curriless for google closure advanced optimization mode

[bobzhang]

currently we already have quite non-intrusive attribute for curry support, we should pursue that the whole standard library and runtime generated JS code is curriless

for the user level code, we can emit a warning if its code depends on the runtime support of curry.

so far, the curry runtime support is the only blocking issue for google closure compiler advanced support, @copy did I miss anything?

[copy]

How about property accesses? Dotted access to properties can be renamed in Closure Compiler. For example the following wouldn't work:

var p1 = { x: 0 };
console.log(p1["x"]); // p1.x would work
var p2 = { "x": 0 };
console.log(p2.x); // p2["x"] would work

In order to call external code from CC-minified code, you're supposed to use externs, so this doesn't need to be provided by bucklescript. It's provided by the library authors and there are built-in externs for all browser apis. However, when we export code that is called by external code, we need to make sure that exported values are quoted.

To keep it simple we could generate all properties quoted when generating code for Closure Compiler, but that would inhibit some optimisations.

Here's some documentation on this topic: https://developers.google.com/closure/compiler/docs/api-tutorial3#propnames (there's more useful stuff on that page).

Out of curiosity, what about currying breaks?

[bobzhang]

for property access, I think we only need to be consistent for basic usage -- build your app using google closure compiler advanced mode (not for library)

for currying, we can emit an warning, it is pretty easy for user to make his app curry-less(see issue #471), we can have a flag to warn user when Curry is emitted

[copy]

for currying, we can emit an warning, it is pretty easy for user to make his app curry-less(see issue #471), we can have a flag to warn user when Curry is emitted

I don't think this a good idea, I'd like to have both currying and CC support. Can't we support both? Which behaviour of CC breaks the code?

[bobzhang]

We support currying and CC simple mode. But if you want to get CC advanced mode, user has to make sure it's currieless. (Note curriless does not mean user can not write curry function, only for some use cases compiler can not infer, user needs add attributes to help compiler infer) The other way is to patch CC to remove optimizations, that would be out of this project's scope

[bobzhang]

It's always sound and correct wherher curry or not, just needs some attributes to make CC advanced happy

[copy]

What's the state of this?

IIRC, the only problem with Closure Compiler was that it removes unused arguments, which breaks partial application. Another idea would be to make a special mode that stores the real arity, i.e. generate code like:

function foo(a, b) {
}
foo.arity = 2;

[bobzhang]

@copy this is my workflow, first use rollup which remove mostly unused code, and use google closure simple mode later, I found it works as good as google advanced mode for bucklescript generated code since we don't use OO too much.

[copy]

@bobzhang That was an excellent suggestion, resulting size is very close to advanced mode.

[aleksandersumowski]

Whats the current state of CC Advanced mode support? Is it planned in the future? Is rollup + simple mode currently recommended approach? Will it remain in the future?

[bobzhang]

rollup + simple mode currently recommended approach.
The conclusion is GCC is something nice to have but should not be bet on