4 ms·

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

by 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.
olavk 18y ago
Under "Future directions" (http://www.codeplex.com/IronScheme/Wiki/View.aspx?title=Roadmap&referringTitle=Home http://www.codeplex.com/IronScheme/Wiki/View.aspx?title=Road...): > Complete support for inward continuations (if this is ever possible on the CLR). So it seems the jury is still out on the issue. The CLR does not support continuations natively. It could be implemented be writing an interpreter on top of it, but that would be slow. Perhaps they could be implemented by eschewing the CLR built-in stack and call, and instead compile everything into jumps or tail calls and keep a separate stack? I'm not sure if this is possible though.
jmatt 18y ago
Continuations are absolutely possible. This is absurd that your professor isn't staying up to date. Especially considering he's teaching a PL class. See Section 4.2 for academic "proof" http://www.ccs.neu.edu/scheme/pubs/icfp05-pcmkf.pdf http://www.ccs.neu.edu/scheme/pubs/icfp05-pcmkf.pdf When .NET clr and C# beta first came out, closures were said to be impossible! C# 2.0 supports lexical closures and CPS (continuation passing style). So no call/cc but most everything else. Most developers don't even know the difference between closures and continuations to begin with. So I understand the compiler team's reasons for not implementing continuations yet. But back in 2001 - 2002 closures were said to be impossible too. Mono has implemented continuations already... (of course) http://lists.ximian.com/pipermail/mono-devel-list/2006-April/017991.html http://lists.ximian.com/pipermail/mono-devel-list/2006-April... .NET clr does not explicitly support them. Neither does the jvm. The jvm is planning on explicitly adding support http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6655643 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6655643 There are plenty of things missing in the jvm (by design). That the clr has and some of those have ended up being useful. I don't know how many developers remember but the clr really pushed changes to the jvm. But that is for a different thread. Microsoft will support continuations and other advanced features as more developers begin to use those coding styles. The more .NET scheme, python, ruby developers the better. Or maybe the pressure will come from the web development side where continuations are promising (weblocks, arc, seaside). [EDIT: A few sentences and fixing grammar]
- Zak 18y ago
  >This is absurd that your professor isn't staying up to date. Especially considering he's teaching a PL class The afformentioned professor Abelson is one of the authors of the Wizard Book. A look at the above citation reveals that he made the statement in 2003, while the paper your reference was published in 2005.
  - jmatt 18y ago
    Ya I've read it along with most anyone that has had an interest in programming languages and went to school in the last 20 years. It doesn't make his statement less absurd. I was doing undergraduate research on .NET in 2003 and it was absurd when I first heard it. Academics were upset that M$ made a pragmatic IL. One that didn't support many advanced languages features. That didn't mean implementing those features wasn't possible. It just meant it was yet another step back for features making it to the M$ environment. It should be noted that Parrot was getting a lot of talk back then. It would be THE intermediate language for all languages dynamic or functional... Maybe it makes sense to start pragmatic, like the jvm and .NET, and then add the harder part later.

by tjr 18y ago

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.

olavk 18y ago

Under "Future directions" (http://www.codeplex.com/IronScheme/Wiki/View.aspx?title=Roadmap&referringTitle=Home http://www.codeplex.com/IronScheme/Wiki/View.aspx?title=Road...): > Complete support for inward continuations (if this is ever possible on the CLR). So it seems the jury is still out on the issue. The CLR does not support continuations natively. It could be implemented be writing an interpreter on top of it, but that would be slow. Perhaps they could be implemented by eschewing the CLR built-in stack and call, and instead compile everything into jumps or tail calls and keep a separate stack? I'm not sure if this is possible though.

jmatt 18y ago

Continuations are absolutely possible. This is absurd that your professor isn't staying up to date. Especially considering he's teaching a PL class. See Section 4.2 for academic "proof" http://www.ccs.neu.edu/scheme/pubs/icfp05-pcmkf.pdf http://www.ccs.neu.edu/scheme/pubs/icfp05-pcmkf.pdf When .NET clr and C# beta first came out, closures were said to be impossible! C# 2.0 supports lexical closures and CPS (continuation passing style). So no call/cc but most everything else. Most developers don't even know the difference between closures and continuations to begin with. So I understand the compiler team's reasons for not implementing continuations yet. But back in 2001 - 2002 closures were said to be impossible too. Mono has implemented continuations already... (of course) http://lists.ximian.com/pipermail/mono-devel-list/2006-April/017991.html http://lists.ximian.com/pipermail/mono-devel-list/2006-April... .NET clr does not explicitly support them. Neither does the jvm. The jvm is planning on explicitly adding support http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6655643 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6655643 There are plenty of things missing in the jvm (by design). That the clr has and some of those have ended up being useful. I don't know how many developers remember but the clr really pushed changes to the jvm. But that is for a different thread. Microsoft will support continuations and other advanced features as more developers begin to use those coding styles. The more .NET scheme, python, ruby developers the better. Or maybe the pressure will come from the web development side where continuations are promising (weblocks, arc, seaside). [EDIT: A few sentences and fixing grammar]

Zak 18y ago
>This is absurd that your professor isn't staying up to date. Especially considering he's teaching a PL class The afformentioned professor Abelson is one of the authors of the Wizard Book. A look at the above citation reveals that he made the statement in 2003, while the paper your reference was published in 2005.
- jmatt 18y ago
  Ya I've read it along with most anyone that has had an interest in programming languages and went to school in the last 20 years. It doesn't make his statement less absurd. I was doing undergraduate research on .NET in 2003 and it was absurd when I first heard it. Academics were upset that M$ made a pragmatic IL. One that didn't support many advanced languages features. That didn't mean implementing those features wasn't possible. It just meant it was yet another step back for features making it to the M$ environment. It should be noted that Parrot was getting a lot of talk back then. It would be THE intermediate language for all languages dynamic or functional... Maybe it makes sense to start pragmatic, like the jvm and .NET, and then add the harder part later.