Currying define John Cowan (30 Jun 2020 22:16 UTC)
Re: Currying define Arthur A. Gleckler (30 Jun 2020 23:58 UTC)
Re: Currying define Shiro Kawai (01 Jul 2020 03:54 UTC)
Re: Currying define John Cowan (01 Jul 2020 03:55 UTC)
Re: Currying define Shiro Kawai (01 Jul 2020 03:58 UTC)
Re: Currying define Arthur A. Gleckler (01 Jul 2020 04:09 UTC)
Re: Currying define Shiro Kawai (01 Jul 2020 04:11 UTC)
Re: Currying define Panicz Maciej Godek (01 Jul 2020 09:21 UTC)
Re: Currying define Marc Nieper-Wißkirchen (01 Jul 2020 09:50 UTC)

Re: Currying define Marc Nieper-Wißkirchen 01 Jul 2020 09:50 UTC

Technically, you cannot curry (which should probably be called
"schönfinkeln"; see
https://en.wikipedia.org/wiki/Currying#cite_note-4) in Haskell because
all Haskell functions take only a single element. (This is true at
least unless product types are involved.) So I agree with Panicz that
the two Haskell forms are equivalent an no currying is going on.

For a programming language like Scheme, the notion makes sense, though.

Mathematically, it is just the adjunction going from Hom(X x Y, Z) to
Hom(X, Z^Y).

Marc

Am Mi., 1. Juli 2020 um 11:21 Uhr schrieb Panicz Maciej Godek
<xxxxxx@gmail.com>:
>
>
>
> śr., 1.07.2020, 00:16 użytkownik John Cowan <xxxxxx@ccil.org> napisał:
>>
>> What you call currying define is not genuine currying, though it is extremely useful.
>
>
> To be fair, all instances of the word 'curried' are in question marks, and the document does contain the following explanation:
>
> This feature, sometimes incorrectly called "currying" [...]
>
> On the other hand, a lot of things here depend on a point of view. If we consider Lisp functions to receive multiple arguments, then indeed this is not currying. However, if we consider them to receive a single argument that is a list, then I think that saying that it is explicitly parenthesized currying is non-controversial.
>
> I believe that e.g. Haskell's
>
>
> f x y = v
>
> is equivalent to
>
> ((f x) y) = v
>
> That is, both forms are equuvalent. (And both are curried)
>
>>   There is, however, a proposal for an adaptation of genuine currying: in this case, lambda invocation with too few arguments returns a procedure representing partial evaluation, whereas lambda invocation with too many arguments invokes the lambda with just enough arguments and then invokes the result (which must be a procedure) with the remaining arguments.
>>
>> See <https://github.com/johnwcowan/r7rs-work/blob/master/BeyondCurryingHemann.md>, which also links to Hemann's paper.
>>
>
> I have been doing similar experiments
>
> https://bitbucket.org/panicz/slayer/src/26a8b3ff05ad9d34a98a636d771e3875496f2d69/guile-modules/extra/common.scm#lines-514
>
> But in my experience, rather than increasing language's expressivity, it mostly adds confusion to the code base.
>
>