On 2011-02-09 4:48 AM, Jonathan S. Shapiro wrote:
> Incorrect. In the explored implementation, Nil('a) is actually
> ref(#Nil('a)), and #Nil('a) is an instance of an unboxed type that
> *definitely* occupies storage.
The guaranteed optimization I'm referring to is that
ref(#NullaryConstructor) compiles to an integer, not a pointer. So yes,
#Nil occupies heap storage, but ref(#Nil) does not.
> I think the latter, ie. dup(#Nil) =eq= Nil is true. Semantically, dup
> would be an overloaded function provided by type class, which for Nil,
> is simply the identity. You can provide a specialized implementation in
> the compiler of course.
>
> Good. You fell in to my trap! [As did I]
>
> #Nil is not a unique value! In order for dup(#Nil) to yield a unique
> value, dup() is required to examine the value being duped.
You only need to examine the tag. I'm also assuming here that dup
produces a heap value, so please correct me if I'm wrong. I don't think
unboxed and boxed values should be equable by default (as in C).
> struct X {
> l: List(char)
> }
>
> def x = X(#Nil(char))
>
> def nilRef = AddressOf(x.l);
>
> // is nilRef EQ to Nil?
I take it AddressOf products a ref(List('a))? So I would say yes to the
question, where Nil is ref(#Nil).
> What is the assignable location here? There is no field in #Nil to
> assign...
>
> True. But deref(ref(someList)) isn't of type Nil. It's of type List('a),
> and *that* type *does* have locations.
That type has locations only if the tag is #Cons, so I disagree with
your assertion. However, I grant that when unboxed, it has to behave
like a C union so the available storage for #Cons is technically there,
just inaccessible when the tag is #Nil.
Unless you're also making the tag itself assignable? That doesn't seem
wise. Better to require the whole structure be overwritten.
def x = mutable #Nil
x := #Cons someValue
Sandro
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
