Llewellyn Pritchard, who is also known to the community as Leppie, has actively ported both Scheme and Lisp to the .NET DLR since its release. The results are IronScheme and IronLisp with an integrated development environment added to round out the development experience. InfoQ editors were able to contact Leppie recently to talk about the interesting recent developments he's made in regards to both IronScheme and IronLisp.
James: What is your motivation behind IronScheme as you near the 1.0 release?
Leppie: I have been interested in language technologies from an early point in my programming career. My first introduction to a LISP dialect was LSharp. I was so impressed with this I decided to incorporate it into my ongoing project, xacc.ide. An attempt was made to create a compiler for LSharp, but I never got it working and decided to bin the idea. A few years later I was speaking to the author of LSharp again for another attempt at making a LSharp compiler, this time using LINQ (I still think this is quite possible for a Scheme backend, as Scheme only requires a handful of primitive syntactic constructs). Rob Blackwell (LSharp author) then pointed me to the yet to be released DLR. This got me very excited, and decided to wait for the release. Less than a month passed, the DLR was released and I jumped in head first into exploring it. I didn't really give the design any thought and tried to base it on LSharp. After a month or so of hacking, I went public with IronLisp, yet another dialect of LISP. This proved both good and bad. Good as I received a lot of feedback from the community, bad as I realized no-one wanted another LISP dialect. At that stage LSharp was my only exposure to any form of LISP, and thanks to feedback, it got me introduced to Scheme.
IronScheme is almost a complete rewrite of IronLisp. There are several reasons behind this. I shall just list them all in no particular order.
- Needed to conform (or attempt to conform) to a standard. My choices were Common LISP(CL) or Scheme. I chose Scheme as the specification (R5RS) was only about 50 pages and with only a few hundred procedures/constructs, compared to over 1000 in CL. This proved beneficial as I could focus on the core language and not worry to much about the details. Today, IronScheme attempts to conform the recently finalized R6RS specification. This requires around 700 constructs/procedures, and is about 3 times the size of the previous specification. IronScheme is about 80%-90% complete in terms of the R6RS.
- I made several design flaws in IronLisp, I cant recall them all, but mostly it was trying to make it too much interoperated with the CLR. This was a mistake that had a terrible ripple effect as IronLisp grew, and eventually I was just too frustrated.
- Apply the lessons learnt from IronLisp.
Originally I was only planning on supporting R5RS, but as I was testing various 'macro systems' I found psyntax, which provides the Scheme community with a reference implementation for the syntax-case and library system. To my surprise IronScheme manage to 'swallow' the bootstrap code (for another Scheme, Kawa I think) without issues, and gave me an excellent boilerplate for a R6RS implementation. As psyntax kindly provide implementations for almost all the Scheme 'macros', only a few core macros, procedures and semantics had to be implemented, including a reader/parser (which is part of the specification anyways). The beauty of it, it matches methods in the CLR quite well, and hence most of the library code has been written in C#, although I would like to have it all in Scheme in the future (my limited experience of writing Scheme makes this a very drawn out, but challenging process).
Another big inspiration has been Abdulaziz Ghuloum, one of the authors of psyntax, and the author of Ikarus, a new R6RS compliant Scheme with an implementation that will blow your mind away. It runs about 10-50 times faster than IronScheme at the moment.
James: Who is the audience IronScheme targets?
Leppie: As IronScheme attempts to conform to the R6RS specification, most portable programs should run without problem. I am not really sure who is my target audience is, but I know people like me that want to get friendly with something else other than Ruby or Python, but have a strong .NET background. They should find my work beneficial. Scheme is also a language that is used frequently in the academic sector. It would be nice to see IronScheme being used in a university or college.
Other possible users would include those that would like a general purpose scripting language embedded in their application, but generally end user will find a Python or JavaScript-like language easier. For myself, this will replace LSharp in xacc.ide.
IronScheme is open-source, and hosted on CodePlex.
James: In the past, changes to the DLR have broken dynamic languages, what is your experience with both IronScheme and IronLisp?
Leppie: I have 'frozen' my DLR since about 2 months ago due to breaking changes. Not really breaking the functionality, but more the interface. There was a lot of movement in the structure/naming of the library, constant adding/removing of features. This made reconciling my own changes very difficult, as I needed to fix some bugs and i needed to add some functionality that was missing in the DLR (e.g. tail calls, direct method references, ability to create persisted assemblies, performance hacks). Currently, IronScheme uses only about 20% of the DLR (as determined by NCover). It might be worthwhile investigating the viability of writing a code-generation library from scratch (perhaps written in Scheme itself, using the DLR as a bootstrap).
One thing that might be beneficial is if they actively updated their source repository on CodePlex, but it seems to have only been used for the occasional update.
James: What features will be part of the next release of IronScheme?
Leppie: As said the main focus of the 1.0 release is to conform to R6RS as much as possible. After that the focus will turn to optimization and better interaction between Scheme and the CLR. Also support for arbitrary precision numbers will be added (using GMP), as the CLR has no support for them. The DLR only has (large) integer support.
There are several limitations I have yet to overcome to be able to be 100% compliant, most notably being continuations. Currently IronScheme only supports 'outward' continuations for non-local returns. This is an approach used on the JVM too. I have had a look very recently at how the IronRuby guys are approaching it, callcc only exists as a comment in their code.
James: What features will be part of the next release of IronLisp?
Leppie: I don't think there will be anymore development on IronLisp unless someone wants to take it over. It will probably be better to use IronScheme as base for future versions of IronLisp.
James: What prompted you to create the xacc project?
Leppie: I wanted an MSIL editor. I tried the VSIP package on VS2003, I didn't really like the whole C++ thing, so I tried SharpDevelop. Unfortunately, their editor was not written very well (at that point in time at least), and after a month or so and several rejected suggestions to the SharpDevelop team, I decided $^%&^& them, I am going to write one myself and show it to be better than the rest. And that's exactly (no pun intended) what I did about 4 years ago. xacc stands for XML Attributed Compiler Compiler. I wanted to make a program where you could design your own languages in and have an editor for it at the same time. The scope of this concept was vastly underestimated, and hence has now been 'limited' to an editor that allows you to easily add new languages. Basic syntax highlighting for any arbitrary language can be added in as little as 30 minutes. You can go further and incorporate a parser to do syntax checking, brace-matching and region folding. You can go even further and create an 'AST' for your language and display it in the navigation bar and outline views. The aforementioned can even be used with AutoCompletion (but this does not work so well yet). And finally use a MSBuild file to build a project. Currently C# and Scheme employs most of this design, with about 20 other .NET based languages using the syntax highlighting bits only.
The result after 4 years of development, is a small, fast, customizable editor with quite a lot of features. The latest version's setup file is just over 600Kbytes, it has syntax highlighting for C# that matches the rendering quality of VS2008, and trumps it in editing of big files (10k lines or more). (Interestingly VS2003 handles big files a lot better than the newer versions of VS). Unfortunately, due to length of the development, some infrequently used features like debugging and project support has suffered bit-rot and does not work anymore. These however are only my low priority to do list.
James: How has the community responded to xacc?
Leppie: Unfortunately not much. Not counting my dependencies (and some other 'plugin' code), I have been the sole developer of xacc.ide (same with IronScheme). I wouldn't be surprise if I am the only user :) This is quite convenient on the other hand as I can work on and off on the project without being swamped with bug reports and feature requests.
James: It has been almost 2 years since you have updated xacc, is there a release on the horizon?
Leppie: The 'latest news' on SourceForge might be bit old, but xacc.ide is still being developed actively (with the occasional break of 6 months). In fact the project will probably never be as complete as I want it, there will always be more to do. I have been making several releases (more like SVN builds) lately for IronScheme support, and more will be happening soon. I have a release RSS feed, and have xacc.ide check for new releases when started.
The latest information on IronScheme is now available on CodePlex and is close to a 1.0 release. A hearty thanks to Leppie for this interview with InfoQ and enjoy more great content on .NET Dynamic Languges.