Yes, I was thinking about that, and the Abstracttext implementation used to allow for implicit currying.

The advantage of *not* allowing implicit currying is that we have a stronger shape of the function call that we can test.

So, if implicit currying is forbidden, then any function call with fewer than the expected number of arguments becomes a validation error. We catch them early.

If implicit currying is allowed, all of these wouldn't be errors, but instead of an integer (or whatever), you suddenly get a function back.

I think the latter is potentially confusing and requires even beginners to be exposed to, well, curried functions and anonymous functions as return values.

If we require explicit currying, we don't lose any of the functionality - everything we could do before we still can do - but we lose some notational convenience for currying (which is kinda of a poweruser feature) but will probably catch much more errors than we would otherwise.

That would be my thoughts on implicit currying.

Denny



On Sun, Oct 18, 2020 at 8:47 PM Subramanya Sastry <ssastry@wikimedia.org> wrote:

> Regarding the Currying: that should not be a problem either way,
> though, if I understand right. So assume that we have a function curry
> Z78 and the concatenate function Z142.
>
> Z1K1:
>   Z1K1: Z7
>   Z7K1:
>     Z1K1: Z78
>     Z78K1: Z142
>     Z78K2: "Wiki"
> K1: "data"
>
> So here we use curry(concatenate, "Wiki"), which results in a function
> that takes a single string and prepends "Wiki" to it, so that would be
> read as curry(concatenate, "Wiki")("data")

Is there need for an explicit currying function? Can currying fall out
naturally out of the implementation? i.e. Z142("Wiki") might itself
return a Z-object which is a Z8?

Subbu.


_______________________________________________
Abstract-Wikipedia mailing list
Abstract-Wikipedia@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia