Using '@' to mark pass-by-reference (was Re: synonyms)

[Mike Kerner]

I was going to reply to something, but part way through the last message,
my brain melted and I stated thinking in 8088 assembler.  I HATE WHEN THAT
HAPPENS!
The reason for forgetting is because it is not something that I, at least,
will be tempted to use very often, on the order of "this me"
So if we're going to be stuck with "@", allowing the developer to put it in
both places in order to make code clearer makes sense.  What I meant was it
would be nice if ithere was the option to put it on the leading or the
trailing side of the name, because for as seldom as I use the syntax, I
usually screw it up.
The other thing that would be good for the purpose of making this
jargonist is to talk about it as an alias instead of a reference in the
docs and the dictionary, for the same reason that "container" was more
commonly used in HC than "variable" for the first n years.


On Fri, Aug 18, 2017 at 11:38 AM, Mark Waddingham via use-livecode <
use-livecode at lists.runrev.com> wrote:

> On 2017-08-18 17:18, Bob Sneidar via use-livecode wrote:
>
>> That actually is a great explanation which solves a mystery I've often
>> wondnered about, which is how a handler with a different variable name
>> can contain the *actual* original variable. I thought the engine
>> actually created a new variable and copied the incoming value to it,
>> and then reversed this operation on return. Aliasing makes perfect
>> sense.
>>
>
> That's what would call 'inout' parameter mode.
>
> For most languages which exist today, the way you can specify to pass
> parameters to functions distills down into 4 types (generally these are
> called parameter 'modes'):
>
>   - by-ref
>   - by-value (also called 'in')
>   - copy-out (generally called 'out')
>   - copy-in-copy-out (generally called 'inout')
>
> Let us imagine we supported all these modes and we had a handler with
> signature:
>
>   command myHandler @yRef, in pIn, out rOut, inout xInOut
>
> Called with
>
>   myHandler tRef, tIn, tOut, tInOut
>
> The 'by-value'/'in' mode is what we are most familiar with. On entry to
> the handler the value in pIn is copied into the receiving variable tIn.
>
> The 'out' mode is similar to what you describe. On entry to the handler
> rOut contains nothing; on exit from the handler, the value in rOut is
> 'copied back' into the passed variable tOut.
>
> The 'inout' mode is a mixture of the two: on entry tInOut is copied into
> xInOut, and on exit xInOut is copied back into tInOut.
>
> In the 'by-ref' mode there is no copying at all - mutations to the
> receiving variable yRef are actually mutations to the passed variable tRef.
> i.e. yRef doesn't really exist at all.
>
> The by-ref mode can emulate all of the other modes - you just have to code
> with some rules:
>
> To use a by-ref parameter as 'in' - you must not change the value of the
> parameter in the handler being called.
>
> To use a by-ref parameter as 'out' - you must not read the parameter at
> all and only change the value of the parameter except just before you
> exit/return.
>
> To use a by-ref parameter as 'inout' - you can read the parameter at any
> point, but only change it just before you exit/return.
>
> In most languages, the 'copy-back' part of the 'out' and 'inout' modes
> only generally happen for normal handler exit - they don't happen if you
> throw an exception.
>
> Now, having said all of that - there is actually a fifth parameter mode
> 'call-by-name' which at least one language had - ALGOL. Basically this
> meant (IIRC) that you passed in the symbolic expression to the receiver so
> it acted as some kind of macro:
>
>   foo(tArray[I]) - inside foo, any reference to that parameter would
> re-evaluate tArray[I] in the context of the caller.
>
> The reason I mention this is because the way LiveCode does by-ref
> parameters for array elements is *almost* like this - but not quite as
> unwieldy. When you do:
>
>   command myHandler @xVar
>     put 100 into xVar["baz"]
>   end myHandler
>
>   local tArray
>   myHandler tArray[tIndex1][tIndex2]
>
> What actually happens is somewhat equivalent to the following:
>
>   local tArrayPath
>   put tIndex1 into tArrayPath[1]
>   put tIndex2 into tArrayPath[2]
>   myHandlerModified tArray, tArrayPath -- a second parameter has been
> added here
>
> With
>
>   command myHandlerModified @xArray, pArrayPath
>     put 100 into xArray[pArrayPath]["baz"]
>   end myHandlerModified
>
> Basically, the 'path' is frozen before the call, but implicitly used
> within the call when mutating the by-ref variable.
>
>
> Warmest Regards,
>
> Mark.
>
> --
> Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."