From: Guillaume Yziquel <guillaume.yziquel@citycable.ch>
To: David Allsopp <dra-news@metastack.com>
Cc: "'Stéphane Glondu'" <steph@glondu.net>,
"'OCaml List'" <caml-list@inria.fr>
Subject: Re: [Caml-list] Recursive subtyping issue
Date: Mon, 01 Mar 2010 14:33:20 +0100 [thread overview]
Message-ID: <4B8BC220.8030904@citycable.ch> (raw)
In-Reply-To: <000d01cab93d$b095c770$11c15650$@romulus.metastack.com>
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/
next prev parent reply other threads:[~2010-03-01 13:32 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-27 1:52 Guillaume Yziquel
2010-02-27 6:38 ` [Caml-list] " Andreas Rossberg
2010-02-27 10:25 ` Guillaume Yziquel
2010-02-27 11:49 ` Goswin von Brederlow
2010-02-27 13:11 ` Guillaume Yziquel
2010-02-27 16:52 ` Andreas Rossberg
2010-02-27 18:10 ` Guillaume Yziquel
2010-02-27 19:52 ` Guillaume Yziquel
2010-02-27 20:32 ` Guillaume Yziquel
2010-03-01 10:55 ` Stéphane Glondu
2010-03-01 11:21 ` Guillaume Yziquel
2010-03-01 12:28 ` Stéphane Glondu
2010-03-01 12:49 ` David Allsopp
2010-03-01 13:06 ` Guillaume Yziquel
2010-03-01 12:49 ` David Allsopp
2010-03-01 13:28 ` Goswin von Brederlow
2010-03-01 20:12 ` David Allsopp
2010-03-02 10:22 ` Goswin von Brederlow
2010-03-01 13:33 ` Guillaume Yziquel [this message]
2010-03-01 20:18 ` David Allsopp
2010-02-28 9:54 ` Goswin von Brederlow
2010-02-28 11:08 ` Guillaume Yziquel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B8BC220.8030904@citycable.ch \
--to=guillaume.yziquel@citycable.ch \
--cc=caml-list@inria.fr \
--cc=dra-news@metastack.com \
--cc=steph@glondu.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox