Browse thread
Recursive subtyping issue
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: | 2010-03-01 (13:32) |
From: | Guillaume Yziquel <guillaume.yziquel@c...> |
Subject: | Re: [Caml-list] Recursive subtyping issue |
David Allsopp a écrit : > Guillaume Yziquel wrote: >> Stéphane Glondu a écrit : >> >>> Why don't you just declare 'a t to be synonym for obj in the >>> implementation of your module, declare them as abstract in its >>> interface, and export the specially typed identities f and g? >> >> Because subtyping seems more efficient than applying a noop function. > > I wholeheartedly agree that doing this in the type system is much cleaner than using noop/coercion functions but I don't think that there's any difference in terms of efficiency. If the noop/coercion functions are correctly coded then they will be of the form: > > external foo_of_bar : bar -> foo = "%identity" > > in *both* the .ml and .mli file for the module in question. I'm virtually certain that ocamlopt eliminates calls to the %identity primitive. yziquel@seldon:~$ grep magic /usr/lib/ocaml/obj.mli external magic : 'a -> 'b = "%identity" So far so good. >> Moreover, having conversion functions is not really handy, from a >> syntactic point of view: It's quite convenient to write something like >> >> let f : string -> obj :> string -> float t = blah blah blah... >> >> than doing the explicit, runtime, casting in the definition of f. > > Agreed - this is where your approach is really neat! I'm not so sure how far we can push the idea. You can, in one ':>', do subtyping at every type in the type 'a -> 'b -> 'c. This is quite handy. But I'll have to check in which way this can be integrated in the calling conventions of, say, Python. >> I then tried to go the whole way, and get rid of conversion functions >> altogether. > > Being pedantic, what you mean is getting rid of *coercion* functions; *conversion* functions could never eliminated OK. > This is tremendously clean - as long as the types are clearly documented! The problem is that ocamldoc doesn't let you "document" coercions (by which I mean that having a conversion function provides means for the documentation of that particular usage). Thank you. The ocamldoc problem isn't really a problem, I believe. You just have to write it cleanly in bold letters. What is more a problem is the fact that inferred .mli files tend to leave out the contravariance on tau: http://caml.inria.fr/mantis/view.php?id=4988 And hence drops part of the subtyping facility. -- Guillaume Yziquel http://yziquel.homelinux.org/