On 2017-08-13 23:26, Monte Goulding via use-livecode wrote:
Ha “(and may not be)” should really be “(and is really really unlikely
to be)” but still it was an interesting thing to have a play with.
In its current form - yes - it is unlikely.
There are several (some orthogonal, some not) options with regards what
we could with the way string literals can be represented in LiveCode.
They all need to be considered in comparison as a whole in as unbiased a
fashion as possible (when taking into account all the ramifications).
Whilst I think most options have been mentioned we still haven't
collected that into a more grokable form with the pros and cons of each
which means any point of view will tend to be biased by what can be seen
directly, rather than what could exist. (In this case this is
particularly important for two reasons - some of the options to not meld
together, it is one or the other and this changes the lexical structure
of the language in a very key way).
In particular, the provision for escaping chars in a string literal is
orthogonal to that of allowing single and double quote bounded literals
- so the merit of both of these things need to be evaluated separately.
Indeed, 'de-escaping' is a function which runs on a string producing the
*actual* string and from this point of view any token structure which
allows escaped strings is actually syntactic sugar for a function
application (if one that is done at compile-time - but that is just a
special-case of simple constant folding, a mechanism for which would be
universally applicable).
[ In Monte's PR, 'X' => format("X") - abstractly at least - after the
tokens have been converted to actual values. Since we already have a
function which can de-escape (format), that requires some analysis
first. Indeed, escaping / de-escaping is a simpler operation than
'format' so perhaps they need their own functions - which would be
useful in their own right ].
To give an idea of the balancing act, one of the key motivations for
having single-quote delimited strings (based on the most recent request)
is to make constructing strings with double-quote in them easier for
JavaScript, HTML and SQL (or any language which uses double-quote for
string literals, in fact), as well as making it easier to have literals
for control references (e.g. 'button "foo"') but that ability is also
weakened by *also* having escapes. e.g.
JS: "window.alert(\"Hello\nWorld!\")" ->
Potential LC no escapes: 'window.alert("Hello\nWorld!")' -- no
escapes
Potential LC with escapes: 'window.alert("Hello\\nWorld!")' -- with
escapes
One thing which does need more thought is whether we *really* need
escapes in single or double quoted literals at all? Is there other ways
we could improve LiveCode Script so that they aren't really necessary
and if not, then would it better that escaping require a little more
than just "..." or '...' (at the moment you get the same effect as '...'
in the PR by doing format("...") - or could, with some
backwards-compatible changes to format(), at least).
Certainly the PR suggests there are a few other things which should be
done first, and separately. e.g. Sorting out what identifiers can hold
(I think we can safely remove single-quote which is a pre-requisite for
allowing single-quote delimited literals - but is it worth cleaving out
others, if possible?) and looking and what escaped string structure
makes the most sense (can we define one which is copy-paste compatible
with as many other languages as possible?).
Warmest Regards,
Mark.
P.S. There is another quote-like char which could be used for an
implicitly merged / escaped string literal - back-quote - `...`. So that
should be considered too - one option would be single-quote and
double-quote delimited strings are the same beyond the quote char; but
back-quote delimited strings do more work, i.e. de-escape and
potentially interpolate. (Of course, this does add *more* symbols to the
language - but one thing symbols are good for is readable bracketing, so
maybe that's a good justification).
--
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
