[bitc-dev] Opinions wanted: Infix shift operators

[Jonathan S. Shapiro]

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
application syntax.


> 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
wherever possible.


>  >> 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
BY-REFERENCE parameters].

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.

shap
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.coyotos.org/pipermail/bitc-dev/attachments/20100810/f804a8e5/attachment.html