DEV Community

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

 
mortoray profile image
edA‑qa mort‑ora‑y

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

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!