Escapes in string literals

[DarScott]

I like the idea of literal strings being self contained as far as meaning.

The constants and variable initial values are an important place for literals (and, should it be in our future, folded constants). I like the idea of putting some unicode characters (or strings) or some special bytes into script constants.

The format() function takes time, though smart function compiling or general optimization will remove that.

Are formatted strings in our future? I'm not suggesting anything, but if so, then maybe what is done here can be a path for that.

I like the idea of "pay-for-what-you-use conceptually", but this might leak badly on the lists and forums. Good dictionary and documentation structure might help. Maybe the idea of core LiveCode would help. A better word than "core" maybe. Even so, this is not like using, say, getProp and setProp, this will sneak into all scripts.

[monte]

I'm assuming escapeStrings is a local property.... hmm... I see lots of:

Code: Select all

put the escapeStrings into tEscapeStrings
set the escapeStrings to true
...
set the escapeStrings to tEscapeStrings

So... it's probably simpler to just use format.

The symbol option wouldn't have that issue and you could easily intermingle one type with the other.

I am wondering what happens here:

Code: Select all

put @"hello \q"& tVar &"\q world" into tString

Are the escapes expanded in the second string literal too or just the first?

PS manually entering code tags on safari... it used to work before the conference/upgrade

[mwieder]

PS manually entering code tags on safari... it used to work before the conference/upgrade

See http://forums.runrev.com/viewtopic.php?f=5&t=15337

[mwieder]

I think I'd be fine with the escapedStrings being determined by the engine and not modifiable, i.e., "\t,\n\,q", etc. And, as in format statements, anything else preceded by a backslash is treated literally.

[monte]

That's what I was originally suggesting but has been ruled out as not backwards compatible. Although I guess if the upgrade from the old to new parser can replace \" with \q then it might be able to replace \ with \\ in non-format style strings.... however, what if someone is building a string to put through format....

[mwieder]

OK - this thread is getting a bit long, and I probably missed that part while I was away.
Can you reiterate for me why it's not backwards-compatible? Is it because someone might have backslashes in string literals now that serve a different purpose?

[monte]

Is it because someone might have backslashes in string literals now that serve a different purpose?

Yes

[LCMark]

That's what I was originally suggesting but has been ruled out as not backwards compatible. Although I guess if the upgrade from the old to new parser can replace \" with \q then it might be able to replace \ with \\ in non-format style strings.... however, what if someone is building a string to put through format....

There were two points I made originally - one was that it isn't backwards-compatible to just adopt escaped strings everywhere. The other was whether we want it as the default in the language.

The backwards-compatibility problem is overcome if we make the switch at the point of switchover to 'Clean Syntax' - the script translator could also translate the constant strings (it needs to for 'format()' etc., so the infrastructure would already be in place).

The other issue is the main one - is it in the LiveCode/x-talk spirit to force c-style escaped strings by default, or should it be considered an 'advanced feature'. Most of the rest of the discussion has focused on ways to bring the general ability of escaped strings in a way that means people can still go on using unescaped strings, and only use escaped ones when/if they want to.

[monte]

Hmm... couldn't people continue to use unescaped strings (with the exception of backslash)...

[LCMark]

Hmm... couldn't people continue to use unescaped strings (with the exception of backslash)...

Yes - but you need to know about the backslash thing (and if you want to read other people's scripts then all the escape combinations). Which is why it needs to be seriously considered as to whether it should be something that is imposed on everyone forever.

A lot of suggestions that have been made have been met with 'but it isn't x-talky' - my question is simply whether C-style escaped strings are 'x-talky'. If they are then I guess making that switch is fine, if they aren't then what makes them any better than any of the other previous suggestions (all of which enable people to both have their cake and eat it)?

[mwieder]

Escaping chars is probably the only way to ensure

a) you can mix single- and double-quotes within a string
b) maximum flexibility to escape *any* character within a string

There is additionally less of a cognitive jump when coming from a different language environment or when having to juggle different coding environments. Someone who is used to c-style formatting will be able to use the same style in crafting strings for LiveCode.

...and nobody's forcing developers to use character escaping. You'd still be able to say quote & "hello" & quote.

Regex isn't particulary x-talky, but it's accepted and we're considering expanding its scope to the filter and sort commands.
AFAICT, the only drawback to allowing escaping anywhere in string literals is the compatibility with current strings like "c:\program files".
So... can the engine/parser deal with things like a file path containing backslashes (are they converted internally to forward slashes before processing the string as a collection of chars?

...and I am, btw, slightly annoyed that the "quote" constant means double-quote.
What would the constant for single-quote look like?

[DarScott]

apostrophe

[DarScott]

C-style strings are a source of lots of confusion. Let's keep it simple.

[mwieder]

Regex is a source of even more confusion. But I wouldn't want to have to flounder around without it.

[monte]

Hmm... how do we define x-talky? Is it 'english like'?

Is "\"hello world\"" any less english like than quote & "hello world" & quote ?

My opinion is neither are english like and both have a learning curve yet the escapes once learned is far more efficient and I think readable... I've been staring at LiveCode scripts for 14 years and I still read ampersand as and.... really wish there were a better concatenation operator.