From: Mike Hamburg <hamburg@fas.harvard.edu>
To: caml-list@inria.fr
Subject: '_a
Date: Wed, 26 Jan 2005 19:19:16 -0500 [thread overview]
Message-ID: <1448756C-6FF9-11D9-8411-0003939A19AA@fas.harvard.edu> (raw)
The appearance of '_a in places where it shouldn't appear causes some
annoyance, and a good deal of confusion among beginners to O'Caml. In
particular, List.map (fun x -> x) "ought to" have type 'a list -> 'a
list, whereas it instead has type '_a list -> '_a list.
Some types are treated specially for creation of '_a, such as refs and
arrays. For instance, if you have the following two declarations:
# let a = let f x () = [x] in f [];;
val a : unit -> 'a list list = <fun>
# let b = let f x () = [|x|] in f [];;
val b : unit -> '_a list array = <fun>
Although I haven't read the code for O'Caml, I deduce from this that
there is deep magic in place to determine when to turn 'a into '_a, and
in many cases, the heuristic is wrong (in the conservative direction:
in this case, 'a should not be turned into '_a until b is applied).
The cause of the problem is that programs may create a closure with a
mutable variable of type 'a, which if we were to let 'a generalize
could be replaced with a subtype 'b of 'a, and then used as another
subtype 'c of 'a, which would be unsafe.
As a fix, I propose the following: the type system should keep track of
where a mutable or immutable reference to a polymorphic variable with
type parameter 'a is created on the stack. Call these places [m'a] and
[i'a]. For example, ref should have type 'a -> [m'a] 'a, and ref []
should have type [m'a] 'a (which is equivalent to the current '_a). I
don't propose that the printing should show this complexity, just as it
hides whatever heuristic O'Caml is using now, except in the case where
there is a mutable reference at top level, in which case it should
convert 'a to '_a.
Of course, module interfaces shouldn't have to show when they keep
references to things, so we probably can't do much about applying
List.map to the identity without modifying List (for instance, what if
List.map decided to memoize the function fed into it using a hash
table?).
Is this a reasonable idea? If so, can someone give me a pointer on how
to go about implementing it (or proving that it is type-safe with
appropriate unification rules?)?
Mike
next reply other threads:[~2005-01-27 0:19 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-27 0:19 Mike Hamburg [this message]
2005-01-27 0:51 ` [Caml-list] '_a Jacques Garrigue
2005-01-27 9:34 ` skaller
2005-01-27 10:02 ` Alex Baretta
2005-01-27 14:13 ` '_a Vincenzo Ciancia
2005-01-27 19:39 ` [Caml-list] '_a Jacques Carette
2005-01-28 0:57 ` skaller
2005-01-28 13:25 ` '_a Stefan Monnier
2005-01-28 14:46 ` [Caml-list] '_a skaller
2005-01-28 14:46 ` Keith Wansbrough
2005-01-28 15:48 ` skaller
2005-01-29 1:37 ` Michael Walter
2005-01-28 13:42 ` Christophe TROESTLER
2005-01-28 14:50 ` skaller
2005-01-28 12:54 ` Richard Jones
2005-01-28 14:39 ` Alex Baretta
2005-01-29 0:33 ` [Caml-list] '_a Dave Berry
2005-02-02 9:17 ` Jacques Garrigue
2005-02-03 7:41 ` Florian Hars
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=1448756C-6FF9-11D9-8411-0003939A19AA@fas.harvard.edu \
--to=hamburg@fas.harvard.edu \
--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