On 2011-02-08 2:29 AM, Jonathan S. Shapiro wrote:
> But what about #Nil('a)? Well, that certainly /does/ occupy storage,
> because it is an instance of #List('a), which is an unboxed type having
> non-zero size. So since /nil/ is now attempting to be syntactic sugar
> for ref(#Nil('a)), it would appear that Nil('a) now occupies storage.Absent a guaranteed optimization, which you do specify in the BitC spec, yes it could occupy storage for the header. > Is dup(#Nil) =eq= Nil guaranteed to be boolean true? If so, is this > accomplished by a subtyping illusion or is it accomplished by imposing a > constraint on the behavior of dup() when applied to union values > corresponding to a nullary constructor? 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. > And if the desired answer is "yes", then is deref(#Nil) =eq= Nil > guaranteed to be boolean true? I would expect "yes". > I think the answer to this has to be > "no", because if a structure contains a field of union type, we may be > trying here to capture the address of a field, and we want to be able to > use that later for address inclusion testing. I'm afraid I don't follow this. Do you have a trivial example illustrating this point? I will note however, that equality on structures that have addresses state conflates identity with equivalency. Normally Eq means the latter, but as you point out, we sometimes want the former. This is why I prefer separating the two concepts. > And finally, consider that deref(ref(someList)) returns an assignable > location, so deref(ref(#Nil)) is an assignable location. Which means it > must be backed by storage, and further means that two instances of > ref(#Nil) probably had better not be Eq. What is the assignable location here? There is no field in #Nil to assign, so I assume you mean the local itself is assignable. In that case, I don't see the problem with the instances. Your overall approach, re:boxed as syntactic sugar over unboxed values, matches my intuition though, which is heartening. Sandro _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
