]> Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp> writes: [...] > Another problem is that it is asymmetric: partial applications could > be polymorphic, but not results containing several functions: > > let both f = (List.map f, List.iter f) sorry, i don't understand that pb. [...] > let toggle r x = let old = !r in r := x; old > let make_toggle () = let r = ref [] in toggle r or worse: let make_toggle toggle = let r = ref [] in toggle r no way to know how many parameters toggle can have, so no easy way to eta-expand. I think it *can* be done at evaluation time, but I'm not sure. so my response to Francois Pottier was wrong: >> > # let apply f x = f x;; >> > val apply : ('a -> 'b) -> 'a -> 'b = <fun> >> > >> > ... You can write applications of `apply' with any >> > numbers of arguments. >> >> you're right... but this isn't a problem for the stuff i'm talking. >> >> If "wrapping-restoring-eta-equivalence" is done based on the number of >> parameters *before* instanciation of type variables, it will do. which was wrong: (even if Francois didn't bother telling :) # let id f = print_string "foo" ; f no simple way to eta-expand. Once again, I think it *can* be done at evaluation time... [...] > So, this seems unlikely such changes would go through. i'm aware of this :) I wanted to note that partial application semantic is somewhat nasty when combined with eager evaluation, and that syntactically & typefully separating functions-returning-functions and partially-applied-functions could ease understanding. One way to do this is to add sugar for partial application of tuples, and having tuples the *default* way of passing parameters. (once again http://merd.net/choices_syntax.html :) Thanks! ------------------- 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