2777Re: "ocaml_beginners":: Re: 'ocaml_beginners':: Execution semantics
- Nov 9, 2004On Fri, 5 Nov 2004 17:46:54 +0000, Alwyn <dt015a1979@...> wrote:
>well, I belive that there is this, and some other value, but I've
> 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.
difficulties to explain when exacltly.
>there is a bug report about it in the ocaml bug tracking
> > 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
you could also try to find messages on the mailing list speaking about it
- << Previous post in topic Next post in topic >>