From: Guillaume Yziquel <guillaume.yziquel@citycable.ch>
To: Goswin von Brederlow <goswin-v-b@web.de>
Cc: Andreas Rossberg <rossberg@mpi-sws.org>, OCaml List <caml-list@inria.fr>
Subject: Re: [Caml-list] Recursive subtyping issue
Date: Sun, 28 Feb 2010 12:08:04 +0100 [thread overview]
Message-ID: <4B8A4E94.3030307@citycable.ch> (raw)
In-Reply-To: <87tyt1r8hk.fsf@frosties.localdomain>
Goswin von Brederlow a écrit :
>>
>> Doing 'a t = private underlying allows you to create a type inference
>> barrier. However, you also want to be able to cast from underlying to
>> 'a t, when you get the result of a function in R or Python, for
>> instance.
>>
>> So that's exactly the use case you mentionned above.
>>
>>> Why not supply conversion functions that do any additional checks to
>>> ensure the conversion is a valid one? Consider the following:
>>
>> Because that's exactly what I try to avoid. R and Python are already
>> slow enough and dynamically type-checked at every corner. I'm not
>> happy to add another type-checking layer.
>
> But if you do not check then someone can convert a float q into w and
> back into int q. That would hide the error in the conversion until such
> a time as the type is later used in some function that does check the
> type. I would rather have those checks than go hunting for the real
> error for hours.
Yes and no.
In some sense, when you do bindings of C code, you do have to be
careful. There's no reason that it should be different for binding
Python code or R code.
I mean, having a slick binding without dynamic type checks is, from my
point of view, a good thing.
But this subtyping is for the person binding R or Python code.
The user of the binded code should not see any subtyping. That's the
goal: having a good framework to do the bindings. Not exposing low level
R or Python details the the OCaml coder using the bindings.
>> I've been looking all over at this issue, but simply cannot find a way
>> out. While experimenting on this, I've stumbled on a number of quirky
>> issues with the type system.
>>
>> First one: http://ocaml.janestreet.com/?q=node/26
>>
>> Second one:
>>
>>> # type 'a q = <m : 'a>;;
>>> type 'a q = < m : 'a >
>>> # let f : 'a q -> 'a q = fun x -> x;;
>>> val f : 'a q -> 'a q = <fun>
>>> # let o = object method m : 'a. 'a -> 'a = fun x -> x end;; val o :
>>> < m : 'a. 'a -> 'a > = <obj>
>>> # f o;;
>>> Error: This expression has type < m : 'a. 'a -> 'a >
>>> but an expression was expected of type 'b q
>>> The universal variable 'a would escape its scope
>>> #
>> All these issues seem to be somehow related, in a way I'm not yet able
>> to articulate clearly.
>
> # class ['a] foo = object method map (f : 'a -> 'b) = ((Obj.magic 0) : 'b foo) end;;
> class ['a] foo : object method map : ('a -> 'a) -> 'a foo end
>
> As I recently learned there seems to be no way to make that actualy
> produce a 'b foo. I think that hits the same problem.
>
> MfG
> Goswin
Will have a look at that when I find the time.
--
Guillaume Yziquel
http://yziquel.homelinux.org/
prev parent reply other threads:[~2010-02-28 11:07 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
2010-03-01 20:18 ` David Allsopp
2010-02-28 9:54 ` Goswin von Brederlow
2010-02-28 11:08 ` Guillaume Yziquel [this message]
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=4B8A4E94.3030307@citycable.ch \
--to=guillaume.yziquel@citycable.ch \
--cc=caml-list@inria.fr \
--cc=goswin-v-b@web.de \
--cc=rossberg@mpi-sws.org \
/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).