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.
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?
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:
> 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.
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
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.
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).
>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.
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.
I think continuation-based web frameworks are a bad use case. It's a leaky abstraction in the same way as wiewstate in ASP.NET: It tricks you into believing that you can write a web app like a traditional stateful application. But all kinds of subtle problems with caching, bookmarks, the back button, search engines and so on crops up.
But continuations are really cool for implementing language features like backtracking.
Viewstate may be bad but it works and .NET developers have figured out how to use it safely and efficiently (ok some .NET developers have).
As for continuation-base web frameworks being a bad use case. I think they are a bad use case in some ways. You make good points. I think the concept is very new. This site is implemented with continuations and it works pretty well. So it's possible to have a successful site. And the current iterations have their problems, no doubt. But that doesn't mean the concept and idea is dead. It's an elegant solution from a coding standpoint - when it works. My point was that continuations could have other uses than the traditional list (backtracking,coroutines,multitasking,escape/enter recursion, etc). And if they do, then M$ is more likely to add them. M$ is not going to add continuations so that a small percentage of their developers will have an easier time implementing backtracking. But, they may very well add continuations if their web developers want them. Or if a large number of people are using IronPython or IronRuby.
> This site is implemented with continuations and it works pretty well.
I believe it uses persistent closures, not persistent continuations. And anyway, it often fails with the message "Unknown or expired link." (because you cant keep all the closures alive indefinitely - but you have to, otherwise you break the web!) This wouldn't be acceptable for most sites.
In any case, I don't think MS would add continuations to .net specifically to support continuation based web frameworks. The model with persistent continuations (or persistent closures for that matter) is at odds with the threading model in IIS, where the server is supposed to spawn multiple threads running the same application code. And IIS is strategic to MS.
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.
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.
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 :)
For all those Python coders - IronPython is usable in production now. It's stable and the differences between cpython and ironpython are well documented.
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.
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/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.