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

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

Expand Messages
  • Remi Vanicat
    Nov 9, 2004
      On Fri, 5 Nov 2004 17:46:54 +0000, Alwyn <dt015a1979@...> wrote:
      >
      >
      >
      > 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:
      > <http://www.smlnj.org//doc/Conversion/types.html>
      >
      > <quote>
      > 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.
      > x::nil).
      > 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.
      > </quote>

      well, I belive that there is this, and some other value, but I've
      difficulties to explain when exacltly.

      >
      > > 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
      > any?

      there is a bug report about it in the ocaml bug tracking
      http://caml.inria.fr/bin/caml-bugs/fixed?id=1692;expression=vanicat;page=2;user=guest
      you could also try to find messages on the mailing list speaking about it
    • Show all 26 messages in this topic