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

[Mark Waddingham]

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.

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