Re: [Caml-list] Constraining mutability of record types with interfaces

[Gabriel Scherer <gabriel.scherer@gmail.com>]

One reason that would be unsound is that the variance would be
incorrectly inferred from the immutable interface as being covariant.
You could then do things such as:

  module Ref : sig
    type +'a ref = { contents : 'a }
    val get : 'a ref -> 'a
    val set : 'a ref -> 'a -> unit
  end = struct
   type 'a ref = { mutable contents : 'a }
   let get = (!)
   let set = (:=)
  end

Having covariant (shared) references is unsound.

Now it would be possible to give a weaker type meaning not "the field
is immutable" but "you're not allowed to mutate the field, while some
other parts of the program may be". This status would not imply
covariance, and would be supertype of both "immutable" and "mutable"
fields -- there is work in that direction in Didier Rémy's record
typing systems in the nineties.

On Thu, Feb 20, 2014 at 7:52 PM, David Allsopp <dra-news@metastack.com> wrote:
> Is there a profound reason that I'm missing (possibly to do with
> optimisations) why one can't have:
>
> Foo.mli
>         type foo = {bar : unit}
>
> Foo.ml
>         type foo = {mutable bar : unit}
>
> i.e. have field mutability being something which can be constrained by an
> interface in a sort of equivalent way to private types? I'm guessing, as the
> compiler goes to the trouble of explaining the exact error, that there is!
>
>
> David
>
>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs