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

[Ben Rubinstein]

 > It requires an explicit '...':

Ahah! Not being a javascripter, I completely missed that, and thought you were 
just omitting some text for clarity!

[Sidenote: what idiot decided to use ellipsis as an operator?? And not even 
the ellipsis character, but three dots???].

 > Interesting your missing of the all important operator being required reminds
 > of a mistake I did make way back when I added the ability to use a sequence
 > array as an array index...
 >
 >    put tArray[tFoo] into tBar -- evaluates as tArray[1][2]

What the... ? [insert joke here - I wrote that without realising what I'd 
done...]. I had no idea this facility existed. Is it documented anywhere?

Just to be clear, because the example below is ambiguous, given

       put "a" into tFoo[1]
       put "b" into tFoo[2]

would
       put tArray[tFoo] into tBar

evaluate as
	tArray["a"]["b"]
or
	tArray[1][2]

?



On 08/09/2021 14:20, Mark Waddingham via use-livecode wrote:
> On 2021-09-08 13:09, Ben Rubinstein via use-livecode wrote:
>> I'm also excited by the items in this list, at least the ones that I 
>> understand.
>>
>> I am a bit disturbed by the Tail Expressions one, because to the
>> extent that I do understand it, I don't see how this doesn't break
>> existing code that passes an array, and will do so in the worst way,
>> i.e. silently, leaving the developer to figure out what's going on by
>> the secondary or tertiary effects. Am I wrong?
> 
> It requires an explicit '...':
> 
>      put 1 into tFoo[1]
>      put 2 into tFoo[2]
> 
>      myHandler tFoo -- passes a single argument: the array tFoo
>      myHandler ... tFoo -- passes two arguments: 1, 2 (the elements of tFoo)
> 
> Interesting your missing of the all important operator being required reminds 
> of a mistake I did make way back when I added the ability to use a sequence 
> array as an array index...
> 
>    put tArray[tFoo] into tBar -- evaluates as tArray[1][2]
> 
> I really should have thought to require explicit syntax there. i.e.
> 
>    put tArray[... tFoo] into tBar
> 
> The reason here is performance - if I had done that it would mean the engine 
> would known that in the case of:
> 
>    put tArray[tFoo]
> 
> That it will only ever generate a path of length 1 to index the array - rather 
> than pretty much all array expressions potentially being unbounded in length.
> 
> You live, you learn.
> 
>> I'm very pleased about constant expressions. I do wonder whether this
>> raft of changes might also be the moment to do something about this
>> nasty little weirdness:
>> https://quality.livecode.com/show_bug.cgi?id=18390
> 
> Well constant expressions do alleviate that problem a bit:
> 
>      constant kFormatArg = format("\"%s\"")
> 
>      put format(kFormatArg, "Hello") => "Hello"
>      put format("\"%s\"", "Hello") => "Hello"
> 
> i.e. The use of `\` escapes in format, generates characters which format 
> otherwise skips over as content - except `\` itself, so you have to be a 
> little careful there. i.e.
> 
>     constant kFormatArg = "\\\\%s"
> 
>     put format(kFormatArg, "Hello") => "\Hello"
>     put format("\\%s", "Hello") => "\Hello"
> 
> In regards to your comment on that report then yes that is a good idea - 
> albeit a breaking change. However, I think that is probably best considered as 
> part of a package of changes which improve the expression of string constants 
> generally. After all, if tooling is going to be updated, it is better to do so 
> 'all in one go', rather than in dribs and drabs. Multi-line string literals 
> (as mentioned previously) would go into that 'package'.
> 
> Another thing we could consider at that point is adding a 'f' prefix to 
> literals which imply they are C-style escaped (basically a contraction of 
> 'format')... Indeed, we could even make that a way to introduce variable 
> interpolation.
> 
> Also, at that point I'd probably suggest that we also allow ' or " to delimit 
> strings.
> 
> So f'...' or f"...", '...\'...', "...\"...", '''...''', """...""".
> 
> (Specifically here I'm proposing that there would be no semantic difference 
> between ' and " - they would merely enable trivial inclusion of the other 
> quote type).
> 
> 
>> I also wonder whether this might be the moment to introduce another
>> bit of (completely non-breaking) syntactic sugar:
>> https://quality.livecode.com/show_bug.cgi?id=8945
> 
> Hehe - with integers being unbounded, there are plenty more version numbers in 
> the future ;)
> 
> Warmest Regards,
> 
> Mark.
>