Why is the currying suffer so much on performance rather than take the method used by BuckleScript?

Chat
#1

I’m still learning PureScript and find it awesome. One of the thing that I find may quite influence the performance is how PureScript handles currying when compiles to JS. It returns functions for each of the argument, which as I think, may quite slow down the overall performance. However, another language BuckleScript also supports currying but seems with less performance penalty.

So my question is, what is preventing us from implementing the currying like BuckleScript?

2 Likes
#2

To save readers from researching independently and discussing based on different assumed ideas, can you describe how BuckleScript implements currying?

1 Like
#3

The reason I didn’t put it here is that I can’t say I understand it fully. I can, however, put an example here to be more illustrative.

let add a b = a + b;;

let add_1 = add 1;;

let () =
    print_int (add_1 2);;

This code generates:

// Generated by BUCKLESCRIPT VERSION 5.0.4, PLEASE EDIT WITH CARE
'use strict';

var Pervasives = require("bs-platform/lib/js/pervasives.js");

function add(a, b) {
  return a + b | 0;
}

function add_1(param) {
  return 1 + param | 0;
}

Pervasives.print_int(add_1(2));

exports.add = add;
exports.add_1 = add_1;
/*  Not a pure module */

The currying here seems to be inlined. I think we can do this as well, but for FFI, use a wrapper or something like that?

1 Like
#4

I think this simply falls into optimization not having been a priority. In general the answer to the question “why is this not as fast as bucklescript?” is pretty much always that it hasn’t been a priority.

#5

And why is that happening? I think the performance is quite important in general cases…

1 Like
#6

I think there are a few reasons for this. For one, there are other important features that would require breaking changes to implement. Since the community has suffered due to breaking changes in the past, core contributors are much more cautious about when and how to implement such changes.
For two, I think some of those optimizations are just hard. So, perhaps people start working on it, then get side-tracked by something and then possibly avoid working on that problem again for an easier one.

#7

People have finite time and not all communities are blessed with people who basically work full-time on those things. PureScript doesn’t have a big enough community to attack several of these fronts at once, being that there aren’t enough people familiar enough with the compiler to work on these things.

If the direction was somehow the other way around and expressive power had been neglected in favor of optimization I personally would simply not use PureScript, because I’m here for the expressive power and the largely unparalleled opportunities for abstraction. Someone can fix the optimization bit later, but when a language is established it’s extremely hard to actually add meaningful features with regards to abstraction.

There are languages that have been trying to add type classes (or some analog of it) for many years at this point but at best they get some neutered version of it or it simply vaporware.

I actually think in the general case is where it simply doesn’t.

It bears keeping in mind that projects like buckle script haven’t added any meaningful features to a language, they’ve simply chosen to translate code into another. Optimization, at that point, is basically the task.

PureScript is a new language with evolving features and significantly more features, so it’s not really a great comparison in terms of projects. Even more so when you take into account the relative size of the communities.

4 Likes