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.
_______________________________________________
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
