4 ms·

Iron Scheme: Scheme implementation running on .NET

21 points by iamelgringo 18y ago

trezor 18y ago
I must admit when Microsoft first introduced the .NET Framework and called .NET-code "language independent", I thought it was a bit of a grand statement and chuckled away, since that pretty much involved C# and Visual Basic .NET. Right now I think even Microsoft is impressed with number of CLR compilers and level of support the .NET Runtime has gathered. You have C++, C#, Visual Basic, PHP, Perl, Python, Ruby, Cobol(!), LISP and the list just goes. And with Scheme now, it just got a little bit longer. I guess even among the open-source crowd there are significant numbers of people who recognizes the good products Microsoft delivers every now and then :)
- jmatt 18y ago
  Here is a mostly complete list of .NET languages. http://en.wikipedia.org/wiki/.NET_languages http://en.wikipedia.org/wiki/.NET_languages For all those Python coders - IronPython is usable in production now. It's stable and the differences between cpython and ironpython are well documented.
  - Daemmerung 18y ago
    And for Schemes on .NET, in addition to the listed Common Larceny (http://www.ccs.neu.edu/home/will/Larceny/ http://www.ccs.neu.edu/home/will/Larceny/) and IronScheme, there is also Bigloo (http://www-sop.inria.fr/mimosa/fp/Bigloo/ http://www-sop.inria.fr/mimosa/fp/Bigloo/). Common Larceny uses the pkcfm hack for its continuations, I believe, while Bigloo continuations are more like IronScheme's ("Bigloo discourages the use of call/cc" - from the manual). Disclaimer: I have personal experience with neither system.
tjr 18y ago
From http://www.cs.uiowa.edu/~rjhansen/dotnet.html http://www.cs.uiowa.edu/~rjhansen/dotnet.html I asked Professor Abelson whether Scheme could be represented in the .NET virtual machine. His answer was a clear and unambiguous “no”. Most of the language can be; but one of Scheme’s most useful and unique facilities, continuations, cannot be modeled in .NET’s VM. It’s not that nobody’s done it yet; it’s that it’s not possible. Is this still true? Has .NET been sufficiently updated to allow full Scheme?
- trezor 18y ago
  Too answer the obvious first: First statement was obviously false, as seen by this implementation. As for your second question, the answer is yes and no. More specifically: .NET supports runtime generation of code, types and classes. In fact you can write a .NET compiler using built in .NET classes. This is all enabled by the Reflection capabilities built into the framework, which also allows execution of generated code. However the .NET framework and the .NET runtime has not been altered in any way to accommodate Scheme. IronScheme builds upon the DLR (Dynamic Language Runtime) which runs on top of the .NET CLR (Common Language Runtime). So basically a runtime upon runtime if you like. The DLR was developed to allow for languages like IronPython and IronRuby. What the DLR does is allowing more functional languages with dynamic typing to run on top of the somewhat strict CLR. It seems the work done on the DLR has made what your professor claimed was impossible possible, and he simply lacked the imagination needed to envision a DLR running on top of the CLR. Edit: Looking at the linked article, this is from back in 2003. The "2.0" languages (added syntax features, new compiler) came with the .NET Framework version 2.0 in 2005. This allowed for more flexible syntax and may be the source of your professors error. In other words: His statement may hold true for the version 1.x VM.
  - tjr 18y ago
    In other words: His statement may hold true for the version 1.x VM. Thank you for your explanation. I have not really followed .NET development, nor did I take the time to search out an answer before asking my question; apologies for laziness.
- jcl 18y ago
  From http://www.infoq.com/news/2008/01/leppie-ironscheme http://www.infoq.com/news/2008/01/leppie-ironscheme: 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. So it sounds like the professor's statement may still be correct in the sense that IronScheme's continuations don't have the full range of functionality that Scheme's continuations do. Another blog post implies that Microsoft's Dynamic Language Runtime (DLR) -- on which IronScheme is written -- is unlikely to get this functionality in the near future: From http://wp.colliertech.org/cj/?p=175 http://wp.colliertech.org/cj/?p=175: When speaking with Jim Hugunin, it sounded as if he would prefer to avoid including support for continuations in the DLR.
Daemmerung 18y ago
Is this still true? Has .NET been sufficiently updated to allow full Scheme? This is no longer true: not because of any change in the VM, but because of a new way to model first-class continuations. Qv "Continuations from Generalized Stack Inspection", http://www.cs.brown.edu/~sk/Publications/Papers/Published/pcmkf-cont-from-gen-stack-insp/ http://www.cs.brown.edu/~sk/Publications/Papers/Published/pc... - Implementing first-class continuations can pose a challenge if the target machine makes no provisions for accessing and re-installing the run-time stack. In this paper, we present a novel translation that overcomes this problem. In the first half of the paper, we introduce a theoretical model that shows how to eliminate the capture and the use of first-class continuations in the presence of a generalized stack inspection mechanism. [...] Second, we show how to use our new technique to copy and reconstitute the stack on MSIL.Net using exception handlers. This establishes that Scheme's first-class continuations can exist on non-cooperative virtual machines.
- jmatt 18y ago
  I link to the same paper - different repository in my comment. Excellent quote.

21 points by iamelgringo 18y ago

I must admit when Microsoft first introduced the .NET Framework and called .NET-code "language independent", I thought it was a bit of a grand statement and chuckled away, since that pretty much involved C# and Visual Basic .NET. Right now I think even Microsoft is impressed with number of CLR compilers and level of support the .NET Runtime has gathered. You have C++, C#, Visual Basic, PHP, Perl, Python, Ruby, Cobol(!), LISP and the list just goes. And with Scheme now, it just got a little bit longer. I guess even among the open-source crowd there are significant numbers of people who recognizes the good products Microsoft delivers every now and then :)

jmatt 18y ago
Here is a mostly complete list of .NET languages. http://en.wikipedia.org/wiki/.NET_languages http://en.wikipedia.org/wiki/.NET_languages For all those Python coders - IronPython is usable in production now. It's stable and the differences between cpython and ironpython are well documented.
- Daemmerung 18y ago
  And for Schemes on .NET, in addition to the listed Common Larceny (http://www.ccs.neu.edu/home/will/Larceny/ http://www.ccs.neu.edu/home/will/Larceny/) and IronScheme, there is also Bigloo (http://www-sop.inria.fr/mimosa/fp/Bigloo/ http://www-sop.inria.fr/mimosa/fp/Bigloo/). Common Larceny uses the pkcfm hack for its continuations, I believe, while Bigloo continuations are more like IronScheme's ("Bigloo discourages the use of call/cc" - from the manual). Disclaimer: I have personal experience with neither system.

tjr 18y ago

From http://www.cs.uiowa.edu/~rjhansen/dotnet.html http://www.cs.uiowa.edu/~rjhansen/dotnet.html I asked Professor Abelson whether Scheme could be represented in the .NET virtual machine. His answer was a clear and unambiguous “no”. Most of the language can be; but one of Scheme’s most useful and unique facilities, continuations, cannot be modeled in .NET’s VM. It’s not that nobody’s done it yet; it’s that it’s not possible. Is this still true? Has .NET been sufficiently updated to allow full Scheme?

trezor 18y ago
Too answer the obvious first: First statement was obviously false, as seen by this implementation. As for your second question, the answer is yes and no. More specifically: .NET supports runtime generation of code, types and classes. In fact you can write a .NET compiler using built in .NET classes. This is all enabled by the Reflection capabilities built into the framework, which also allows execution of generated code. However the .NET framework and the .NET runtime has not been altered in any way to accommodate Scheme. IronScheme builds upon the DLR (Dynamic Language Runtime) which runs on top of the .NET CLR (Common Language Runtime). So basically a runtime upon runtime if you like. The DLR was developed to allow for languages like IronPython and IronRuby. What the DLR does is allowing more functional languages with dynamic typing to run on top of the somewhat strict CLR. It seems the work done on the DLR has made what your professor claimed was impossible possible, and he simply lacked the imagination needed to envision a DLR running on top of the CLR. Edit: Looking at the linked article, this is from back in 2003. The "2.0" languages (added syntax features, new compiler) came with the .NET Framework version 2.0 in 2005. This allowed for more flexible syntax and may be the source of your professors error. In other words: His statement may hold true for the version 1.x VM.
- tjr 18y ago
  In other words: His statement may hold true for the version 1.x VM. Thank you for your explanation. I have not really followed .NET development, nor did I take the time to search out an answer before asking my question; apologies for laziness.
jcl 18y ago
From http://www.infoq.com/news/2008/01/leppie-ironscheme http://www.infoq.com/news/2008/01/leppie-ironscheme: 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. So it sounds like the professor's statement may still be correct in the sense that IronScheme's continuations don't have the full range of functionality that Scheme's continuations do. Another blog post implies that Microsoft's Dynamic Language Runtime (DLR) -- on which IronScheme is written -- is unlikely to get this functionality in the near future: From http://wp.colliertech.org/cj/?p=175 http://wp.colliertech.org/cj/?p=175: When speaking with Jim Hugunin, it sounded as if he would prefer to avoid including support for continuations in the DLR.

Daemmerung 18y ago

Is this still true? Has .NET been sufficiently updated to allow full Scheme? This is no longer true: not because of any change in the VM, but because of a new way to model first-class continuations. Qv "Continuations from Generalized Stack Inspection", http://www.cs.brown.edu/~sk/Publications/Papers/Published/pcmkf-cont-from-gen-stack-insp/ http://www.cs.brown.edu/~sk/Publications/Papers/Published/pc... - Implementing first-class continuations can pose a challenge if the target machine makes no provisions for accessing and re-installing the run-time stack. In this paper, we present a novel translation that overcomes this problem. In the first half of the paper, we introduce a theoretical model that shows how to eliminate the capture and the use of first-class continuations in the presence of a generalized stack inspection mechanism. [...] Second, we show how to use our new technique to copy and reconstitute the stack on MSIL.Net using exception handlers. This establishes that Scheme's first-class continuations can exist on non-cooperative virtual machines.

jmatt 18y ago
I link to the same paper - different repository in my comment. Excellent quote.