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

[Ben Rubinstein]

I'm also excited by the items in this list, at least the ones that I understand.

I still haven't fully understood the one Alex raises below, but I'm content 
that it won't bother me until I do.

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?

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

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

Ben, eagerly anticipating


On 08/09/2021 08:50, Mark Waddingham via use-livecode wrote:
> On 2021-09-08 01:33, Alex Tweedly via use-livecode wrote:
>> But
>>      put [1, 2, 3 ] into tVar2
>> isn't clear to me. If it was in Python it would be a list - but LC
>> doesn't have 'lists'.
>>
>> Is it equivalent to
>>    put true into tVar2[1]
>>    put true into tVar2[2]
>>    put true into tVar2[3]    ??
> 
> Yes.
> 
> A sequence in LC is a numerically-keyed array where the keys range from 
> 1...the number of elements.
> 
> Admittedly they are (currently) still implemented as a 'normal' array 
> internally, but they do have different functionality in `repeat for each 
> element` which iterates in numeric order, and not hash order.
> 
>> Why can't I say
>>     put { myvar: "first", anothervar: tWhatever } into tVar2   ?
> 
> So if one treats array literals as an equivalent to an ordered sequence of put 
> statements (which is the canonical interpretation really!) then there is, in 
> principal, no problem with allowing non-constant expressions for both key and 
> value.
> 
> Certainly non-constant value expressions are no problem at all, and would be 
> included in the initial implementation... I'm not averse to non-constant key 
> expressions either really, I'm just a little skittish over the resulting 
> reservation of ':' (which is probably fine), and the interplay with variables 
> and unquoted-literals (more in terms of difference that might occur between 
> what the engine thinks something means and what the writer intended).
> 
>> But I was disappointed to not see my two biggest 'constant' wishes
>>
>> 1. multi-line constants e.g. amongst other ways, Python's
>>
>> put """line 1
>>
>> line 2
>>
>> line 3""" into tVar
> 
> I'm not averse to the idea of multi-line literals - although constant-folding 
> does go a long way to assuage the problems they solve in many cases.
> 
> e.g. You can use format("dfsdf\ndfgdfg") for short strings with newlines in, 
> and any chained sequence of concatenations of constants will be evaluated at 
> compile time.
> 
> The main issue here is the effect on tooling really - any code which processes 
> LiveCode Script in any way would need to change to take them into account. 
> This not only includes syntax highlighters and editors but any code which 
> groks script for other reason. This means that what might be a relatively 
> simple change to the engine, actually introduces a ripple effect where the 
> whole implementation burden is a great deal higher.
> 
> [ I'd point out that I don't think there is a single piece of tooling in 
> existence which actually fully supports the *current* lexical structure of 
> LiveCode - which has not actually changed since day dot - including the 
> existing Script Editor ]
> 
> That being said, in terms of what multiline syntax I'd propose, if it were to 
> be added - I'd be in favour of Swift's model. Most other languages have added 
> multiline strings with no thought to code structure, however the Swift team 
> really have:
> 
>     var foo = """
>       Line 1 - spaces before stripped
>       Line 2 - spaces before stripped
>       """
> 
> There are two simple rules at play here.
> 
> The first is that no string content is present on the lines containing """ - 
> i.e. the string content starts on the line after the opening """, and the 
> string content ends on the line before the closing """.
> 
> The second is that whitespace is stripped from each line of the string content 
> based on the whitespace before the final """. i.e. If the """ is indented by 3 
> spaces, then 3 spaces are removed from all lines of the content.
> 
> This means indenting of such literals is no different from any other construct 
> - and is merely predicated on identifying the lines in such a literal as 
> continuations (i.e. each line is an extension to the last).
> 
>> 2. global constants. Most compiled languages will allow an 'include'
>> file which can specify constants, which you can then rely on to be
>> defined properly (and the same) everywhere. So that's probably too
>> much at odds with LC's model - but could be handled by 'protect'
>> global variables (or, I'm sure, another 10 ways that Mark W. could
>> think of).
> 
> So if by 'global constant' you mean being able to define a token which means 
> the same thing in all scripts - then yes, that does not really fit at all as 
> it breaks the logical independence of all scripts in terms of what tokens mean.
> 
> Put another way, all scripts would have to be recompiled when a script defines 
> such a thing, which would then potentially change the meaning of any script if 
> it happens to internally use said token for something else (in the worse case 
> scripts which did not have syntax errors before might do so after). This is 
> why you have to declare global variables in all scripts which use them.
> 
> The request for 'global constants' comes up repeatedly, but I don't really 
> recall anyone proposing a single use-case which couldn't be solved in a 
> 'better' (relative to xTalkiness existing featurs) way :D
> 
> Warmest Regards,
> 
> Mark.
>