Proposal: Don't use a toy language

[madmalik]

My understanding from reading the other issues is: The idea of the book is that different concepts are explored and demonstrated with a simple toy language.

I see where this is coming from, but imo it leaves out the most important step in the process: Setting real requirements. If choices between bytecode formats or garbage collection strategies are arbitrary for the provided example, it's not really an example for a meaningful choice. Also it removes the accountability that these choices where actually the right ones.

I get that we don't want to be buried in too much detail, but i think that the semantic complexity of an embeddable dynamic language build for real world usage is not that much greater than a toy language that actually shows anything interesting.

The one thing that would be vastly more complex is the "chapter" about language design itself and all the parsing stuff, at least in comparison to the proposed s-expression based language. I propose to just leave that stuff out and replace it with a textual intermediate representation that is effectively an assembler for the bytecode. A chapter about parsing a super simplified language that we actually don't want to write and that is not the focus of the book has probably not that much value anyway.

[pliniker]

I do think you're right about not making a toy language, I agree that the end-goal should be runtime code that can host a language with real-world requirements. The point about using an s-expression based language is that it gives minimal emphasis to syntax and parser design when the focus is on implementing a runtime, it doesn't necessarily imply a toy language.

What specific requirements would you like to see? Edit: a lot of that discussion is on the wg issues, of course, and would best be continued there.

[madmalik]

What specific requirements would you like to see? Edit: a lot of that discussion is on the wg issues, of course, and would best be continued there.

Basically that. Use the progress and the decisions in the wg to inform the book and use the book to document the stuff we build in the wg.

The point about using an s-expression based language is that it gives minimal emphasis to syntax and parser design when the focus is on implementing a runtime, it doesn't necessarily imply a toy language.

I'm totally on board with de-emphasise the surface level design. But even when that part is simplified it is a distraction from the rest and does not provide much value in itself. Imo, leaving it out completely would be a better solution.