IronScheme

IronScheme
Preview release 1.0 RC6 / March 22, 2012
Platform .NET
Website ironscheme.codeplex.com

IronScheme is an implementation of the Scheme programming language targeting the Microsoft .NET framework. IronScheme is a complete rewrite of IronLisp, incorporating lessons learnt while developing IronLisp.[1]

IronScheme was planning to build upon the Microsoft Dynamic Language Runtime, 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.[2] IronScheme eventually made a limited use of its own version of the Microsoft's DLR, but it had to patch it to be able to implement some required Lisp features like Tail calls.[3][4]

See also

References

  1. ↑ "IronScheme will aim to be a R6RS conforming Scheme implementation based on the Microsoft DLR.". Retrieved 2009-03-21.
  2. ↑ "Is there any silverlight sample?". 2009-05-11. Retrieved 2009-07-26. Unfortunately, my DLR branch is very out of sync with the Silverlight one. I just thought about it, perhaps I do not need the DLR perse, will investigate. The problem is that the DLR as-is, is not good enough to support the majority of the Scheme's requirements
  3. ↑ ".NET Integration with current runtime?". 2010-01-05. Retrieved 2011-08-29. To make IronScheme use the current DLR, I would loose [sic] quite a few language requirements and important features, namely tail calls, and runtime record generation. Both these are not (and probably will never) be supported by the DLR, due to Silverlight compatibility requirements. Currently, IronScheme only lacks reifiable continuations to be 100% RnRS conforming. One could make IronScheme use the current DLR, but then it would not be Scheme anymore, as tail calls are extremely important (and required).
  4. ↑ "Plan to update to current version of DLR?". 2008-05-14. Retrieved 2011-08-29. At the moment I only utilize about 15% of the DLR, and I would love to get rid of it eventually. The path they have chosen to do Python dynamically is too slow, and it lacks features that used to be present in the DLR (the new 'dynamic' features makes compilation to an assembly impossible). There are other features too that I had to build in, like tail calls and direct methods calls, that is also impossible in the latest DLR.

External links