Ashlar and Assumptions August 17, 2010 | 08:47 pm

A few years back, I started exploring programming language implementations. Generally, I wanted to understand the kind of decisions and trade-offs that programming language designers make: specifically, I was curious as to why Scala made some of the decisions that they did, and so I went down the road of trying to build a language that “fixed” what I perceived to be issues in Scala. That language was called Cornerstone.

After a while, I discovered that there are good reasons why Scala does things the way it does. In those “fixes”, what I was asking for was basically having my cake and eating it, too. Cornerstone was born of naiveté, and so while it was a wonderful educational opportunity, it was a stillborn language.

With lessons learned, I reconsidered my approach and started in on a new language, Ashlar. In my free time this summer, as a counter-balance to the pastoral/ministerial work I was doing, I cranked on Ashlar. It’s still just getting started, but a big hurdle has been crossed: the runtime is up and running, and the compiler infrastructure is in place. The functional test of printing “Hello, World” has gone from red to green. By request, I’ve added a bit of a description up on the Ashlar wiki, so go check it out.

In particular, there is an extensive conversation about the assumptions of Ashlar. Let me know what you think about that: I’m very curious.

  • Michael Ekstrand

    Thank you for documenting the assumptions and explicitly positioning Ashlar in that way – it makes a lot of sense, and is refreshingly honest that Ashlar isn’t intended to be the final programming language for everything.

    In general, I think the assumptions are pretty reasonable. About the only one that I have difficulty with with is the memory usage one. While memory is (generally) cheap, exorbitant memory usage does become a problem for cloud deployment where your rented VM may well have 256, 512, or 1024 MB of RAM rather than a few gigs to keep the web app server happy.

  • Robert Fischer

    Yeah, we’ll see how the memory stuff works out. I’d like the language to be reasonably sized even for virtual machines (distributed processing is one of they targets for Ashlar), but there’s a fair bit of infrastructure that’s coming with the language and I’m not willing to sacrifice it.

    We’ll see how this works out.

  • Marc

    Why not use JavaCC and JJTree?

  • Robert Fischer

    I am using JavaCC and JJTree. See the currently-gutted *.jjt here and a previous take on a JJTree implementation here. (Dear Future: If those links are failing, it’s because I moved the compiler to its own subproject.)