Version française
Home     About     Download     Resources     Contact us    
Browse thread
mutable and polymorphism
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Goswin von Brederlow <goswin-v-b@w...>
Subject: Re: [Caml-list] mutable and polymorphism
Radu Grigore <radugrigore@gmail.com> writes:

> On Wed, Sep 15, 2010 at 8:10 PM, Goswin von Brederlow <goswin-v-b@web.de> wrote:
>> In your original a.ml you didn't use the [...]
>
> Let me rephrase. IMO, both the modified a.ml and the modified c.ml
> fail for the same reason: polymorphic references. Therefore, just as
> you can't infer from "modified a.ml fails" that "original a.ml should
> fail" you can also *not* infer from "modified c.ml fails" that
> "original c.ml should fail".
>
>> Because the compiler is stupid and things with a ref can't
>> polymorphic.
>
> The compiler isn't stupid: Polymorphic references are unsound. See for
> example Section 2.2.3 here:
>   http://caml.inria.fr/pub/docs/u3-ocaml/ocaml-core.html#toc8

It isn't as smart as you. Call it conservative.

>> let f y = let x = ref () in (fun y -> ()) y in f 1; f 'a'
>
> This has different semantics. Consider
>   let f y = let x = ref 0 in (fun y -> incr x) y in f 1; f 'a'

Yes it does. Which makes the value restriction sometimes anyoing.

> In any case, I'm more interested in an explanation of what happens,
> since in practice I'm quite happy with a.ml (together with hiding the
> reference from outside by not putting it in mli).
>
> regards,
>   radu

Reading up on value restrictions as mentioned in the other mails will
give you the technical details. But they get quite technical so you
might need some background into the theory of functional languages.

MfG
        Goswin