Version française
Home     About     Download     Resources     Contact us    
Browse thread
Recursive subtyping issue
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ 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/