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: | -- (:) |
| 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/