On Thu, 2008-10-16 at 18:42 -0700, Pal-Kristian Engstad wrote:
> Jonathan S. Shapiro wrote:
> > What we now have in mind is to introduce a new constraint:
> >
> > (has-field 'a name 'b)
> >
> > which is satisfied when the type 'a has a field with the given /name/,
> > and that field in turn has type 'b. So the type of:
> >
> > (define (get-x v) v.x)
> > get-x (forall ((has-field 'a v 'b))
> > (fn 'a -> 'b))
> >
> > that is: we will now do polymorphic inference over field names.
> How do you intend to implement such a function? One option would be to
> require an offset for each HAS-FIELD constraint...
You are actually on the trail of something interesting here, which I
will get into in a moment, but the short answer to your question is that
our polyinstantiation procedure does not require any hidden arguments or
dictionaries. After polyinstantiation, all types are fully concrete and
therefore all offsets are fully known.
But you *are* on the trail of something interesting here, which is a
strategy for avoiding over-instantiation and a new style of typed
assembly language.
If you think about it in a certain way, a type declaration can be viewed
as a short-hand way of stating the following sorts of things:
1. The offsets of fields and their types
2. The sizes of types
That is:
(defstruct S
int32: x
int32: y)
is (among other things) a shorthand for a representation type:
(has-field 'a 0 int32) ; field names replaced by offsets
(has-field 'a 4 int32)
At the assembly language level, a load instruction
ld int32 %r2 := [%r1 + 4]
can be permitted to have polymorphic type on %r1. That is, this load
instruction is legal for *any* type having an int32 field at offset 4.
Now this is interesting, because it means that when we instantiate
procedures we can "lower" their type down to the implementation level
type system without any loss of safety, and then re-use any
implementation whose constraints match up.
This is a very hand-waving description of a broader idea that is just
beginning to form in my mind.
shap
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
