The following fails with cannot read name of undefined inside the shouldBox function.

Grammar = {
  constructAllParses: function() {
    for (;;) {
      const thiz = this;
      ret = ret.concat(
        function(kids) {
          return thiz.applyAction(rule, kids, sppfNode.pos, semActions);
        });
    }
  }
}

20 minute compile times are not reasonable.

We're trying to optimize these things, let's measure them too.

Recent changes to make stopify produce runnable files have broken the demo webpage. Fix it.

This test case currently fails in Fission. Verify that Stopify handles it correctly:

var assert = require('assert');

  var skipped = false;
  var i = 0;
  for (; i < 2; i++) {
    if (i == 0) {
      assert(skipped === false); 
      skipped = true;
      continue;
    }
  }
  assert(i === 2);

js_of_ocaml has sourcemaps which means ocaml will be able to use the stepping and breakpointing features in the IDE.

We should prefix all generated variables with $ to avoid capture and make it easier to debug later down the line.

We need a better readme. The first paragraph is lifted from our NEPLS talk, which makes no sense to include in the README for software. The rest needs to be updated.

Add more here as we encounter them.

String

• replace

Array

• every
• filter
• find
• findIndex
• forEach
• map
• reduce
• reduceRight
• sort

I came up with a hack to replace the new handler with one that works for callCC:

699a9f9

It is theoretically possible for the callCC transformation to desugar the handleNew function, but it isn't worthwhile.

Here is what I suggest. Let every transformation have a runtime module. Let the runtime module export the new handler. We can assume that the runtime is imported as $__R (or some standard name). Then, desugarNew can invoke $__R.handleNew.

Functions that are imported, or more generally, functions transformed by the CPS transform need to be marked. The way that CPS does it does not work for the following test case:

const assert = require('assert')

This can fixed by marking all the functions that are transformed in the CPS transform and then checking on that flag before applying.

• DesugarSwitch + DesugarLabels (commit 13677a5)
• DesugarLoop + DesugarLabels
• (DesugarLoop + DesugarLabels) + DesugarLoopToFunc (assumes all loops are while loops)

js_of_ocaml has sourcemaps. Let's use it instead of BuckleScript.

I think they were browserify'd, and that doesn't mix with our webpack step to run things in-browser.

The integration of stopify with the pyret compiler needs stopify to be a require-able module. An programmatic interface like ones used by BuckleScript and Typescript will probably do for now.

We should eventually decide what functions to expose through this library.

Some of the JS benchmarks are using eval. Additionally, Emcscripten also makes use of it.

We should start supporting it. Since implementing eval would require the entire compiler infrastructure to be imported, the implementation should detect eval and only include the compiler if eval is being used.

See comments on commit 2287246

Names of first order functions that are marked as 'flat' can be used to remove useless wrapper code around corresponding function applications.

This is using path.rename(id) which is backed by babel's generateUid. We should re-write it to use our Identifier generator.

Break transformation is still broken. It was not being reported in the desugar tests because loopToFunc transform was disabled for some reason.

This can be done by setting an opts object on the AST.

The readme is out of date. There is are new ways to compile programs and compile them. Update the readme to reflect the changes.

Add all of the OCaml benchmarks from the operf-micro library. Currently we have two, of which, only one works.

The transforms should produce individual runnable files as output. The file should export a single function that takes all the arguments as the Stoppable argument currently does.

• CPS
• Trampolined CPS
• Yield
• Regenerator Yield

For every language we get working, we should add a simple "hello World" program. The program should be compiled to JS and browserified so it can run as a standalone. Simply add this test to test/should-run/source-language/.

Currently we have two ways of passing options to transform: one style used by yield and another one used by the jumper transform.
Instead we can do the following: Pass the whole process.argv object from the stopify binary to the transform and let it handle it.
Or, we could add options for each of the transform through commander (command line parser).

It may be the case that a subsequent transformation deals with the output of desugarSwitch. However, when applied in isolation, desugarSwitch produces invalid JavaScript. This will be an issue if we want to use it to do the Pyret-style transformation.

The high-level issue is that desugarSwitch eliminates the switch statement but leaves enclosing break; statements intact. A break; statement jumps out of the innermost enclosing loop or switch statement. So, with the switch eliminated, we either get (1) a syntax error if there is no enclosing loop or (2) wrong result, if we jump out of an enclosing loop.

The solution would be to enclose the output from desugarSwitch in a labelled block and turn the break;s into labelled breaks.

Here is the smallest example. This program, which does not raise an error:

function f() {
  switch(0) {
  case 0:
    break;
  }
}

f();

Is transformed to this program, which raises a SyntaxError:

function f() {
  {
    let _test = 0;
    let _fallthrough = false;

    if (_test === 0 || _fallthrough) {
      _fallthrough = true;

      break;
    }
  }
}

f();

Use src/ for transformation code only. Other code should be kept separate.

RacketScript overflows CPS. Write the CPS transformer in CPS so that this stops happening.

Yo, I heard you like CPS, so I CPS'd your CPS, so that you can CPS in CPS.

This happens when the function being called is not declared in the file. Consider the program:

let assert = require('assert');
assert(true)

which gets turned into:

let assert = require('assert');
let gen  = assert(true)
run(gen)

which is incorrect.

Need to do something about it.

This issue with the JS selenium bindings causes the firefox runner to timeout: SeleniumHQ/selenium#4041

@baxtersa also reported issues with the firefox driver.

We should not be stepping inside the runtime library, so it doesn't make sense to add a yield expression on every single line.
Currently, the code adds a yield expression before every statement. Instead of doing this, add a yield expression at the start of the function, and then only add a yield expression if the line has an associated number.

• bitops-nsieve-bits
• crypto-aes
• string-unpack-code

This one seems to infinite loop, it has a while (true) loop

• access-fannkuch

• crypto-aes
• string-unpack-code

Since programs are evald synchronously, mocha can't stop non-terminating programs.

To fix this, we need to spawn a new thread for each test and kill it after a timeout.

const assert = require('assert');

function myfunc() {
  return 10;
}

myfunc = function() { for (var i = 0; i < 2; i++) { }; return 20; };

assert(myfunc() === 20);
console.log("Should print");

1. Find a better way to test this bug.
2. Fix the bug

This is was the example I was trying to give the other day. Consider the two programs:

var x = 10;
var f = new Function("return x")
console.log(f())

and

(function () {
  var x = 10;
  var f = new Function("return x")
  console.log(f())
})()

The first one will execute and output 10 while the second one will error out with x is not defined. Since jumper wraps the whole program in a function. We will also see the same failure there.

I'm not sure if it makes sense to focus on this because both webpack and node break the first program. I am leaving this here as documentation.

NOTE: To see the failure, you need to use the browser because even node has the same problem. Run the first program in a tab in the dev tools and run the second program in a new tab.

the direct and wrapper strategies for new can make use of flatness information.

There is some issue with this benchmark. It works with ./bin/run compiled.js but not with ./bin/run --yield 100 compiled.js

Not sure what the issue is yet, but this is the common theme among all the failing CPS tests.

Prototypal inheritance does not work because of the way we transform newExpressions into .call with a new empty object on the function generator. Any properties that the function is inheriting does not get inherited by the empty object.

Known Hack: If nothing else works, we can duplicate definitions for the functions in order to have a constructor function that returns this.

I believe desugarNew is broken. What if the program has a function with the same name as one of the known built-in constructors?

I really want to get everything in a state where all the tests pass on travis. This requires fixing the few tests that fail on CPS.