On Sat, Feb 12, 2011 at 4:34 AM, wren ng thornton <[email protected]> wrote:
> On 2/12/11 1:55 AM, Jonathan S. Shapiro wrote:
> > In an impure language where a union's content can be overwritten by
> another
> > value of compatible type, this implementation isn't correct - which is
> why
> > I'm looking from the other point of view.
>
> Perhaps, but that's only the case because you have already assumed
> C-style unions.... It's equally valid to say that it means something
> more like (really not C):
>
> typedef struct{} IntList$Nil;
> typedef struct{ int head ; IntList* tail } IntList$Cons;
> typedef (Nil | Cons)* IntList;
>
> Which is to say, that there is a storage representation for things
> constructed by Nil, and there's a storage representation for things
> constructed by Cons, but that doesn't say anything about the storage
> representation of IntList.
>
Wren:
First, thank you. I understand the point you are making, it is valid, and I
agree that this is a fine way of looking at unions from a type system
perspective. Unfortunately, its consequences from a representation
perspective are inconsistent with the view that is needed for successful
construction of systems code.
Also: from a pragmatics perspective, I don't think that I accept the
argument. The fact is that an *unboxed* union must have *some* determinate
size, and that this size must support assignment (and therefore must be at
least as large as the largest unboxed leg) and also the space for the type
tag (at least in some representations). While I could imagine admitting
other considerations, almost all of the concrete possibilities that I can
come up with are extraneous.
It is also significant that existing hardware implementations impose (in
some cases) tag-embedded representations. While the language *can* support
other representations, it *must* support tag-embedded representations.
But perhaps I have missed something significant. If so, please do not
hesitate to point it out!
Jonathan
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
