On Mon, Feb 16, 2015 at 8:03 AM, Keean Schupke <[email protected]> wrote:
> The reason for the suggestion is that the arrow should take multiple left
> arguments.
>
Why? What advantage arises from using this in preference to unboxed tuples?
Note: I actually *can* see some, and I was going to send a note about this
shortly.
> If BitC tuples are always unboxed, then it may not make any difference,
> but the tuple constructor could be curried, whereas arrow left arguments
> cannot.
>
Actually, I think that is not the case. We already seem to have concluded
that n-ary functions cannot be curried, and it would follow that n-ary
value constructors cannot be curried. Since tuple is an n-ary value
constructor, it would seem that it is exactly as curried or uncurried as
the LHS of an n-ary function.
BitC v0 doesn't actually *have* a tuple type. We define "," as an infix
syntax for pair, with the result that (a, b, c) turns into pair(a, pair(b,
c)). This is mostly OK, except that the type ('a, 'b, 'c) can do strange
things if 'c gets specialized to a pair type. It was never apparent that
this distinction between tuples and pairs had any practical consequence in
the expressiveness of the language, and it allowed us to have a tuple-like
syntax without introducing another special case into the compiler
implementation.
I'm still not sure if that was a good decision or a bad one. I think we
still have all of the effects of product types, except that our product
operator now has associativity. I'm on the fence about introducing tuples
as a first-class type in BitC v1.
Opinions?
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
