]> 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