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 ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
