views:

108

answers:

1

According to Wikipedia: "IronScheme, an upcoming Scheme implementation, was planning to build upon the DLR, but decided to abandon this idea because the DLR branch the project used became out of sync with the trunk, and also because the DLR, according to the developers, could not support the majority of the Scheme's requirements"

Does anyone know what requirements were not fulfilled and why?

+7  A: 

Originally, one of the big limitations was the ability to generate assemblies. I believe however they did solve that one.

Secondly, I requested support for tail calls, but that never happened, and it an absolute must for Scheme.

Lastly*, the DLR seemed very Python-centric, and had tonnes of functionality not required for Scheme (eg first class environments) which just slowed down things and prevented further optimizations.

Anyways, the plan for version 2, is to rewrite the compiler in Scheme, and then either go barebones with Reflection.Emit, or use a non language centric 'assembler' like the CCI.

*** I am probably forgetting about more

leppie
Great to see an answer straight from the source.
Steve Rowe
I was lucky, saw this 40 seconds after it got posted, sent myself a reminder when I got to work :)
leppie
Thanks a lot for your answer. I would love to know about more limitations.
kunjaan
@kunjaan: I have stripped out about 75% of my DLR, even BigInteger, but mostly I did not need the dynamic typed call site architecture they were pushing at the time. For version 2.0, that would be better suited, given the fact I had time to think how I want to model the underlying runtime, which would be a statically typed scheme for the CLR. The existing IronScheme libraries would just fit on top of that :)
leppie