Hi,
Just been reading though the BitC spec again and trying to understand
Swaroop's latest mails and noticed that the definition of the "optional"
union type looks a bit strange. It currently appears as:
(defunion (optional 'a) :val
none
val:(some 'a))
But I think it's probably:
(defunion (optional 'a) :val
none
(some val:'a))
I'm having a lot of trouble getting my head around the semantics of
types like "optional" -- i.e. polymorphic value unions. Not sure if
it's just me or not. For example in the presence of elided tags, what
representation gets picked for:
(define x none)
id: (forall ('a) (optional 'a))
At the moment I assume this is where the polyinstantiator kicks in.
I also assume that you don't want the polyinstantiator to be used quite
as liberally in later versions of BitC, but I'm unsure how this can be
reconciled.
Section 5.4 (Interaction with ``Relaxed'' Value Restriction) of the
paper Swaroop is writing has the following example:
(define p:(mutable bool, 'a) (#t, none))
val p: (mutable bool, (optional 'b))
(let ((r1:(optional int8) p.snd)
(r2:(optional double) p.snd)) ... )
which is a problem because optional is a value type and hence it's size
is determined by its parameter type. I've just realised another related
problem, that of finding the location of a structure (or union) member.
Given the type and function:
(defstruct (pair 'a 'b)
a:'a b:'b)
(defun (fn p):(fn (pair 'a 'b) 'b)
p.b)
how does the compiler know the member `b's location. I guess the
polyinstantiator kicks in again and spews out instances of the function
where needed.
The only way I can see out of this is to require polymorphic members
to be boxed. I have a feeling that this is what Garrigue's restriction
effectively does in BitC, but haven't entirely convinced myself of it yet.
It guess it would be possible to allow functions to pass boxed types
around with polymorphic members as long as they are treated as opaquely.
I hope that makes sense and is somewhat useful.
Sam
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
