On 10/19/10 12:34 PM, Jonathan S. Shapiro wrote: > So I suppose the question now is: where should type annotation be in the > BitC precedence hierarchy? I prefer that it bind tightly, but this probably > just reflects the fact that I'm coming from C, and that is what is familiar. > Is there a strong or compelling reason to have it bind loosely (other than > the mixfix complications)?
In my experience the looser binding tends to be more parsimonious, since often a top-level (i.e., expression-outer) annotation is sufficient to help the type inferencer figure everything else out. Then again, that's coming from Haskell/ML-like languages. Part of the reason it works out so well is because things like addition have type (Num a => a -> a -> a) where both arguments are forced to the same type--- whereas in C, addition is more like ((Num a, Num b, Num c) => a -> b -> c) which cripples the, non-existent, type inferencer. When trying to use C-like excessive polymorphism in Haskell you end up needing to write type annotations all over the place. I'm not sure exactly where BitC would fall in this spectrum. Then again, I think it's important to keep the notion of type annotations and casts distinct. Annotations are just there to help inform the compiler of the type that things (already) have, and they have no operational existence; whereas casts do have operational existence since they are coercing from one type to another, either by reinterpreting bits or by converting to different bits. Casts should definitely be expression-inner, like they are in C and (in the form of newtype wrappers/unwrappers) in Haskell. -- Live well, ~wren _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
