BTW..After writing my email I started reading about Rust for the first time...
I can see why Bennie thinks an experimental rust fork might be a good starting point. It seems to be spiritually solving many of the same problems bitc set out to solve.. though their constructs and ahead-of-time compilation seem to be leading down a C++/ML like whole-program-compilation-forever path. I seem to remember some of the bitc end-of-life involving the mutual exclusivity of modular subtyping plus parametric-instantiation and ahead-of-time compilation. Below are a few connections with Rust and what I wrote about GC tracing pressure... On Sat, Jul 13, 2013 at 10:38 PM, David Jeske <[email protected]> wrote: > ...Now, if we extend the CLR "ref" argument decorator to be usable on any > object and mean "a pointer to something which can not be copied during the > call and thus has no lifetime requirements outside the call" > ...it looks like this concept I talked about above is similar to Rust's "borrowed pointers". They also use the same concept for strictly stack-descending function-pointer callbacks, in their type "stack closures". ...my thoughts are staying away from what I perceive as > "magic" mechanisms which allow "normal" objects and "normal" pointers to > work for either heap-GC or region spaces. I'm thinking of a C#-like > class/struct dichotomy which gives us more convenient mechanisms to manage > typesafe collections of mutable structs which are not seen by the GC. Rust's multi-memory-model handling of both types and variables is exactly the type of "magic" (type-polymorphic?) mechanism I was talking about avoiding above. I don't yet fully understand their multi-memory-model system, or the implications for authoring software.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
