common code patterns

[Mark Waddingham]

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 ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps