On Tue, Jul 30, 2013 at 5:06 AM, David Jeske <[email protected]> wrote:
> I know (Shap) supports the end of world-stop, but there is a difference in > our prioritization which some comments from Bennie recently made more clear > to me. > > Authoring and popularizing runtimes is a social effort. Without the deep > pockets of a funding organization, I don't believe that social support will > arrive for a systems runtime unless there is current-proof it has no > achilles heel. That is no world-stop, and no common practical problems > which have unviable CPU and/or memory efficiency. > > Without this proof, I can't be convinced it can even be used for all > application programming problems, let alone systems programming for all > application programming problems. It is effectively a research effort to > learn from not a practical system to use for systems programming. (though > it may be useful for application / embedded system development) > > Because of this, for me, a practical systems-programming system needs to > end the world-stop first and experiment with other ideas second. I believe > Shap's priorities are (currently) different than this. > David: WIth no sarcasm intended, if you really believe I am pursuing the wrong path, you can and should start a project to address the things that you believe are important. I see a range of things that need to be done. Some of them are GC-related and storage management related. Some of them are expressiveness related. Some of them are safety related. Some of them are typing related. No one, or two, or three of these things seems likely to generate a winning systems language. As an example, one of the things we need is a successor to CLI with a type system that supports Nat kind and a modern type system. That needs to be supported by several successor CLR implementations (one per platform of interest) in order to be of interest. On a cell phone, the pause times that concern you simply may not be an issue at all. My problem is that advanced GC implementations and the type systems they support have a way of being intimately connected. I don't think the two problems can be solved in isolation. Just as one example, GC support for unboxed unions isn't a trivial thing. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
