caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: "Dave Berry" <Dave@kal.com>
To: "Daniel de Rauglaudre" <daniel.de_rauglaudre@inria.fr>,
	<caml-list@inria.fr>
Subject: RE: [Caml-list] variant with tuple arg in pattern match?
Date: Tue, 10 Apr 2001 13:17:09 +0100	[thread overview]
Message-ID: <DD7356599083414BA450E3DCC4119B8B06C435@NT.kal.com> (raw)

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


             reply	other threads:[~2001-04-10 12:19 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-10 12:17 Dave Berry [this message]
2001-04-10 13:12 ` Marcin 'Qrczak' Kowalczyk
2001-04-10 21:26   ` Bruce Hoult
2001-04-10 22:34     ` John Prevost
2001-04-10 13:51 ` Frank Atanassow
  -- strict thread matches above, loose matches on Subject: below --
2001-04-10 17:33 Dave Berry
2001-04-10 22:34 ` John Prevost
2001-04-10 17:25 Dave Berry
2001-04-10 23:16 ` Marcin 'Qrczak' Kowalczyk
2001-04-08  0:22 jgm
2001-04-04 11:04 Chris Hecker
2001-04-04 18:47 ` Alain Frisch
2001-04-04 19:18 ` Patrick M Doane
2001-04-04 19:36   ` Chris Hecker
2001-04-04 19:49     ` Daniel de Rauglaudre
2001-04-05  8:19       ` Christian RINDERKNECHT
2001-04-04 19:49     ` Patrick M Doane
2001-04-06 13:52   ` Xavier Leroy
2001-04-07  1:42     ` Patrick M Doane
2001-04-07  6:44       ` Daniel de Rauglaudre
2001-04-07  7:42     ` Fergus Henderson
2001-04-08 19:45       ` Pierre Weis
2001-04-08 20:37         ` Charles Martin
2001-04-08 23:57         ` Brian Rogoff
2001-04-09  0:22           ` Alain Frisch
2001-04-09 16:07             ` Pierre Weis
2001-04-10  8:23               ` Michel Mauny
2001-04-10  9:14                 ` Xavier Leroy
2001-04-10 10:09                   ` Michel Mauny
2001-04-10 10:44                 ` reig
2001-04-10 11:32                   ` Michel Mauny
2001-04-10 11:47                     ` reig
2001-04-10 12:10                       ` reig
2001-04-10 12:35                         ` Michel Mauny
2001-04-10 12:49                         ` Marcin 'Qrczak' Kowalczyk
2001-04-09  6:23           ` Mattias Waldau
2001-04-09  7:34             ` Daniel de Rauglaudre
2001-04-09 15:57           ` Pierre Weis
2001-04-10  9:07             ` Sven LUTHER
2001-04-09  8:20         ` Christian RINDERKNECHT
2001-04-10  2:54         ` Patrick M Doane
2001-04-10 19:04           ` John Max Skaller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DD7356599083414BA450E3DCC4119B8B06C435@NT.kal.com \
    --to=dave@kal.com \
    --cc=caml-list@inria.fr \
    --cc=daniel.de_rauglaudre@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).