Geoffrey is right about this issue. The reason I don't want to tackle this right now is because I'ld rather get a lot of stuff right (and not do this) than not get anything at all, and this requires a degree of thought that we shouldn't stop to do right now.
That said, I do think that this is a good idea. On Wed, Mar 11, 2009 at 11:02 AM, Geoffrey Irving <[email protected]> wrote: > Also, if make-vector is a primitive inlining it produces invalid BitC > code, which breaks the BitC -> BitC optimization property. This would be true if make-vector were a built-in procedure. It can be treated in most respects **as if** it were a procedure, and the majority of the compiler does so. But at the end of the day the implementation of make-vector is primitive, and it is not required or expected that it's inlining produces valid BitC code. There is an enormous safety problem here. If the vector body can be in scope without being fully initialized, we would be force to introduce a dependent type system that could accomodate disjoint subranges (some initialized, others not). I'm not aware that *anybody* has managed to do that. It's definitely a hairball, especially so since BitC does not (and will not) support multi-dimensional arrays in the type system. The reason this matters is that it makes describing the initialized sub-slices moderately complex. shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
