[bitc-dev] Opinions wanted: Infix shift operators
Jonathan S. Shapiro
shap at eros-os.org
Tue Aug 10 09:52:43 PDT 2010
On Mon, Aug 9, 2010 at 6:32 PM, wren ng thornton <wren at freegeek.org> wrote:
> Jonathan S. Shapiro wrote:
> > The thing we failed to notice, I think, was that tuples have arity and
> > pair-consing does not.
> Or more precisely, tuples have fixed arity whereas pair-consing has
> bounded arity. I.e., the tuple (a,b) has arity 2, whereas the pair (a,b)
> has arity 2+. The tuple (a,b,c) has arity 3, whereas the pair (a,(b,c))
> has arity 3+. So pair-consing only gives you a lower bound on the arity,
> whereas flat tuples give an upper bound as well.
> Speaking of which, for your purposes, does it really matter that you
> only have a lower bound?
Yes. Calling procedures with the wrong number of actual parameters is
something we want to be able to check, so establishing a bound is important.
This is another reason that I didn't initially adopt the curried-style
> That is, if you wanted to pursue this again, I
> could see a calling convention that makes it work.
Thanks. We'll stick with the native calling convention for the platform
> >> The (x,y,z) = (x,(y,z)) translation only works when (1) tuples are
> >> implemented as products of boxed values, and (2) there is no bottom
> >> value for the product type.
> FWIW, I phrased (1) poorly regarding what I actually meant...
> > PAIR, in bitc, is an unboxed cons cell. PAIR(x, PAIR(y, z)) emits the *
> > identical* bit-level layout as (x, y, z), and the resulting code is
> > identical, so I don't see why your statement (1) holds.
> But that same representation has different semantics. In particular, the
> semantics of pairs means that we have a function:
> snd :: (a,b) -> b
> snd (x,y) = y
> We can pass in (x,(y,z)) and get (y,z) back as a result. Effectively,
> this means (y,z) is actually boxed in some sense; the inlining of that
> box in the representation of (x,(y,z)) is secondary. We can see the
> boxing if we think about how snd must be implemented. One option would
> be to return a pointer to where the second component begins:
I agree that we can get back a *copy* of (y,z), but it is a *copy*, not an
inner reference. BitC doesn't use the heap-based value semantics you are
assuming. If the tuple is not heap-allocated, there is no way to get back a
reference to the storage occupied by the original (y,z) [ignoring
We could accomplish this result with tuples too. It's exactly:
let (newY, newZ) = (y,z)
[Different sorts of products] is one of the reasons
> why there are so many different flavors of "pairs", "tuples",
> "products", etc. And also why the differences become important in lazy
> languages (like Haskell) or languages that are exacting about their
> representations (like BitC).
So oddly enough, we experienced no such complication in BitC at all, and I'm
unclear how such a complication would arise in practice. I'm not even clear
that having a bottom in the sense that you mean is actually necessary.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitc-dev