On Wed, Feb 9, 2011 at 8:32 AM, Sandro Magi <[email protected]>wrote:
> 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.
>
But that doesn't work out. The problem is that ref(#Nil) has type
ref(#List('a)). #List('a) has non-zero size, and is mutable. So the
following is legal:
let r = dup(#Nil)
in
deref(r) := cons(x, nil)
the cons cell occupies storage, the assignment is performed by byte copy,
and the bytes have to go somewhere. So the target of ref(#Nil) has to occupy
storage unless we can show that it is not a target of assignment. Further,
two independent instances of dup(#Nil) cannot occupy the *same* storage.
> #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.
Yes. But the fact that you need to do that is a qualitative change in the
behavior of dup(). In fact, it requires that dup() be automatically
instantiated with a distinct implementation for each type!
> I'm also assuming here that dup
> produces a heap value, so please correct me if I'm wrong.
Yes.
> I don't think
> unboxed and boxed values should be equable by default (as in C).
Certainly not. But any two values of type ref('a) and ref('b) where 'a=='b
should be Eq-able. There is no guarantee that both targets are in the heap,
though.
>
> > 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).
>
So you are saying that the value returned by AddressOf a structure element
may not always name a byte that falls within the span of the containing
structure. This is a pretty radical move, and one that is very problematic
from a systems coding standpoint. In fact, I think it's not a survivable
decision for the language.
> > 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.
>
Sorry - the someList here was intended to be of type #List, with the
consequence that the value of someList might be #Nil and the type of
deref(ref(someList)) is #List(T) rather than List(T).
But not that you argued above that ref(#Nil) should always be Eq to
ref(#Nil). In order for that to be true, ref(#Nil) need not point to *any*
location, but if it does, it must always point to the *same* location. That
location, if it is ever overwritten by assignment, will no longer hold the
value #Nil....
> That type has locations only if the tag is #Cons.
>
No! That is precisely the mistake here. The decision about whether a
reference denotes a location is (necessarily) a consequence of its type, not
a consequence of its value. The optimization that allows unary elements of
natively-boxed types to have no storage is exactly that: an optimization. If
it is possible to apply deref() to such values, then the assumptions that
admit that optimization no longer hold, and the optimization ceases to be
legal.
> 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.
>
In all of these examples, the entire union *is* being overwritten. The tag
is, of course, overwritten as a consequence.
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
