On Tue, Jul 30, 2013 at 5:28 AM, Ian P. Cooke <i...@informatic.io> wrote:
> I'm really not. I'm making a set of brutal and hopefully mostly-objective > culling rules for the minimum viable systems programming language must > include. In C we can author Python, and twisted, and stackless without > stop-the-world so C seems like it does not have any achilles heel WRT this > issue. We can't say the same about JVM. > > I think we could with a HotSpot patch: > http://classparser.blogspot.com/ > Thanks for the reference, this looks like really good work. I prefer this kind of "stack-freezing" coroutine implementation as I think it's more practical than stackless stack-frames in many ways. I wish C# async had used something like this instead of the viral-keyword compiler-generated coroutine-simulation they decided on. Digging a little I found this experimental CLR coroutine implementation, though it's unclear how 'real' it is: http://msdn.microsoft.com/en-us/magazine/cc164086.aspx I agree continuations are not a required language feature for a minimal > language although I believe the ability to implement them in a library > without runtime modification should be a requirement. > Agreed, and this is exactly the kind of thing my rule #3 is about. If we can't implement co-routines, and it doesn't provide coroutines, then the only way to write our coroutine applications is to abandon the runtime -- which makes it a pretty limited systems programming environment to me. This is part of why managed systems runtimes are hard. Your additional comment that we should be able to do it *without runtime modification* is very important. It's easy to step back and say "hey, it's theoretically possible to add coroutines, and C4, and all these other things with the same language and vm-instruction-set, by hacking the runtime. So that's our systems runtime, right?" The trouble is, in practice this theoretical possibility isn't useful. Even if there are implementations of coroutines and C4 for the runtime, they are not necessarily compatible. Further, if I develop components which require them, other installations do not use that modified runtime, and in fact they could use a different modified runtime with changes of their own. Thus the whole "systems runtime" notion degenerates, as we are each building our own isolated embedded systems.
_______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev