LES3: can named prefix operators or unparenthesized calls be practical?

[qwertie]

ASCII doesn't have enough characters.

For LESv3, I designed a special use for single quote (followed by a space or an identifier): it would cause a parsing mode where each tokens is simply converted to a Loyc tree, e.g. (' x+y, z) means (`'`(x, `'+`, y, `',`, z)). Inside this mode, square and curly brackets [] {} temporarily switch back to normal parsing. This works great for DSLs of unusual syntax, such as parser generators:

parser = ('lexer
  email :: name ('.' name)* "@" name ('.' name)+
  name returns int :: {result := 0} (('A'..'Z' | '0'..'9' | '-' | '_') {result++})+
)

I've been wondering if it wouldn't have more value to use the single quote differently. For one thing, I was looking at some Ruby code the other day and I was like "this is nice."

attr_reader :name, :age

Meanwhile, Julia and (I think) MATLAB have a nice syntax for matrixes that is space-sensitive, something like

X = [x*x 0; 1 x*y]

Could LES understand lines like these?

'print lastName ", " firstName // means print(lastName, ",", firstName)
X = [' x*x 0; 1 x*y] // means, uh... [`'`(x*x, 0, `';`, 1, x*y)]?

Maybe, but I don't think ; would work as a delimiter unless it terminates the special parsing mode, because outside brackets it should mark end-of-statement. And similarly for comma:

'print x " times 2 = " x*2; 'print "should be a separate statement"
ThisSeemsToAccept2Arguments('sin x, x + 1)

An ordinary operator character could delimit matrix rows instead:

X = [' x*x 0 | 1 x*y] // Reasonable

The change I'm thinking of would have two parts:

1. Multiple tokens not separated by a space are parsed as an expression
2. Parentheses reset the parsing mode to normal

The second rule is motivated by examples like

'print (x + 1)*x

because surely this must mean print((x + 1) * x) and not print((x, '+, 1) * x), which is what it might mean if parentheses don't reset the parsing mode.

Both of these changes would harm the ability to parse grammars. #1 would mean that X? is a syntax error, while #2 would mean that A (B | C D) is a syntax error. Another disadvantage is that, by convention, ' means "operator", but I specifically want to use it to call ordinary non-operator functions like sin or print. Finally, I defined this notation as being able to accept multiple arguments, but that's not good for unary operators, as we'd like 'sin x + 1 to mean sin(x) + 1 and not sin(x, '+, 1).

So, while it would be nice to create opportunities to avoid parentheses, the cost seems too high for this idea. Thoughts?

[qwertie]

New idea for omitting parentheses in calls

In LESv2 the $ operator - commonly used for substitution, string interpolation, or other purposes, e.g. in Ruby it denotes a global variable - was specially designed: it could only be a prefix operator, not an infix operator. This design choice allowed you to write "superexpressions" like

print $x $y;

which means

print($x, $y);

I copied this rule into LESv3 even though the motivation for it (superexpressions) had disappeared. So now I'm thinking, huh, what if $ were a pseudo-operator meaning "call the thing on the left without parentheses"?

Then you could write log$x as a shortcut for log(x). Maybe it doesn't look as nice as 'log x, but I'm thinking syntax highlighting could lessen the ugliness, e.g. by showing $ in a very light color so it is barely visible.

What precedence should this operator have? Well, Haskell defines a very similar $ operator which, I must say, completely baffled me when I first saw it in some code. Anyway it's nice to have a precedent, and that precedent implies that this operator's precedence should be very low. It's unclear whether it's appropriate to copy Haskell's precedence choice, however, because Haskell already lets you just write log x without parentheses, so the motivation for LES to have this operator would be to gain a feature Haskell already has, and arguably the best reason to omit parentheses is if you're writing something short and sweet like log$x. It would certainly have less than maximum precedence though: Math.log$vector.x surely means Math.log(vector.x).

Note the need for double-$ for string interpolation (each $ being a separate operator - would a space be required between them? I do not know...)

Console.WriteLine$$"Hello {name}!"

Since this would be a pseudo-operator, not a real operator, log$x would have the same Loyc tree as log(x) (just with a style/trivia attribute to indicate the presence of the $). I think this would be better than a real operator because the motivation for this operator arises from the need to avoid ambiguities in the grammar of LES itself. These ambiguities prevent me from letting users just write log x (an early design actually had a juxtaposition operator so you could write log x - I don't remember the full details of why I removed it, but expressions like log -x are prima facie ambiguous, and the juxtaposition operator is ambiguous in the presence of the newer arbitrary-binary-word-operators feature.) The point is, it's a low-level concern of LES, not a high-level concern of whatever consumes the Loyc tree.

Another question is whether it should be possible to call a method of two arguments with this pseudo-operator. Er, probably not. The ambiguity monster stirs...

I'm inclined to require that there be no space to the left of $, in order to reserve $-with-a-space-on-the-left for future use (a pseudo-operator need not follow the same rules as normal operators.) A space to the right of $ seems acceptable. What "future use"? One possibility: $-with-a-space-on-the-left has a low precedence while $ without-a-space has high precedence.