David Allsopp wrote: > Without the full coercion for x you'll get a type error because the type > checker infers that the type of the [if] expression is [t] from the [then] > branch and then fails to unify [> `B of int ] with [t] unless the type of > [x] is first coerced to [> t ]. If the compiler were to try (x : t : [> t ]) > in all those instances I think that would render polymorphic variants pretty > unusable ... the type checker needs to know that you meant to do that or > everything will unify! > Okay, you claim we shouldn't automatically open polymorphic variants. I don't see why auto->ing polymorphic types is really a problem. If the later code (receiving the returned value) can't handle the [> ] type, that type error will stop things (although it won't point out where the [> ] came from). This seems one case where the compiler can easily DWIM the correct result.
>> Would it be particularly difficult to, in the cases where type [x] is >> found but type [y] is expected, to try a (foo : x :> y) cast? > > +1! With reference my previous comment that "the type checker needs to know > if you meant that", there's still the option of using fully abstract types > if you wanted to avoid this kind of automatic coercion and have, say, > positive integers totally distinct from all integers without an explicit > cast. > Actually, I do see the use of two kinds of derived types: type positive = private int ( auto-coerced to int ) type category_id = new int (not auto-coerced to int - math not allowed) I assume there's some efficiency benefit to exposing the underlying type of category_id, if not then abstract types will quite suffice. > All said, I do see Jacques point of wanting to keep coercion and type > inference totally separate... though perhaps if coercions were only tried > during unification if at least one of the types in question is private that > would maintain a certain level of predictability about when they're used > automatically? > > > David > I'm happy moving down this slope of the compiler doing more of the work. Hopefully it's slippery, so it'll end up doing lots of work for me. E. _______________________________________________ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
