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