Hacker News Reader

Comment by titzer | Hacker News Reader

As someone who has worked on a systems programming language for a long time, my strongest advice would be to avoid trying to make syntactic or semantic choices that are just different unless they're really motivated by making the systems aspect better, or to make the language more self-coherent. Having surprises and syntax to learn is a barrier to entry and probably won't impress anyone.

That is to say, do focus on systems problems. Key ones I identified are efficient data representation, avoiding needless memory churn/bloat, and talking directly to lower-level software/hardware, like the kernel.

Focus on systems programming and not on syntactic niceties or oddities.

View on HN

Yes, I also found the description a little weird because of the emphasis on linear-time parsing. It is cool theoretically, and it could be understandable from a perspective of "make the compiler fast", but parsing is never the bottleneck in modern compilers. For a systems programming language this seems to be the wrong emphasis.

Yes, I would go the opposite in terms of simplicity.

Parse once for syntax and symbol definition, 2nd pass over parsed structure to link symbol references to their definitions. Two uncomplicated passes.

That handles a general code graph - so the language can go anywhere, and never be fundamentally held up by limitations of early syntax/parsing decisions.

While working on my systems PL, Cwerg, I adopted a "syntax last" approach:

For the longest time the syntax was just glorified s-exprs. This made it much easier to focus on the semantic choices and improved iteration times and willingness to experiment since the parser changes were always trivial.

I highly recommend this approach for new PLs.

The danger is you might decide to just keep the s-exprs.

I almost did ;-)

I added a few improvements to help with legibility which made it bearable to program with sexpr.

But arithmetic expressions and (chaining of) unary operators was just too painful, e.g.

(= (. (^ ptr) file) ...)

instead of

ptr^.field = ...

Interesting.

For Virgil, I started with mostly Java/C syntax, but with "variable: type" instead of "type variable", because it was both easier to parse and was more like standard ML and what you encounter in programming language theory. That syntax was already catching on, so I felt like I was swimming with the stream. I initially made silly changes like array indexing being "array(index)" instead of "array[index]", which turned out to be annoying to just take random code and change all the "[" to "(" and "]" to ")". Also, I had keywords "method" and "field", but eventually decided things looked better as "def" and "var", because they were easier to eyeball and readily understandable to people who write JavaScript (and Scala, as it turns out).

Overall Virgil's syntax is a kind of an average of all the curly braced languages and where it differs at all, it's been to make things more composable and avoid cryptic line-noise-looking things. For example, to allocate an object of class C, one writes "C.new(args)", because that can be understood as "C.new" as a function applied to "(args)"--so one can easily write "C.new" and yes, indeed, that's a first class function. That works with delegates and so on. So I don't regret not exactly matching the "new C()" you'd find in Java or C++.

This reminded me of two other recommendations:

1) write a pretty printer early on (I had one for the s-expr based syntax and one for the concrete syntax I introduced later) This will allow you to automatically apply the syntax changes on the example code you have written in your PL with only very little programming

2) instead of parser generators use recursive descent + Pratt parsing Pratt parsing is a little bit magical at first but it is easy to develop a working intuition without understanding all the details of the algorithm.

Reply on news.ycombinator.com