Re: [Caml-list] variant with tuple arg in pattern match?

[qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk)]

Tue, 10 Apr 2001 18:25:27 +0100, Dave Berry <Dave@kal.com> pisze:

> There are two levels of semantics here.  At the higher level, we have
> the behaviour that the programmer is trying to communicate, which
> distinguishes returning a function as a result on the one hand from
> passing multiple arguments on the other.

Sometimes it distinguishes that, sometimes not.

Cases when they are not distinguished seems to be common among
functions taking functions as *arguments*. Consider
    let flip f x y = f y x
How would you write it in the uncurried style?
    let flip (f,x,y) = f y x
    let flip (f,x,y) = f (y,x)
    let flip f = fun (x,y) -> f y x
    let flip f = fun (x,y) -> f (y,x)
    let flip (f,x) -> fun y -> f y x
    let flip (f,x) -> fun y -> f (y,x)

It tries to distinguish too much. flip transforms a binary function
to a function which takes its arguments in the opposite order. flip
transforms a multi-argument function to let it take its first two
arguments in the opposite order. flip takes a binary function with
its second argument and returns the appropriate partial application.
flip takes a binary function and its arguments and applies the function
to the arguments in the opposite order.

All these interpretations are correct. They describe the same thing
in different ways. I see no point in being forced to distinguish them.

> The lower level is how this is encoded in the programming language.
> With currying, there is no difference between the two, so information
> has been lost.  With multiple arguments, the distinction is
> maintained.

I would say the opposite. The uncurried style requires to introduce
some grouping of arguments. This grouping is not necessarily inherent
to the problem at hand. The concrete syntax introduced an unnecessary
distinction.

-- 
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK

-------------------
To unsubscribe, mail caml-list-request@inria.fr.  Archives: http://caml.inria.fr