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