

Ask HN: How to start programming language design? - poseid

Hello,<p>as far as I know, programming started out with translating expressions like:<p><pre><code>    (number) (operation) (number) := (result)
</code></pre>
Now, I want to understand a bit more on programming language principles, but reading references quickly results into discussion of abstract algebra.<p>So here is my question: How can I start designing simple programming languages?<p>What are some simple, but useful grammars to understand programming language principles?<p>What are these &quot;treetop&quot; like parsing libraries about, and are these for beginners or advanced users?
======
EdwardCoffin
You should probably spend some time browsing through Lambda the Ultimate [1],
a discussion forum devoted to this kind of thing (it is very academic though).

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](http://lambda-the-ultimate.org)

[2]
[http://thread.gmane.org/gmane.comp.lang.lightweight/2547/foc...](http://thread.gmane.org/gmane.comp.lang.lightweight/2547/focus=2552)

------
wilsonfiifi
You could take a look at Marc Cournoyer's course
[http://createyourproglang.com](http://createyourproglang.com), check out the
compiler course on Cousera
[https://www.coursera.org/course/compilers](https://www.coursera.org/course/compilers)
and watch Rob Pikes talk on lexical scanning
[http://www.youtube.com/watch?v=HxaD_trXwRE.b](http://www.youtube.com/watch?v=HxaD_trXwRE.b)

That should get you going. Oh and don't forget to have a look at Go language
specification as well.

~~~
poseid
what makes the go language a good example?

~~~
hariharan_uno
The language spec is very short compared to others.

------
chton
For some quick hands-on learning, it might be interesting to read up on
Resursive Descent Parsers
([http://en.wikipedia.org/wiki/Recursive_descent_parser](http://en.wikipedia.org/wiki/Recursive_descent_parser)).
They're easy to understand and easy to code in a language of your choice. Once
you have a working one, you can expand it to experiment with your own grammar.
Spend some time experimenting that way and you'll be able to get a lot of
insight in what the pitfalls of language design are and how you can work with
your parser to minimize them.

~~~
poseid
thanks! do you have some tool that you would recommend to run programs with
these grammars. e.g. I have

    
    
       calculator.ycomb
    

and a ycomb grammar.

which programs would you recommend to get an output of calculator.ycomb ?

~~~
chton
honestly, I would recommend you write your own parser for it. A grammar is
meaningless by itself, and you'll learn a lot more about why yours might work
or not work if you do the work yourself.

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.

~~~
poseid
interesting advice to get hands dirty with source code directly. I might think
to experiment a bit with C/lexx/yacc then.

one thing, I am curious about, what are the kind of "hello_world()" functions,
that would print something on a screen... hmm..

~~~
chton
Getting in on the ground floor tends to be my advice for a lot things. It's
hard to make something click if you can't see it work in the flesh.

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:

    
    
      print myVar
    

and Java:

    
    
      System.out.println(myVar);
    

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 :)

------
CmonDev
Check the next generation approach for a modern IDE:

[http://blog.jetbrains.com/blog/2014/05/27/nitra-goes-open-
so...](http://blog.jetbrains.com/blog/2014/05/27/nitra-goes-open-source)

[https://github.com/JetBrains/Nitra](https://github.com/JetBrains/Nitra)

~~~
poseid
with Nitra, how would a "hello_world()" of a programming language print
something to the screen?

------
sprobertson
Here's the best "hands-on" introduction I've seen:
[http://nathansuniversity.com/](http://nathansuniversity.com/)

He walks you through the basics of compiling, parsing, and interpreting to
create your own scheme-like language (complete with exercises along the way).

