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

[Mike Kerner]

So how about trying to make it a little easier to read, and using "->"
instead (a 4D way of identifying pointers)?  The position of the symbol
indicates if we have are referencing or dereferencing.  ->a is a reference
to a (pointer to a), and a-> is dereferencing a (give me what a is pointing
to).

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

> On 2017-07-04 17:39, Ben Rubinstein via use-livecode wrote:
>
>> May I hijack this thread to have another go at promoting my feature
>> request for a bit of syntax sugar around parameters which I _think_
>> would not have a very deep implementation requirement?
>>
>> http://quality.livecode.com/show_bug.cgi?id=8945
>>
>
> It is no longer a hijack - I've changed the name of the thread :)
>
> (Although I have hijacked your original post by rewriting the content
> slightly - I hope you don't mind too much!)
>
> The underlying problem here is that whether or not an argument passed to a
> handler is treated 'by value' or 'by reference' is determined by the
> handler at the point it is invoked - not at the point it is called
> (remember that the message path means that one call can end up invoking
> several handlers as it passes through the message path).
>
> This is the only way it can work at the moment because LiveCode Script
> does not require you to explicitly mark arguments that should be passed by
> reference - without that bit of information, the only thing you have to
> 'trust' is whether '@' is present in the signature of the parameter in the
> handler definition *when that handler is actually executed*.
>
> Ben's suggestion (which I think is a really good one - even though I've
> not commented on it at all up until now - including the original
> enhancement request) is that we use '@' as an explicit marker for whether
> an argument should be passed by reference.
>
> I can think of at least one other language which has a similar thing - C#.
> C# has both by-ref and by-value - and it requires 'ref' to be used on
> arguments to method parameters which are 'by-ref'. It requires this because
> C# allows method overloading - you can have two methods in a class with the
> same name as long as their parameters are different:
>
> class RefOverloadExample
> {
>     public void SampleMethod(int i) { }
>     public void SampleMethod(ref int i) { }
> }
>
> Because C# requires 'ref' on arguments it can disambiguate the call to
> 'SampleMethod' - SampleMethod(tFoo), SampleMethod(ref tFoo).
>
> [ For more details about this see https://docs.microsoft.com/en-
> us/dotnet/csharp/language-reference/keywords/ref ]
>
> The weak form of the proposal would not require @ before arguments to
> reference parameters, but would require that it is not present before
> arguments to value parameters:
>
>   command myHandler @xRef, pValue
>   end myHandler
>
>   myHandler tRefVar, tValueVar - fine
>   myHandler @tRefVar, tValueVar - fine
>   myHandler [@]tRefVar, @tValueVar - not fine: passing tValueVar by
> reference to by-value parameter
>
> The strong form of the proposal would require @ before arguments to
> reference parameters:
>
>   command myHandler @xRef, pValue
>   end myHandler
>
>   myHandler tRefVar, tValueVar - not fine: passing tRefVar by value to
> by-ref parameter
>   myHandler @tRefVar, tValueVar - fine
>
> The weak form would still allow you to make the 'accidentally passing the
> wrong argument to a reference parameter' coding fault, but at least if you
> used @ consistently then it would catch the 'passing the wrong argument to
> a value parameter' coding fault. The strong form would eliminate
> ref-parameter related coding faults entirely.
>
> Even in its weak form, there are a few other fringe benefits:
>
>   - we could allow @<literal> to mean: I know this is a by-ref parameter,
> but I don't care about what it gets changed to, I just want it to be
> <literal> on input
>   - we could allow 'put x into param(y)' if the y'th argument was marked
> with '@'
>   - if @ is used consistently then it solves the mismatched reference
> parameter markings in the message path problem:
>        group: on myHandler @isRef
>        card: on myHandler isRef -- oops, I forgot the '@'
>
> There is a very low risk, in my view, of breaking backwards
>>
>
> Ignoring lexical issues (i.e. @ being allowed in an identifier - which is
> only the case because of the way the parameter list of handlers is parsed -
> ick!), then the weak form has no backwards-compatibility issues as far as I
> can see.
>
> In terms of the lexical issue, then the change would mean that '@' would
> become a self-delimiting token - and not be allowed in identifiers.
>
> I can't imagine there is any reasonable code out there which uses '@' in
> identifiers, a bit like "'" is also allowed in identifiers - so changing
> that is probably 'completely' safe. Indeed, we are already considering
> removing various characters from the definition of identifier to allow a
> little more flexibility in the symbols we can use (not that I particularly
> want to add that many symbols, however I fear that adding a few more is
> unavoidable if we want to keep the language ergonomic).
>
> My general feeling is that the weak form is much better than we have now,
> but the strong form is actually how things should be. Indeed, as 'by-ref'
> is a more complicated concept in many ways than 'by-value' it seems fitting
> that it should be explicitly marked - especially as if we were able to move
> to the strong form, we would eliminate the by-ref related coding faults -
> at least insofar as getting a runtime error when we make a mistake (if not
> a compile-time error - which we could only do for private handlers due to
> the dynamic nature of the message path).
>
> 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."