LiveCode 10 - what are your thoughts on the new features?

[Mark Waddingham]

On 2021-09-08 11:35, Andre Garzia via use-livecode wrote:
>> I just don't understand this one, so no comment.
> 
> As I understand, this is LC version of the “spread operator”.  It
> allows you to spread the elements of an array as the arguments to a
> handler.
> 
> The code:
> 
>   put “andre at example.com <mailto:andre at example.com>” into tDataA[1]
>   put “Andre Garzia” into tDataA[2]
> 
>   sendEmail …tDataA
> 
> Is syntactically equivalent to:
> 
> 
>   put “andre at example.com <mailto:andre at example.com>” into tDataA[1]
>   put “Andre Garzia” into tDataA[2]
> 
>   sendEmail tDataA[1], tDataA[2]
> 
> Which means that you can code the “sendEmail” command to have two
> string arguments instead of an array, as shown below:
> 
>   command sendEmail pEmail, pFullName
>     // send your email
>   end sendEmail
> 
> The spread operator will pass every array element as an argument to
> the handler.

Yes - that is precisely what it is :)

> It would be beneficial if this feature would also come paired a “rest
> operator” that collected extra arguments in an array, so that we could
> declare the “sendEmail” handler as
> 
>   command sendEmail pEmail, pFullName, …pMoreArgumentsA
>     // stuff
>   end sendEmail
> 
> This way, if the call uses an array that contains more than two
> elements, the remaining parameters are collected in the final
> “pMoreArgumentsA” array. That if what I would like to have, LC didn’t
> say anything about this but it is very common in other languages to
> implement both operators at the same time.

Indeed.

The key thing here is that doing that adds to the handler signature 
syntax which I'd prefer to do as part of a more substantial improvement 
to the expressibility of that aspect of the language.

Therefore...

> In the case of LiveCode there is an alternative though. We can use
> “paramCount” and “param()” to grab the extra parameters, but that
> requires us coding it while something like a “rest operator” do that
> for us automatically.

The feature I omitted from the list and which does pair with the spread 
(or tail) operator is a tweak to the params function... Namely:

    params(N) => returns a sequence or params starting from the Nth

So in the above:

    command sendEmail pEmail, pFullName
      local tMoreArgumentsA
      put params(3) into tMoreArgumentsA
      ...
    end sendEmail

This is a direct evolution / useful addition to the current way existing 
handlers manipulate arguments - and, more importantly, saves a blob of 
code I've seen 100's of times in code which needs to forward arguments:

    command foo
      local tParams
      repeat with i = 1 to the paramCount
         put param(i) into tParams[i]
      end repeat
      ...
    end foo

Also this feature is largely orthogonal to any tweak to handler 
signature (i.e. the merge operator, Andre suggests above) as it just 
manipulates the parameters as defined by the signature. For example, in 
the imagined case of a 'merge' clause:

    command merged pFoo, pRestA...
        put the paramCount into tCount -- gives 2
        put param(1) into tFoo -- would give pFoo
        put param(2) into tRestA - would give pRestA
    end merged

Here there are two parameters - pFoo, and an (array) pRestA which 
contains the rest of the parameters passed.

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps