caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: rossberg@mpi-sws.org
To: "Dawid Toton" <d0@wp.pl>
Cc: "caml-list" <caml-list@yquem.inria.fr>, rossberg@mpi-sws.org
Subject: Re: [Caml-list] Re: References and polymorphism
Date: Wed, 11 Jan 2012 16:42:52 +0100	[thread overview]
Message-ID: <869af1b432cfe71214ce68625a92a1c0.squirrel@mail.mpi-sws.org> (raw)
In-Reply-To: <4F0D9501.60107@wp.pl>

Dawid Toton wrote:
> On 2012-01-11 14:15, rossberg@mpi-sws.org wrote:
>>> let f3 : forall ˆ€'a . unit ->  'a list ref =
>>>     fun (type 'aa) ->
>>>       let r = ref ([] : 'aa list) in
>>>       fun () ->
>>>         r
>>>
>>> (* f3: Fine, but it would require some work at compile time or smart
>>> transformations to keep types erased at run-time. Also, keeping the
>>> first actual argument (staying for 'aa) implicit would need extra rules
>>> to resolve ambiguities (decide when this argument is applied). *)
>>
>> No, this would be unsound, because "fun (type t) ->  ..." does not the
>> suspend computation -- there'd be only one ref. It's not System F.
>
> I would insist that it won't crash at run-time.
> Consider the possibilities:
> a) type abstraction suspends the computation - no run-time crash; there
> are implementation problems as in my comment above
> b) computation is not suspended in the sense that the job is done at
> compile time - for each possible type 'aa a separate ref cell is
> allocated. This is of course problematic in practice, but still sound.
> c) computation is not suspended in the sense that the allocation is done
> at compile time, but the implementation tries to keep only one ref cell
> for this purpose. This is impossible. The function can't be compiled
> this way.
>
> I would say that the difference between a) and b) is minor, just a
> choice between more static or more dynamic implementation of the same
> semantics.

It is actually:

d) computation is not suspended, allocation is done when the declaration is
evaluated, for some.

That is more or less equivalent to (c) when the declaration is in global scope.

> The c) option is incorrect, as I understand it, regardless what type
> system flavour is chosen.

Not sure why you think so, but in any case, that's essentially what's
happening.  Type abstraction or application is not operationally observable
in OCaml, or any similar language.  Which is exactly the reason why the
whole soundness issue with polymorphism + references arises, and you have to
disallow certain combinations.

/Andreas


  reply	other threads:[~2012-01-11 15:43 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-10 15:29 [Caml-list] " Dario Teixeira
2012-01-10 15:45 ` Romain Bardou
2012-01-10 16:31   ` Arnaud Spiwack
2012-01-10 17:00 ` Dario Teixeira
2012-01-10 17:20   ` David Allsopp
2012-01-10 18:59     ` Gabriel Scherer
2012-01-11 10:48     ` [Caml-list] " Dawid Toton
2012-01-11 11:07       ` Gabriel Scherer
2012-01-11 13:00         ` Dawid Toton
2012-01-11 13:15           ` rossberg
2012-01-11 13:56             ` Dawid Toton
2012-01-11 15:42               ` rossberg [this message]
2012-01-12  9:55                 ` Dawid Toton
2012-01-12 10:05                   ` Andrej Bauer
2012-01-12 10:46                     ` Romain Bardou
2012-01-11 11:43       ` rossberg
2012-01-11 13:34         ` Dawid Toton
2012-01-11 15:34           ` rossberg
2012-01-11 13:57         ` Dawid Toton

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=869af1b432cfe71214ce68625a92a1c0.squirrel@mail.mpi-sws.org \
    --to=rossberg@mpi-sws.org \
    --cc=caml-list@yquem.inria.fr \
    --cc=d0@wp.pl \
    /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).