Xavier Leroy <xavier.leroy@inria.fr> writes:

> No reasonably simple type system can distinguish both examples.  Many
> have been proposed -- this was a hot research topic in the 1980-1993
> time frame, and I even did my PhD on this very topic -- but none was
> found to be really usable in practice.  The value restriction on
> polymorphism (i.e. what Caml implements) is far from perfect, but is
> the "least bad" of the known solutions.

what about changing the semantic of partial application, restoring
eta-equivalence: a function is not evaluated unless every arguments
are given:

make_toggle()  <=>  fun x -> make_toggle () x


of course this makes functions like "make_toggle" quite useless:

# let make_toggle () =
    let r = ref [] in fun x -> let old = !r in r := x; old

would be semantically equivalent to

# let make_toggle () x =
    let r = ref [] in let old = !r in r := x; old

To get back the power of "make_toggle"-like functions, a special
function call could be added that would break eta-equivalence:
  call_now(make_toggle, ())
would have the semantic "make_toggle()" has in today's caml.


The rationale for this change would be that "make_toggle"-like
functions are seldom used, whereas "map"-like are used a lot.
Differentiating syntactically them would be nice.

But i don't think such a big change would do caml any good:
- are "make_toggle"-like functions really seldom used?
- performance drawbacks?


(i've been toying around the syntactical pb of partial application:
 http://merd.net/choices_syntax.html)
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners