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

[Mark Waddingham]

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.

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