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.
Comments
- August 17, 2010, Michael Ekstrand wrote: 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.
- August 17, 2010, Robert Fischer wrote: 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.
- August 17, 2010, Marc wrote: Why not use JavaCC and JJTree?
- August 17, 2010, Robert Fischer wrote: 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.)
This post was by Robert Fischer, written on August 17, 2010.
Comment on this post: http://enfranchisedmind.com/blog/posts/ashlar-and-assumptions/#respond
Public Permalink: http://enfranchisedmind.com/blog/posts/ashlar-and-assumptions/
This article was a post on the EnfranchisedMind blog. EnfranchisedMind Blog by Robert Fischer, Brian Hurt, and Other Authors is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.
