DEV Community

loading...

Discussion on: Help design a language: What about tuples without commas?

Collapse
jrop profile image
Jonathan Apodaca

I have been thinking about implementing this in my language as well, but I remain undecided as I already have implemented significant newlines if the next token is an operator on the "line-continuation" whitelist. I really like tuples without commas, but I fear this may muddy my syntax further (in my case). So I guess the answer is it depends on the current syntax!

Collapse
mortoray profile image
edA‑qa mort‑ora‑y Author

I chose to limit line continuation to only paired syntax, (...), {...}, and [...]. I was worried that operators continuing lines can lead to ambiguity and also make it a bit harder to read.

In Leaf a new-line is always significant in this regards, It's never ignored and always has some meaning.

Collapse
jrop profile image
Jonathan Apodaca

That is an interesting take on a very polarizing issue. I quite like it. So you are saying that I cannot split an expression across lines, but if I want to, I can surround it in parenthesis? Cool.

I chose to have "context-aware" newlines, so this works:

some
  .very(...)
  .long(...)
  .method(...)
  .chain(...)

The following are not "whitelisted" infix operators: (, [. So the following works as expected:

var x = y
(z)
// is equivalent to:
var x = y;
(z);
Thread Thread
mortoray profile image
edA‑qa mort‑ora‑y Author

The splitting across lines works with a common syntax style, which will basically become the defacto approach:

some.very(
  args
).long(
  args
).method(
  args
).chain(
  args
)

I'm tempted to make . a continuation operator as well though, but it will have to occur on the previous line:

some.
  very(...).
  long(...).
  method(...).
  chain(...).

The core idea is that continuation to the next line is decided solely on the current line, it never looks to the next line. This avoids a lot of ambiguity and avoids doing lookahead in the parser.

Thread Thread
jrop profile image
Jonathan Apodaca

That is how Golang approaches it, and it seems to work well for them. In that respect, as long as you have a good, standardized code formatter (leafmt?) then I think that solution will work quite well.

I am a compiler noob, and this is what gets me: TBH, the concept of writing a compiler is not too bad, but what quickly spirals downhill are (a) too many choices to make, and (b) so many things to implement. It's hard to stay motivated, but rewarding to see things begin to come together and work.

Thread Thread
mortoray profile image
edA‑qa mort‑ora‑y Author

I this case I don't need a formatter, since if the continuation format is wrong it won't compile. :)

That in mind, I've kept the syntax simple to parse to make it easy to write formatters and high-level tools. The language can be parsed and manipulated without really knowing the semantics of it.

It takes a long time to create a language that does something useful. I'm finally at the point where I can do stuff. I've decided to use SDL and start doing graphics, to keep it interesting. Simple games in particular for now.

Thread Thread
jrop profile image
Jonathan Apodaca

You still may benefit from a formatter. Imagine the case where the user types:

some .
  very( anArg).
  longMethodChain  ()

It would still be nice to normalize it and remove the unnecessary whitespace (assuming that the above is not a lexer error):

some.
  very(anArg).
  longMethodChain()

That's awesome that it's in a workable state! I look forward to following your development!

Forem Open with the Forem app