From: Guillaume Yziquel <guillaume.yziquel@citycable.ch>
To: "Stéphane Glondu" <steph@glondu.net>
Cc: OCaml List <caml-list@inria.fr>
Subject: Re: [Caml-list] Recursive subtyping issue
Date: Mon, 01 Mar 2010 14:06:14 +0100 [thread overview]
Message-ID: <4B8BBBC6.8070302@citycable.ch> (raw)
In-Reply-To: <4B8BB2EF.1010008@glondu.net>
Stéphane Glondu a écrit :
> Guillaume Yziquel a écrit :
>> Because subtyping seems more efficient than applying a noop function.
>> And this code might run really often, so I do not like very much the
>> idea of having noop functions running really often.
>
> FWIW, I don't think you have any penalty if you declare your identities
> as externals like Obj.{repr,obj,magic}. Yuk, some might say... but we
> are in the context of bindings to other languages anyway.
Yuk indeed. The subtyping was also a way to avoid Obj.magic in the first
place and keep doing things cleanly.
I'm not so sure about runtime penalty in this context.
>> 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.
>
> It's more convenient for me write letters and parentheses than the
> symbol ":>" :-)
That's a matter of taste, I guess :-)
> IIUC, these conversion function are not to be used often, are they? What
> you want is the equivalent of Obj.{repr,obj}, but for values of some
> other language, right?
Yes, for the values of some other language.
It depends: they are to be used often for people wanting to make
bindings of R / Python code. (Even tough I plan to use syntax extensions
to ease the pain, something like 'module Nltk = python module nltk'. But
that's a long term perspective.
For people using the binded code, subtyping shouldn't be necessary.
> Are you planning to leak your "tau", "typed" and "untyped" types out of
> the module? If so, inferred types are likely to refer to those, which
> might be very confusing (unless you resort to a lot of type
> annotations). If not, you'll have to use explicitly the coercion
> functions outside of the module anyway.
Yes.
I'm not satisfied with this. (Renaming 'tau' to 'wrapped' would be
better, I guess).
But somehow, I believe that it's an OCaml issue rather than an issue
with my approach. I mean, why should it be impossible to *express* in
the .mli file something like type 'a t = private obj and obj = private
'a t without resorting to extra intermediary types and contravariant
phantom types? Couldn't we just dump the type inequations and
co/contra-variance information (which would require another syntax for
types, I guess)?
But there's another problem for weirder typings that would need 3
different categories of types (R ?). 2 conversion functions is OK. 6
conversion functions is clearly a pain... And concerning R's quirky type
system, I'm probably optimistic with the number 3.
--
Guillaume Yziquel
http://yziquel.homelinux.org/
next prev parent reply other threads:[~2010-03-01 13:05 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 [this message]
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
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=4B8BBBC6.8070302@citycable.ch \
--to=guillaume.yziquel@citycable.ch \
--cc=caml-list@inria.fr \
--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;
as well as URLs for NNTP newsgroup(s).