On Fri, 2008-10-17 at 08:22 -0400, Sandro Magi 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. > > Isn't this just record polymorphism?
Yes, but there is a difference between this and what O'Caml does: we are abstracting over a quasi-literal here (the field name). In O'Caml, field names are not scoped by their structure type. They are global. In consequence, in the reference: x.y The symbol resolver can resolve the field name 'y' without reference to 'x'. Since 'y' is global, it is uniquely associated with exactly one (possibly polymorphic) structure definition. The result is that O'Caml never has to introduce any sort of constraint here -- the constraint is "solved" immediately and uniquely at the use-occurrence. I truly hate the fact that field names are globals. My view here is that the use-cases for record polymorphism are VERY rare, and mostly have to do with programmer laziness (that is: declining to state the intended structure type). It's good to be able to be lazy, but I don't think that it is unreasonable to say to the developer "Look: by the time you are using three or four fields you really do know what type you want. Tell us what that is." shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
