Browse thread
RE: [Caml-list] variant with tuple arg in pattern match?
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Dave Berry <Dave@k...> |
| Subject: | RE: [Caml-list] variant with tuple arg in pattern match? |
You certainly can avoid currying in functional languages. Currying is a hack that was created to keep the lambda calculus as simple as possible. Currying lets the lambda calculus simulate two things: 1. Multiple arguments. Fine for the calculus, but in any language with tuples or records we can just write f(x,y), like everybody else. 2. Partial application. Again, fine for the calculus, but for languages this fixes the decision of which arguments can be partially applied when the function is defined, instead of where it is used. If we define functions with tuple arguments, we can introduce an explicit syntax for partial application, e.g. f(_,y). The explicit syntax is particularly useful for ML, because of the value polymorphism rule. In pure functional languages (and SML'90), you can write: let flatten = fold \:: [] In ML, this gives an error (at least at top level), and you have to eta-expand the definition: let sum l = fold \:: [] l With explicit syntax for partial application, you would write: let sum = fold (\::, [], _) Daniel points out that you will always be able to return a function from a function. But currying is a partly syntactic hack; it relies on function application being notated by juxtaposition. Without this hack, you have to write: let f = g (x, y) f (z) instead of: g x y z In cases where a function is explicitly returning another (as opposed to just simulating multiple arguments), I think the explicit binding describes what is happening more clearly. Incidentally, using juxtaposition to denote application makes it harder for the parser to detect some errors. This makes it more likely that the user will see a type error where a simpler parse error would have been more appropriate. An earlier writer in this thread has already pointed out that if some arguments are mistakenly omitted in a curried application, this isn't reported until the point of use (and there might not even be any uses, if the function is only called for its side effects). -----Original Message----- From: Daniel de Rauglaudre [mailto:daniel.de_rauglaudre@inria.fr] Sent: Monday, April 09, 2001 8:34 To: caml-list@inria.fr Subject: Re: [Caml-list] variant with tuple arg in pattern match? Hi, On Mon, Apr 09, 2001 at 08:23:40AM +0200, Mattias Waldau wrote: > If so, I don't think that curried syntax is something good. I agree with your arguments, but... but you cannot avoid currification in functional languages. Ok, all your functions take non curried parameters, but how do you write a function which returns a function? If it is: let f x = fun y -> blahblah ok, you can write it: let f (x, y) = blahblah But, how do you transform it if it is: let f x = blahblahblah...; blah blah blah; fun y -> blah blah Currification is inside functional languages, you cannot decide to ignore it. And in OCaml, currified functions are more efficient (mmm... Xavier, tell us if I am wrong). Besides, if you don't apply all arguments, you get typing errors (in most cases), anyway. -- Daniel de RAUGLAUDRE daniel.de_rauglaudre@inria.fr http://cristal.inria.fr/~ddr/ ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr ------------------- To unsubscribe, mail caml-list-request@inria.fr. Archives: http://caml.inria.fr