[bitc-dev] mixfix meets syntactic categories
wren ng thornton
wren at freegeek.org
Tue Oct 19 19:49:08 PDT 2010
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.
More information about the bitc-dev