Loading ...
Sorry, an error occurred while loading the content.

2754Re: "ocaml_beginners"::[] Re: 'ocaml_beginners'::[] Execution semantics

Expand Messages
  • Alwyn
    Nov 5, 2004
    • 0 Attachment
      On 5 Nov 2004, at 13:19, Remi Vanicat wrote:

      > On Fri, 5 Nov 2004 12:59:29 +0000, Alwyn <dt015a1979@...>
      > wrote:
      > >
      > > It's called 'value restriction'. For full polymorphism, the
      > expression
      > > on the right hand side of the '=' sign must be a value.
      > Well not exactly, if the value on the right hand side of the = is an
      > hashtable for example, it is a value, but it won't be polymophic (it
      > would be realy unsafe).

      I was under the impression that current O'Caml, like SML 97, employed a
      system of value polymorphism as suggested by Andrew Wright in his paper
      "Simple Imperative Polymorphism" published in 1995. See:

      As in SML '90, we approximate the class of safe-to-generalize
      expressions conservatively by the simple syntactic notion of a
      nonexpansive expression, also known as a value expression or simply a
      value. SML '90 defined nonexpansive expressions to include the
      following atomic forms:
      • constants (e.g. 3),
      • nullary constructors (e.g. nil),
      • variables (e.g. x, A.x),
      • function expressions (e.g. (fn x => x)).
      It is clear that the evaluation of any of these forms is safe because
      it cannot entail the creation of new data structures (other than the
      benign case of creating function closures for function expressions). To
      partially compensate for the fact that we are being more restrictive in
      our creation of polymorphism, SML '97 enlarges the class of
      nonexpansive expressions to include some simple compound expressions:
      • records and tuples with nonexpansive fields (e.g. (3,x,nil)),
      • constructors (except ref) applied to nonexpansive arguments (e.g.
      All other expressions, including function applications, let
      expressions, conditionals, etc., are by definition expansive, implying
      that their evaluation may entail nontrivial computations that might
      lead to the creation of ref cells or other mutable data structures.

      > Only imutable value will be generalize (that
      > is render fully polymorphic). Well, not exactly this, it will be
      > generalize if the type polymorphisme is covariant (and I believe there
      > is another restriction).

      I haven't been able to find an authoritative source on this subject
      with regard to O'Caml either in English or in French. Do you know of

    • Show all 26 messages in this topic