Ask HN: How to start programming language design?
Hello,
as far as I know, programming started out with translating expressions like:
(number) (operation) (number) := (result)
Now, I want to understand a bit more on programming language principles, but reading references quickly results into discussion of abstract algebra.So here is my question: How can I start designing simple programming languages?
What are some simple, but useful grammars to understand programming language principles?
What are these "treetop" like parsing libraries about, and are these for beginners or advanced users?
(
17 comments
| 12 points
| on HN
)
There's a collectively authored set of guidelines "How to Design (Declarative) Programming Languages" [2] posted in comp.lang.lightweight, curated by Scott McKay that you might find useful.
[1] http://lambda-the-ultimate.org
[2] http://thread.gmane.org/gmane.comp.lang.lightweight/2547/foc...
That should get you going. Oh and don't forget to have a look at Go language specification as well.
what about these "PEG" parsers? when/why do they make sense?
http://www.vpri.org/pdf/tr2010003_PEG.pdf
which programs would you recommend to get an output of calculator.ycomb ?
I can't say I know of any good PEG implementations, and even if there were, you'd be limited to what you can express in PEG. A real language can be far broader, encompassing inputs, outputs, complicated functions, etc.
one thing, I am curious about, what are the kind of "hello_world()" functions, that would print something on a screen... hmm..
For the typical functions that print output or take input or the likes, I'm always partial to keeping them separate from the grammar itself. You can see the distinction clearly between for example Python:
and Java: In Python, the print verb is defined in the grammar, and as such needs to be parsed and handled properly. In Java's case, it's regarded as any other method. It's irrelevant to the parser what it does, it just needs to handle it like it would a normal method. This tends to make the whole easier to debug and adapt, since you never need to touch the parser to change behavior of one of these standard methods.This does ofcourse lead to more complex applications, which may not be desirable, depending on the intent of the language. Just my 2 cents :)
http://blog.jetbrains.com/blog/2014/05/27/nitra-goes-open-so...
https://github.com/JetBrains/Nitra
He walks you through the basics of compiling, parsing, and interpreting to create your own scheme-like language (complete with exercises along the way).