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.