LiveCode Forums.

Whoops. I meant that in phase two, a literal string in the first parameter of format() would be parsed like all other literal strings. I have no idea how "literal quote" came out of these fingers. (Well, actually I do, but I don't want to know how that happened.)

I'll try code:
(the ambiguity example again)

Thanks!

The main problem with implied concatenation is that it reduces the flexibility of the syntax we can create as it means that any expression can be a sequence of expressions as well as just a single expression.

For example, we are currently proposing adding 'start using font' syntax as a way to integrate revFont. The current idea is this syntax: Let's say we added this, and (for whatever reason) someone had in their script: With implied concatenation this would parse fine and result in the command loading the font "myfont.ttf-suffix". This might seem okay (at this point), however we could then never add 'start using font <expr> globally' (to mean load font for all processes) since the globally keyword would always be resolved as part of the <expr>.

Now, this is a very contrived example but I'm sure there are a myriad of much less contrived ones lurking around - indeed, the problem is that we cannot forsee entirely how it might restrict the language in the future. One of the things that makes it possible for the abstraction of the current syntax work is the requirement for operators between expressions and I'm not at all comfortable with the idea of removing this requirement.

In regards to ':' as a return concatenation operation, I remembered yesterday that (at the back of my mind) I had ear-marked that for a proper list concatenation operator: Would result in a sequenced array tVar[1] = "a", tVar[2] = "b", tVar[3] = "c" - it would make a nice complement to "," which is essentially a string list concatenation operator.

@monte: Haha - I wondered if you would remember that - it occurred to me while I was making that post. In my defense, I was doing a little style experiment to see if I could work out how to explain appropriate uses of "? :" in engine coding as part of writing up our coding standards.

@runrevmark good excuse

So implied concatenation is out.

Would result in a sequenced array tVar[1] = "a", tVar[2] = "b", tVar[3] = "c" - it would make a nice complement to "," which is essentially a string list concatenation operator.

This is pretty cool, however, some braces and just using comma might work better for array assignment. I think it more clearly demonstrates what's happening. It also leaves : for return if you want that...

Perhaps the syntax for simple array building should be integrated with operations on arrays interpreted as sequences, sets or bags in a preferred format and with operations to build trivial instances of those with zero or one elements.

So implied concatenation is out.

Well, at least the general case. We could potentially experiment with making things like 'tab' and 'return' binary (and potentially unary) operators at some point with the new parser but I'm not sure how well that will work. So: This is, of course, assuming that the parser wouldn't throw up its hands in horror at: (I don't think it would, but I'd have to think quite hard about what it would actually do in this case if 'return' were left/right unary, binary and a constant).

However, all that being said, I'm still not entirely convinced I (personally) like that particular syntax

This is pretty cool, however, some braces and just using comma might work better for array assignment. I think it more clearly demonstrates what's happening. It also leaves : for return if you want that...

I guess the following syntax wouldn't be too bad: Re-using brackets seems to make the most sense as that is what is used for indices on arrays at the moment. Overloading ',' has always concerned me a little - although at least this overloading is (essentially) identical to the case of passing a list of parameters to a function or command (which is a 'proper' list, rather than a string).

I like it but I do wonder what happens if you pass in a variable with comma. Or change the itemDel... All this reminds me that I want to add split/combine as table with keys... This would take some delimited text and some column names and return a multi-dimensional array with the first key being row number and second key being column name. If no keys are supplied then the second key is a column number.

Though brackets say "array", putting elements inside the brackets might be confusing.

I wonder if using comma-brackets
is really any more readable than
where sequence is a function, LiveCode or engine.

The idea of 'return' as an operator is pretty clever. To keep the concept simple, it should apply to any built-in single character constant, but maybe also CRLF. Maybe there is some better--and still easy to remember--set of constants.

Then '&&' would be shorthand for 'space'.

There might be a problem with learnings inferring concatenation.

I suppose we are getting away from the original topic, except by the thin thread that includes concatenation operators.

Suppose it is handy to represent a wide range of things as a count indexed array, that is, an array with keys 1, 2, 3....

If we embrace overloading comma, then we can see the meaning of comma depending on the context. Contexts are function parameters, perhaps the above sequence builder notation with brackets, and the general expression context. Other clear contexts can be added.

I assume something like this is meaningful in this notation:
As I mentioned, a function could do that but a long function name can make it harder to read. Also, the brackets mixed with parentheses (as in the above example) make reading easier than a lot of parentheses. I'm not sure that a comma in a special context is the way to go or,if it is,whether [] is the way to indicate that context; I'm speaking in abstractions.

(When there is a special context, the comma might not be needed; maybe juxtaposition, that is, adjacent elements will suffice.)

This could be used to create a singleton like this:
That might be easier to read than, say:
I'm not sure which really looks best.

There should be a way to concatenate such a count indexed array. And if there is a singleton operator and not a builder for a count indexed array then that should be simple and maybe built-in. The much coveted colon could be used or '&' could be overloaded for concatenating count-indexed arrays. Like this:
That doesn't really look like LiveCode any more.

Maybe those can be compared to what we might do now:
It might be possible to automatically convert nonarrays to singletons, but there will still need to be a way to make an array an element of the resulting concatenated sequence and not concatenated by the operation. So the last one above might optionally be written like this:
And an example of making an array an element might look like this:
There might be a way to do that without using up special characters.

We might be losing a lot of ways to make typos that create errors. If almost everything we type looks good, then many typos will not be caught.

I'm again coming late to the party, but I want to express my horror of multiple double-quotes. Having used these in Visual Basic for the same results, I can say that they work for simple examples, but for anything more complex they rapidly become unreadable. And that's "unreadable" even beyond the VB coding context.

I *would*, however, like to suggest that single- and double-quotes be used interchangeably, as this would simplify both the parsing and reabability of scripts:
(hand-coding the "

I'm with Mark Wieder on this one. Allowing the use of single and double quotes interchangeably as string identifiers would at least take the drudgery out of adding quotes to strings - at the day-job, we use Progress OpenEdge and it allows this. Still doesn't help for multi-line text or arrays, but it's easy enough to understand and read.

Jan Schenkel.

If single quotes (') are consumed (from the cool symbols for future use) and used as an alternative bracketing in string literals, then should double quotes (") be allowed in single-quote strings?

If repeated quotes ("") are allowed to represent a double quote (") in double-quote strings (that source of horror), can some sort of colorization be used to mitigate any readability problems?

If single quotes (') are consumed (from the cool symbols for future use) and used as an alternative bracketing in string literals, then should double quotes (") be allowed in single-quote strings?

I certainly think so. See my example re: color="red"

If repeated quotes ("") are allowed to represent a double quote (") in double-quote strings (that source of horror), can some sort of colorization be used to mitigate any readability problems?

Hmmm. Possibly, although readability and compiler parsing are still problems with things like """hey!"" & he repeated, ""I said quote & ""stop that!"" & quote".
Also, I think the doubled double-quotes are error-prone for entering text.

The function format() and matchText() use special string parsing for a string literal for the first parameter to allow a quote in the string.

If special string literals are dropped, then the language is simpler but scripts break. Maybe there is some way to ease the transition.

If special string literals are not dropped, then documentation and colorization might emphasize the specialness.

(Oh, my brain didn't see your good example of double quote in a single quote string, Mark Wieder. Sorry. Maybe it is because it works so well! And your leadership in writing "doubled double-quote" is appreciate; that is clear.)