The post was more generally addressed to JavaScript developers (as an accompanying material to a presentation I’m working on) so I’ve tried to keep the text as practical as possible in the context of JavaScript programming.

But as I remarked on, the post wasn’t academically correct, more precisely the examples I’ve used had a specific purpose of incorrectness. Skipping that part for now, let’s just see what exactly currying means to its true definition.

In mathematics and computer science, currying is the technique of transforming a function that takes multiple arguments (or an n-tuple of arguments) in such a way that it can be called as a chain of one argument functions.

If we where true to that definition, a function add(a, b, c, d) in a curried form would actually be representable in JavaScript under the following form:

Now, for a second let’s suppose that we could actually curry a function to that form. As far as I was able to reason and do, the only possible variant was a curry function with on-demand currying.

I’ve tried my best with that one without succumbing to tempting human sacrifice. Some javascripters with knowledge in JavaScript’s darker arts may enlighten me on a better implementation; I have no doubts in such a thing.

Anyway let’s see that curry function in action:

While an interesting hack, it’s far away from being a curry function. In fact, there is no single curry function in any JavaScript library, no matter how functional it calls itself. Search for curry in these libraries documentation here, where the author is even nice enough to offer an explication:

Note that, unlike in languages with true partial application such as Haskell, curry and uncurry are not inverses. This is a cause to the fact that in JavaScript, unlike Haskell, a fully saturated function is not equivalent to the value that it returns. The definition of curry here matches semantics that most people have used when implementing curry for procedural languages.

And you could pick the Prototype documentation, or the one for underscore and you’d get the similarity between them and the one in my earlier article; but they are still not the currying function.

Anyway, what I’m trying to go at, their role in JavaScript serves as partial application functions; that being the basis of my previous post, where in spite of incorrectness, I wanted to make it clear that there is difference between the two that is not generally very clear to new developers (without functional programming knowledge, that is).

In the voice of a great man, Live long and prosper

But from all these concepts, the last two seem to be in many places used interchangeably, or so may they seem from various articles and code snippets spread over the internet. Don’t get me wrong, I am responsible for such confusion myself, and my co-workers can blame me for it on that time when I tried to explain partial function application.

That, ends today, because I’ve gotten my facts right and demistified these two strange concepts that seamingly do the same thing.
Now, in order to get this started I’d think the best approach should be to start with a formal definition:

In computer science, partial application (or partial function application) refers to the process of fixing a number of arguments to a function, producing another function of smaller arity. Given a function f:(X × Y × Z) → N , we might fix (or ‘bind’) the first argument, producing a function of type partial(f):(Y × Z) → N. Evaluation of this function might be represented as fpartial(2,3). Note that the result of partial function application in this case is a function that takes two arguments.

Given a function f of type f:(X × Y) → Z , currying it makes a function curry(f):X → (Y → Z). That is, curry(f) takes an argument of type X and returns a function of type Y → Z .

Where the following definitions could be used for papply and curry:

papply  : (((a × b) → c) × a) → (b → c)
curry   : ((a × b) → c) → (a → (b → c))

Now let’s try to define these two functions in JavaScript (the only programming language that everybody knows?)

Before we can safely proceed onwards let’s fiddle around with these two functions in order to get the hang of it:

As you can deduce from the sample code above, it is very clear that in our case we can define one as an application of the other. And let’s do just that with our papply function.

Partial application IS dependent on function currying. And if we’d done our implementation correctly, the following equation should hold true:

curry papply = curry

Again using our previously defined functions (including add) we’ll see if we got it right:

I highly recommend playing with the code in either Firebug or JsFiddle to get the hang of it.

As much as we’d like people to strictly fill in data into forms, they get annoyed and complain when the http:// prefix is mandatory. As such I had to create my own validator which is a little more permissive over symfony’s default URL validator.

Sometimes I really find user feedback bothersome.

For each number in the list, it spawns a process waiting an amount of time equal with the number received and afterwards prints its.

Brilliant, I would say.

