LiveCode Forums.

@monte:

Is there any reason to add \q to format etc when you could just translate \" to "" ?

Other than consistency with the other escapes, no. There'd be no problem adding things like \uXXXX to 'format' too when Unicode arrives.

@markw:

Are ; and : free for tab and return? e.g. "First line" : "Second Line" : "Third line" or "First item" ; "Second item" ; "Third item"

';' is equivalent to newline so that's not available... As to ':', that depends on whether its considered part of an identifier or not, I'd have to check - but that could work for a return concatenation operator.

Maybe | for tab concatenation then - if such an operator is actually desirable.

Maybe | for tab concatenation then - if such an operator is actually desirable.

That's the question I guess. LiveCode as a language minimizes on the use of symbols, so I'm not sure we want to add a whole raft of them. However, we already have ',', '&' and '&&' so there is precedent. I certainly quite like ':' for newline concatenation - It would make code a bit more readable than using '& return &' and this is a very commonly used form.

As to needing one for tab, I guess it depends on how much that operation is actually used...

there's always: synonyms for return:
return
linefeed
cr
lf

Hmm... but I'm hoping for this one day:
Actually... I'm guessing the xTalk police won't like that one even though it's very useful in most other languages. However, I think I've solved the concatenation operator issue. Right now we can escape a newline in our scripts with \ so why not just extend that with \n and \t and allow those escapes to format correctly either on a single or over multiple lines:
same as
I think this is a good solution because it likely replaces this much less readable code:

Only non-topic comments in this reply.

Personally I think your coding style is weird, Monte

Whenever I have complex strings, I put them into a field or a custom property. To get rid of text formatting issues in scripts, I'd rater have an easy way to never enter user-read text within the script... great way to be ready for localisation too!

@monte: To my mind, both of the suggestions heavily distort the language into something it's not. One of the 'readability' aspects of LiveCode is that it is very light on operators - yes, it does force you to perhaps type a little more, but generally the result is much more readable.

I'd argue with the utility of the ternery operator - I do use it occasionally in C++, but generally I find 'ifs' more readable (obviously this is a personal perspective).

In regards to token elision (with \n and \t) then this just seems clunky somehow (the semantics of what is going on is implicit - whereas at least with an operator there is something clearly manipulating things). If this is something that is really wanted then a ':' operator would be at least consistent with &, &&, and ',' (although I am very wary of introducing new operators into the core). Also, remember, 'format()' isn't going away:

Just throwing another suggestion out here... The cases we are discussing are all to do with the processing of string literals thus another suggestion is to have a context-local property that would control their processing.

For example: I'm not sure how much of a good suggestion this is, but there are other examples such as convertOctals which affect the interpretation of literals so there is precedence already in the language. It does have the 'pay-for-what-you-use' aspect to it though (in this case more in the sense of pay the comprehension cost as in readability, rather than performance); and also localises it to when its needed.

I've worked for a very large company where use of the ternary operator was banned as it is not at all readable and had actually been identified as a regular source of bugs.

I suspect there's no justification for a tab concatenation operator. I do quite like ':' as a newline concatenation shorthand.

However, in all of this I think Bjornke has hit the nail on the head:

To get rid of text formatting issues in scripts, I'd rater have an easy way to never enter user-read text within the script... great way to be ready for localisation too!

Built-in localisable string references and a localisation system would be really useful. Qt does this a nice way, where you have a tr() macro around a user readable string - if the string doesn't have a corresponding localisation for the current language then the string itself is used - the macro doubles up as a marker for tools that process the source and manage lists of all the localisable strings and translations. I bet we could come up with an even nicer syntax/marker for doing the same thing in LiveCode.
I like it. This might be handy if you want to use LiveCode to process ascii representations of escaped string output/input for other programs or externals. Could be useful for implementing the tools to handle localisation.

An alternative approach is a display editor in the script editor. This translates a limited in-line text box to a format() expression bounded with some comment markers. It shows up as a bordered box in the editor acting as one character, but that can be turned off. The markers (and thus the editing box) can be removed.

Tabs (to default positions), new-lines, and funny characters are allowed.

This might be especially handy for preambles and epilogs in message creation and be a good alternative to parsing one's own script comments or pulling info from a (hidden) field. These can be script constants.

But there is no reason why this can't be the layout for three lines of a log entry.

The language at one level is still format(), but the editor helps with a box you can fill in. People can use what style they like.

This might be considered a slight change from the script model of source (string), or it might be considered just a helper in writing and displaying scripts.

It might be harder to read scripts over the phone, but turning off the box should help.

(I'm good at thinking up hard things that others might implement.)

(Slightly related is the name of the newline character. I know it will break some scripts, but I hope for NL as yet another name for it. Or newline. I use LF when I want to be explicit what the code is, especially in ASCII contexts. Otherwise, well, except when matching a customer's style, I use LF then, too. In the context of LF and CRLF, the name CR seems just wrong to me, on top of my having to create a name for ASCII CR that is not CR. And return reminds me of CR. And the name of NUL is wrong. -- Grandpa ASCII)

@DarScott: Don't worry this irks me slightly as well - I've always found it slightly alarming that 'cr' is never numToChar(13). I must confess I use 'return' as I don't seem to have the same connection between that and 'carriage return' as you do. That being said - I see the issue there too. Of course, if one is being pedantic then one could argue that 'newline' / 'NL' should really be NEL (U+0085)

Hmm... I'm thinking that using format is simpler than escapedStrings so perhaps just stick with that. I do think if you are messing with format to remove \" then replace it with "" rather than \q then add "" everywhere. I'm not sold on : as return as I don't see the connection. One idea might be to allow all constants to have implied concatenation in a string because its the ampersand that reduces readability.
@runrevmark I would like to point out you modified one of my contributions to include the ternary operator...

I agree with \q probably not needed. Perhaps the timing is such-- Phase 1: Allow "" everywhere, even in format(). Phase 2: Drop \". I think that means in Phase 2, the literal quote would be the same as all other places for format().

I think implied concatenation can be considered.

This case is a problem (I need to learn how to hand enter code displays):

put "hello""world"

That would be ambiguous with implied concatenation and "". I suppose it could be required that concatenation requires a space between.

Both have problems with commands that allow two operands in a row. Maybe 'special effect' does, but that might be a bug. A space would get rid of "" but might not work with commands with two parameters in a row, if there really are any. That can be handled the same as the clash between comma operator and comma the parameter separator, perhaps, parameter separation has precedence and parentheses can be used to force concatenation.

I think some people continue commands on the next line after '& return &'. I wonder how the concatenation idea fits in with that. It might look nice.

I wonder about this:

put f(y)

Is that a function application or an implied concatenation? Is there a way to tell in LiveCode? I think we are getting into why we don't have juxtaposition (implied) multiplication. Spaces can get rid of name merging, but function syntax can still affect things.

(I need to find a reference so I can put code in by hand. Or maybe not use Safari.)

@Dar:
[/code]

Cheers,

Malte