From: "Ohad Rodeh" <ORODEH@il.ibm.com>
To: Francois.Pottier@inria.fr
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] mutability analysis too strict?
Date: Mon, 10 Dec 2001 11:12:39 +0200 [thread overview]
Message-ID: <OF6ACCF129.3F4691A6-ONC2256B1E.0031C7C8@telaviv.ibm.com> (raw)
First of all, sorry my mail was sent twice, this was due to mail delivery
problems
from my site.
Perhaps I was not specific enough about what I wanted to acheive. What I
need
is a repository that has the following interface:
module type Repos = sig
val put : 'a -> 'b -> unit
val get : 'a -> 'b
end
An implementation that looks like this:
module S : Repos = struct
let h = Hashtbl.create 10
let put key data = Hashtbl.add h key data
let get key = Hashtbl.find h key
end
Does not work. Compilation error:
Signature mismatch:
Modules do not match:
sig
val h : ('_a, '_b) Hashtbl.t
val put : '_a -> '_b -> unit
val get : '_a -> '_b
end
is not included in
Repos
Values do not match:
val put : '_a -> '_b -> unit
is not included in
val put : 'a -> 'b -> unit
I tried also using the Map and Set modules, but they don't really allow
building
a repository of immutable values either. Is there any deep reason for this
behavior? Could you expound on this line:
> A monomorphic, mutable
> structure that contains polymorphic data is sound, but cannot be
expressed
> in ML's type system where universal quantification must be prenex.
Ohad.
Francois Pottier <francois.pottier@inria.fr>@pauillac.inria.fr on
10/12/2001 10:13:31
Please respond to Francois.Pottier@inria.fr
Sent by: owner-caml-list@pauillac.inria.fr
To: Ohad Rodeh/Haifa/IBM@IBMIL
cc: caml-list@inria.fr
Subject: Re: [Caml-list] mutability analysis too strict?
On Sun, Dec 09, 2001 at 05:43:41PM +0200, Ohad Rodeh wrote:
>
> let h = Hashtbl.create 10;;
> h : ('_a, '_b) Hashtbl.t
>
> The objects and keys in the table are infered to be mutable. However,
> in my case, they are immutable and I have to coerce them using Obj.magic
> from '_b to 'b.
You are slightly wrong here: the analysis infers the table itself (not the
keys or objects in it) to be mutable, which it indeed is. If the table was
given a polymorphic type, you would be able to store objects of a certain
type and to retrieve them at another type (by taking different instances of
'b), which would be unsound.
Furthermore, I'm surprised to hear that using Obj.magic helps; indeed, any
application of Obj.magic is itself deemed `dangerous' by O'Caml, leading
to the following behavior:
# let h = Hashtbl.create 10;;
val h : ('_a, '_b) Hashtbl.t = <abstr>
# let h = (Obj.magic h : ('a, 'b) Hashtbl.t);;
val h : ('_a, '_b) Hashtbl.t = <abstr>
That is, Obj.magic doesn't help at all in this case.
Perhaps you could tell us what you are trying to achieve? Any polymorphic,
mutable structure is unsound and rightly rejected. A monomorphic, mutable
structure that contains polymorphic data is sound, but cannot be expressed
in ML's type system where universal quantification must be prenex.
--
François Pottier
Francois.Pottier@inria.fr
http://pauillac.inria.fr/~fpottier/
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ:
http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr Archives:
http://caml.inria.fr
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
next reply other threads:[~2001-12-10 9:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-10 9:12 Ohad Rodeh [this message]
2001-12-10 9:28 ` Remi VANICAT
-- strict thread matches above, loose matches on Subject: below --
2001-12-10 10:13 Ohad Rodeh
2001-12-10 10:30 ` Basile STARYNKEVITCH
2001-12-10 10:50 ` Francois Pottier
2001-12-10 11:21 ` Mark Seaborn
2001-12-09 15:43 Ohad Rodeh
2001-12-10 8:13 ` Francois Pottier
2001-12-09 12:14 [Caml-list] Mutability " Ohad Rodeh
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=OF6ACCF129.3F4691A6-ONC2256B1E.0031C7C8@telaviv.ibm.com \
--to=orodeh@il.ibm.com \
--cc=Francois.Pottier@inria.fr \
--cc=caml-list@inria.fr \
/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