IronLisp compliance

I read some interesting feedback on reddit.com. Although I havent seriously looked into it, IronLisp would ideally compliant to some form of LISP. That leaves me 2 choices: Common LISP and Scheme. As for the former, there are just under 1000 functions in the ‘spec’. Learning them and implementing them would be ongoing venture beyond my expected lifetime. As for the latter (Scheme), it presents a much cleaner approach, with almost a tiny ‘core’ and using that as building block.

Another aspect mentioned was library support. Again, learning the entire LISP library(s) to get an idea of the implementation will be too great task for me. Having worked (almost exclusively) on the .NET Framework ‘library’ for the last 6 years, it is pretty much the only library I am really comfortable with. My idea with IronLisp is to let the .NET framework provide all the common libraries, and hence any .NET user can just learn a new syntax to use it practically. That will also keep IronLisp small and manageable.

Getting back to Scheme. Ideally IronLisp at some future time, will support/comply to some degree of Scheme, or will have a compatibility mode, or have macros to make it syntax (and functionally) compatible. With this in hand, hopefully IronLisp would be capable of running Scheme libraries.

Unfortunately, Scheme has no defined test suite, but the specification is rather unambiguous, and smaller in total than the Common LISP’s index!

Rate this:

Like this:

LikeLoading...

Related

Responses

Interesting — thanks for the update. If you wanted to be Scheme-compatible, but not initially, it might make more sense to implement the core functionality (which would be similar) and then split off an IronScheme project once the shared components were relatively stable.

Scheme does have a nice, small spec; OTOH that spec doesn’t define a terribly capable language (the various Scheme implementations, of course, can be as capable as they want to be). Moreover, it hasn’t really learnt from the decades of experience of the Lisp community; the product of those decades of experience was a common Lisp platform–or Common Lisp. Not that Scheme’s a bad language at all; it’s neat, and cool, and definitely easier to implement than a Common Lisp.

But I think that in the long run it’s much nicer to have Common Lisp at one’s fingertips than Scheme.

The nice thing is that once you have a Scheme you can start work on building Common Lisp…

As for libraries… the experience with IronPython was that making it comply ever more closely to ‘normal Python’ enabled more and more ‘pure Python’ libraries to ‘just work’. (And existing libraries made very good testcases for IronPython.)

For the libraries implemented in C, the IronPython team did re-implement some in C# and the community has created ‘compatible wrappers’ around similar .NET libraries for others.

I wonder if ILisp should present it’s self as a variant of Lisp based of say a Scheme syntax. Aiming for CL compliance (to the standard) would be a massive job and Lispers would prehaps expect nothing less than compliance. This would allow you experiment a little too (if you so wished).