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 ~ 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