So how did it go?

Well, once the problem clicked the solution was writable in a couple of minutes (like of what I assume was the case with most of the problems); but never having played with IO before in Haskell (of course I’m still a beginner) I copy pasted the input – output routine from Real World Haskell.

My solution looked marvelous:

Until today when I’ve seen rst76′s solution:

And found about interact. Now marvelous doesn’t quite fit as a description for my solution.

note to self: y u no read complete page?

Almost, because even with a clear specification of the expected result I still managed to lose focus for a moment, and went for a “fancy” solution that doesn’t quite qualify as a solution. What I want to say is that instead of returning a list ordered with the people who have died, I have only returned the last person killed.

The “fancy” part of it is, that it returns the last person killed by solving the problem for each varying number of people from 1..n.

Considering it’s 2AM, I’m going to leave it as it is and pretend that everything went better than expected :)

For the correct Haskell solution check the first comment on the challenge page.

Also found a couple of variations of the Haskell solution on reddit.

P.S.I would have had it right if I would have sticked with my first idea consisting of a cycled list and an incrementing step.

I’d rather have Haskell books that first point out the mathematical abstraction, and afterwards actual Haskell code. Just inspect for yourselves the following two function definitions.


Now if you’d only know the basics of function definitions in Haskell, I’d think that this example would make it very easy for you to understand function guards (and in a broader sense pattern matching).

Or were we?

Some may have known this, or would have read the whole page in the PHP manual, but setting the connection to passive mode has practically no effect if it is issued before the user is logged in. So the correct solution was:


If you would still like to say that the FTP library is a mere protocol implementation, just think that it offers non blocking procedures and handling of FTP SSL connections. The later being part of a different RFC than the FTP protocol.

And it does not stop here, even when people abstract further away the FTP library they still stick with the same leaked implementation detail. Sure, the command pattern would be a good candidate for a solution, but what argument could one give to make them add a bit more complexity in their abstraction for a disputable benefit.

No one, and that is why the current state of development consists of leaks all the way down.

Piece of cake I said, made another branch from the trunk and integrated my branch in it, conducted a svn branching/merging 101 workshop to my team mates (which have never used/heard of branches/tags before), and wrote a document on the steps required for merging new code from trunk to the branch deployed on our test environment. Gave the most basic rule to follow:

Always before switching make sure no local modifications exist. Diff and revert if necessary, but don’t switch around until your local copy is clean.

Two weeks in everything seemed fine. Then BOOM, the seed was planted; because one day one of the developers, and I’m not going to point fingers, made a commit without the files generated by our ORM. Someone else noticed it after deploying the code on production and running the ORM code generator. Being asked about it I said the solution is simple:

Just add the files to subversion and you’re done with it.

Without other questions they poured a bit of water on the seed, by adding the files not on trunk, but on the branch from our test environment. Day was over, it was time to go home. Next day, back in the office and I’m asked why subversion has flagged more files that the ones that where changed on trunk since the last merge.

It’s just svn, version 1.5.x really likes to go nuts with mergeinfo properties.

And the seed flourished.
Minutes later stuff, that shouldn’t have, got broken on our test server… what? One look into subversions log and almost all files have gotten property changes upon the last merge.

The reason? The subversion switch from trunk to branch got broken somewhere, leaving around a large number of files still pointing to trunk. And as with the mechanical way they followed my written down merging operations issued a commit, task finished.

But what’s the seed got to do with this? The only reason the switch failed was because the mentioned ORM generated files where unversioned on trunk, but had incoming adds upon the switch.

Three hours in, I brought back the code to stable version on both branch and trunk (committing was done to both due to the partial switch).

But no, the story doesn’t end here. Even after stabilizing both source trees, another problem popped up, I could no longer synchronize the branch with trunk. The all so mystical mergeinfo property conflict appeared.

The now tired developer used: svn merge trunk --accept theirs-full
It was super effective.

p.s. Might have not sounded too horrific for you, but I remember the face my project manager made when I tried to explain him the issues.