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.