On Pony

With the school year over, I’ve been working on updating this website. In particular, I’ve been working on updating to Hakyll 4. Previously, it was written in Hakyll 3. However, in doing so, I’ve been updating the blog posts I’ve posted previously to literate haskell. This has come to make me realize that I posted several posts on work I was doing on the Pony compiler, and that I never posted about what conclusions those came to.

Pony, for the uninitiated (i.e. those that didn’t read my last posts, as the rest of the initiated consist pretty much exclusively of the 4 people who have done work on Pony), is an augmented C to ANSI C compiler. Pony allows programmers to write, in haskell, a program for transforming abstract syntax trees (ASTs). This means that we can write Domain Specific Languages (DSLs) into C, or write compilers for other languages into C.

However, as I’ve noted in previous posts, writing anything but a transformation from ANSI C ASTs to ANSI C ASTs involves cracking open Pony itself and editing the parser and the AST description. Originally, my BSc project was going to be to fix this, allowing an interface into Pony without cracking Pony itself. I worked on this for about a year, planning on using the notions from Wouter Swierstra’s Data Types a la Carte to fix the parser issue. However, I ran into many issues with this, which I’ve detailed in previous posts. At the time, I was hopeful that I would find a way around this, however, I did not.

Instead, my project changed. One of the major problems with Pony development was that there were no major Pony projects to test things with. So, my project ended up being to provide one in one semester. The project was a DSL for the Composite Operating System developed at my university. This DSL described the ways that components of the system could interface with each other, and inserted dynamic checks to insure that the interfaces were being implemented correctly. I did this the “old-fashioned” way, by cracking apart Pony and changing the internals.

However, this doesn’t mean that I’ve given up on the idea of providing Pony with an interface that can be used without the Pony source. But, I don’t think that Data Types a la Carte will not work with the idea. Proving this, however, is not something that I’m actively working on. Instead, I think that the correct solution would be to change Pony from an extensible compiler to a compiler compiler. Pony should be given two new DSLs that would provide the interface. At the end, Pony would output a program, which would be a compiler from your new language to another.

What would these two DSLs be? One would be a language for describing transformations between ASTs. This might be an internal haskell DSL, or it might be an external DSL. The second, however, would be a declarative parser DSL, similar to that of Happy. However, it would probably be more like that in Ensō. Like the Ensō language, it would automatically generate ASTs and pretty-printers. It would also include a notion of extension, similar to in object-oriented languages.

This would also mean that a project that used a Pony language wouldn’t require Pony to work on. Instead, Pony would only be required to develop the Pony language itself. This could potentially be a large benefit.

However, it should still be possible to create a truly extensible parser in Haskell. However, the methods are not as pretty as the Data Types a la Carte method. There are two main methods I can think of: 1. Use Template Haskell to write a Parsec for you, similarly to the above. This is really ugly. 2. Write a GHC extension to allow for first-class subtypes (as in Nuprl) and then have, if

A :<: B

then

(Parser A) :<: (Parser B)

However, this requires significant GHC hacking.

I believe that the best option for Pony is to create compiler executable.