Version française
Home     About     Download     Resources     Contact us    
Browse thread
RE: [Caml-list] variant with tuple arg in pattern match?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ 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