caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Radu Grigore <radugrigore@gmail.com>
To: caml-list@yquem.inria.fr
Subject: Re: mutable and polymorphism
Date: Fri, 17 Sep 2010 15:04:00 +0100	[thread overview]
Message-ID: <AANLkTimk_X50Z+N2_R2B2fVW6omjheVigmtxMK4dRbom@mail.gmail.com> (raw)
In-Reply-To: <AANLkTimOrmnhFmzgDBVO5ZgPKF89ePHBnHqf=w+2Fynu@mail.gmail.com>

Thanks Kaustuv! For whoever may bump into this thread, here's a brief
summary that includes info from
  http://scholar.google.com/scholar?cluster=15692213376116771285
  http://scholar.google.com/scholar?cluster=7879701537639090355

Given (let x = e1 in e2), it is not safe to generalize the type
variables for x when e1 has side-effects. After all e1 performs its
side-effects only once, but a polymorphic type on x may let it be used
as if it does them multiple times. For example,
  let x = ref [] in x := ()::!x; 1::!x
would seem to work if you think about it as
  ref []; (ref [] := () :: !(ref []); 1::!(ref []))
and that's exactly how the type system "thinks" about it if it
generalizes types for x. But, of course, that's not the semantics:
only *one* reference is created at runtime.

Some solutions:
1. Never generalize type variables that appear under ref. (OCaml,
before 1995.) Too restrictive.
2. Keep track of side-effects, for example by using type system
with... effects :). (Many people, before 1995.) The problem is that in
interfaces you need to write types, so you'd need to say whether you
implement something using imperative features or not.
3. Only generalize type variables if e1 clearly doesn't have
side-effects because it's not a computation. (Wright 1995, OCaml up to
3.06.)
4. If it's not clear that e1 doesn't have side-effects, you can still
generalize type variables when they appear only in covariant
positions. (Garrigue 2004, OCaml since 3.07.)

So, in my example
  let f = let x = ref () in fun y -> ()
the type checker finds the type '_a->unit for f, but does not
generalize to 'a->unit because '_a in a contravariant position. On the
other hand, in
  let f = let x = ref [] in fun () -> !x
the type is unit->'_a list so it does generalize.

regards,
  radu


  parent reply	other threads:[~2010-09-17 14:04 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-15 17:10 Radu Grigore
2010-09-15 17:40 ` [Caml-list] " Andreas Rossberg
2010-09-15 17:59   ` Radu Grigore
2010-09-15 19:10     ` Goswin von Brederlow
2010-09-15 19:38       ` Radu Grigore
2010-09-15 20:44         ` Kaustuv Chaudhuri
2010-09-17  7:31         ` Goswin von Brederlow
2010-09-17 14:04 ` Radu Grigore [this message]
2010-09-17 14:08   ` Radu Grigore

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=AANLkTimk_X50Z+N2_R2B2fVW6omjheVigmtxMK4dRbom@mail.gmail.com \
    --to=radugrigore@gmail.com \
    --cc=caml-list@yquem.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;
as well as URLs for NNTP newsgroup(s).