We have made a revision in Release 5 that will allow a parameter to 
be more as you would expect.

LOCAL FN fred(p AS ^SHORT)

or

LOCAL FN fred(p AS PTR TO SHORT)

This also works for bytes, longs, etc.


this should provide a logical way of accessing remote vars.
>Hi all,
>
>Ignorant of Staz' replies (being a digest reader)  I
>wrote:
>
>  >I hope we all agree that:
>  >
>  > '' CONSOLE MODE
>  > LOCAL FN AssignSevenTo(@X&)
>  >   X&=7
>  > END FN
>  > ''
>  > FN AssignSevenTo(X&)
>  > PRINT X&
>  >
>  > should print 7.
>
>No hope!!  Staz' reply reminds me/us that this use of @ is
>forbidden the new FB^3 use of @ to force a variable to be
>lodged in RAM (in case the "register based variables"
>option is on).  I would add that FB^3 syntax is running
>short of intelligible ASCII symbols and consequently @
>already has several meanings!!  That makes life a bit
>difficult; in particular a longer multicharacter syntax
>has to be established as well.
>
>Recall that since FB was born, @x& has meant the address
>of x&. And that meaning persists as you can see from:
>
>           x&=5
>           y&=@x&
>           PRINT [y&] '' prints 5
>
>Similarly
>
>      DIM ptr AS @TEREC
>
>makes ptr a long integer containing the address of a
>text edit record.
>
>But if I understand Staz correctly the @ in
>
>  > LOCAL FN AssignSevenTo(@X&)
>
>means nothing if register variables are off
>BUT if they are "on" (an option new with FB^3)
>the @ commands that X& be a stack
>variable (in RAM) rather than a register variable.
>
>Thus even Andy G. could not make the quoted syntax work!
>
>HOWEVER I believe he could make the following syntax
>work.
>
>  '' CONSOLE MODE
>  LOCAL FN AssignSevenTo(~X&)
>  // ~ asks that X& be a VAR (in RAM)
>    X&=7
>  END FN
>  ''
>  DIM @X& // assures that X& is at a RAM address
>  FN AssignSevenTo(X&)
>  PRINT X&  // should print 7.
>
>The ASCII symbol ~  is hopefully available in this
>context. Recall that ~ is the sign of alternating
>electric current so it's natural to associate it with
>potential change of X&.
>
>I interpret Staz reply as saying that in today's FB^3
>there is no way to neatly realize the VAR concept of
>Pascal *except* via the relatively clumsy dot syntax (or
>worse).
>
>Frankly, to me, the VAR behavior of function arguments
>seems as important or more important than the
>function argument behavior that we currently have.
>
>The funny thing is that it also seems, again to me,
>simpler both in concept and in implementation.
>
>For completeness, let me suggest a more modern syntax
>that would extend to all species of variable:
>
>  '' CONSOLE MODE
>  LOCAL FN AssignSevenTo(X as LONG VAR)
>  // asks that X be a LONG VAR (in RAM)
>    X=7
>  END FN
>  ''
>  DIM @X AS LONG // @ assures that X be at a RAM address
>  FN AssignSevenTo(X)
>  PRINT X  // should print 7.
>
>Incidentally, I am not sure about the necessity of VARs
>being in RAM; it just seems a safer bet.
>
>Any remaining problems in the present corrected proposal?
>
>Any other pleasing syntax for implementing "true" VARs?
>
>Cheers
>
>Larry S
>
>PS.  ^ means "pointer to" in PASCAL; in C
>the symbol is *.  Apologies to Ian Mann
>for an offside pun or two.
>  --------------------------------------
>
>     -- Old programmers never die, they just can't C as well.
>
>
>--
>To unsubscribe, send ANY message to <futurebasic-unsubscribe@...>



Best,

-STAZ  ~)~

800.348.2623 Orders  http://www.stazsoftware.com
228.255.7086 FAX     mailto:staz@...