Alternate syntax without newlines

[Gouwi]

Wren is great : not only the language is well designed, but the implementation is concise and efficient.

It brings me joy.

However, i cannot stand the newline syntax as described here. So i started digging the code to research a way to implement an alternate (compatible ?) syntax which would allow to write Wren code on one line with, say, semicolons.

I created this thread for two reasons :

• First, i would like to gather feedback from the community for such endeavour. I understand very well that newlines syntax is a major part of the language design decisions, but maybe there are others like me who prefer NOT to use Gravity as a workaround and stick to Wren.

• Second, changing the syntax will require to rewrite parts of the Wren parser. I am not yet familiar with the implementation and I would like to know if someone with more experience can give me some pointers to analyze the code the right way.

[mhermier]

Both syntax are fine, and have pro and cons. One issue I see is that it will remove the one line function return, requiring an explicit return.

Appart from that, I don't think it will be accepted in main branch because some of the pros of the current syntax makes it more interesting than the comma separated expression syntax.

But if you are really motivated, make your own branch, converting the compiler should be quite trivial and straight forward, since it means mostly replacing checks for blanks/new line by ignoring blanks/expecting ';', with some corner cases. If you want to support both syntax, I think the main corner cases is the one line return function I pointed out earlier.

[darkuranium]

I know this is an old thread, but my $0.02:

To me, having semicolons would be a killer feature since I'm really used to Allman-style braces (plus it makes parsing it less ambiguous, and reduces hidden errors --- all wins in my book). When Wren dropped semicolons entirely and started to support this syntax, it kind of made me lose a lot of interest, to be honest.

@mhermier What do you mean by "one line return function", by the way? I'm having a hard time finding an example that would match that description.

[mhermier]

The one line return syntax implies that the following expressions are the same:

Fn.new(x) { x + 1 }
Fn.new(x) {
  return x + 1
}

Removing significant new line implies that the first short syntax cannot be used.

Considering terminating ';' to be optional, the shortest syntax could then be:

Fn.new(x) { return x + 1 }

Another solution would be to have last expression to be implicitly returned, this also have pros and cons. But I don't think it is desirable as implicit returning last expression can have to much unexpected side effects, by implicitly return internals.

[darkuranium]

Ah, I see.

It also feels like it'd still work even with semicolons. You simply replace the rule of "no newline" with a rule of "no semicolon[s]".

But to be honest, I'm not a fan of that syntax to begin with. I don't like a very suble & non-obvious difference having critical semantic differences --- and a "no semicolon[s]" rule would make it even subtler.

I understand why this exists, though (at least considering blocks are a thing in Wren). I can think of approaches to preserve this feature while making it more explicit, though none of them particularly pleasant. Off the top of my head, options like { (x + 1) } and whatnot.

[mhermier]

The subtilty about ';' as I see it depends if you consider it as a separator or a terminator. The idea that I like and promote, is not to choose and accept both. Making the last ';' optional.

Thinking at it there may be situation where we want the short syntax but no returned value/null. So maybe it is not that bad to have an explicit return, even in the short form.

Most of the time, the new line syntax does not bother me until it does. The if/else become tedious as it force the block to have a nice indentation. The fact that an infix operator can not be placed at the begin of a line to continue previous line makes things really frustrating for me sometimes.