IronScheme explained
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.[3]
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.[4] 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 Scheme features like tail call elimination.[5] [6]
See also
External links
Notes and References
- https://www.infoq.com/news/2008/01/leppie-ironscheme/ A .NET Triumvirate: IronScheme, IronLisp, and Xacc
- https://www.infoq.com/news/2009/10/IronScheme/ IronScheme Nears Final Release
- Web site: IronScheme will aim to be a R6RS conforming Scheme implementation based on the Microsoft DLR. . 2009-03-21.
- Web site: Is there any silverlight sample?. 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. 2009-05-11. 2009-07-26.
- Web site: .NET Integration with current runtime? . To make IronScheme use the current DLR, I would loose 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).. 2010-01-05. 2011-08-29.
- Web site: Plan to update to current version of DLR? . 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.. 2008-05-14. 2011-08-29.
