glathoud / js.metaret Goto Github PK

Bug: currently sub-resources are included backwards. Use case: building metaret_standalone.js

Based on one comment on my talk at mloc.js 2014.

There is already a warning if the user defines a metafunction without any metaret, which is valid but does not bring any optimization.

Now if the user uses metaret from within a normal javascript function

function f() { ... metaret ... }

then the code is not transformed, so the metaret is still present in the resulting code, and an error is triggered when evaluating the code.

Task: in this case give a more meaningful error message to the developer, before the eval.

Add support for convenience inlining of normal functions:

inline var result = f(x,y,z);

inline result = f(x,y,z);

inline f(x,y,z);

Requires hygenic renaming of local variables within the calling scope.

When re-parsing minified code false positive detections of regexps are triggered by a division sign because the current strategy is still too naive. This is a problem if we want to reparse the minified code - where most newlines have been removed - to e.g. further shorten it.

blah = x / y; ...... line goes further ...... ; foo = bar / bin

-> false positive with the current implementation: / y ..... bar / detected as a regexp because the identifier x is not taken into account.

Task: reject such false positive regexps.

Difficulty: we want to try to keep lightparse "light" i.e. without a full tokenizer (mmm maybe I won't avoid it in the long term, but for now this way if it goes). So we should not only reject the simple false positives but also prevent introducing false negatives:

for (...) /true regexp/.exec();    // Here the regexp is correct!
while(...) /true regexp/.exec();    // Here the regexp is correct!
do (...) /true regexp/.exec();  while ( )  /another true regexp/ ...  // Here both regexps are correct!
similarly with if(...) /true regexp/
similarly with else /true regexp/

See also the remarks at the beginning of section 7 of the ECMAscript 5 spec:

NOTE There are no syntactic grammar contexts where both a leading division or division-assignment, and a leading RegularExpressionLiteral are permitted. This is not affected by semicolon insertion (see 7.9); in examples such as the following:
14 © Ecma International 2011
a = b
 /hi/g.exec(c).map(d);
where the first non-whitespace, non-comment character after a LineTerminator is slash (/) and the syntactic context allows division or division-assignment, no semicolon is inserted at the LineTerminator. That is, the above example is interpreted in the same way as:
a = b / hi / g.exec(c).map(d);

At each step of the build, if there is a corresponding .test.js file, it should be executed in a sort of sandbox. If the test fails, then the build should break down ((over)write "empty" files with some error message).

(similar to issue #10)

Reason: the body of the metafun is going to be inlined.

finish a first version of jsm_out_mini

Following #16 js.metaret is ready for production usage.
A supplementary round of profiling of the js.metaret process itself cannot hurt.

Use case: pick some code to transform, replace all newlines \n by tabs \t and feed it into jsm2js

Won't work.

Background: in cases where the original metafunction (resp. function) is only used within metafun (resp. inline) then after converting the code to normal JS we may end up producing unused function declaration (basically code duplicates).

Unused means: not in the global namespace, not called or passed around anywhere at all.

Task: remove such a function. Not sure yet at which stage:

• right away during jsm2js (could help debugging: reduce confusion).
• at the next step (build).

function declarations only + function name must be unique else error (we only parse and change the code, we do not execute it at this point).

About closures:

• forbid inlining of a function from another file when the function body uses some external variables (closure).
• permit closure when inlining a function within the same file as long as there is no ambiguity on the external variables. Else forbid (error).

Probably related to regexp parsing of regexp code. Probably.

Reason: Switching file names and corresponding dependency calls is not practical. Looking for metafun/metaret (and inline) keywords should be simpler.

Hi.

I've hand-made a little npm package for js.metaret (https://github.com/i-e-b/metaret-npm)

If the generated js files included shims like this at the top

global = global || exports;
if (exports) {
    lightparse = require('./lightparse').lightparse;
    lp2fmtree = require('./lp2fmtree').lp2fmtree;
}

Then packaging for Node.js could be done automatically.

We cannot inline the body of a function that uses arguments, because the arguments would then (wrongly) point to the containing function. An explicative error should be thrown in such a case.

Add support for local namespaces e.g.

(function (global) {
  global.myFunc = myFunc;

  metafun myFunc ...

})(this);

Similarly to issue #7 but now for metafun in the mutual recursion case ("other" dependencies):

• when the "other" metafun is in another file... well we do not allow that at all, because most of the time mutual recursion involves tightly coupled metafunctions == on a similar or close order of abstraction. (Contrast this to the inline case, where one "mother" function needs to inline small tool functions possibly from another file == much lower level of abstaction == the programmer does not want to even think about the inlined body at the target place).
  • so all metafun must be in the same file.
• when all involved metafun are in the same file they are allowed to have bound local variables as long as they are share all of them == it is forbidden to have a bound variable in one metafun that has the same name as a bound variable in another metafun, but are actually different == homonyms declared in two different scopes.

Some (stupid) example to clarify the issues involving bound variables.

This is okay:

var a; // shared bound variable
metafun f(self) { ... var x = a + 1; ... metaret g;  }
metafun  g(self) { ...var x = a + 1; ... metaret f; }

This is also okay:

var a; // shared bound variable
metafun f(self) { 
... var x = a  + 1;... metaret g;  
    metafun  g(self) { ... var x = a + 1;... metaret f; } 
}

This is NOT okay:

var a; // bound by f
metafun f(self) { .... var x = a + 1;... metaret g; }
metafun g(self) { 
    var a;  // homonym: redeclared by g, same name, but different variable
    var x = a + 1;
    metaret f;
}

...because it leads to ambiguities when resolving the metafunctions into normal JavaScript function with while loop and the inlined bodies of f and g.

for convenience

This one is permitted (no cycle):

function a() { inline var x = b(); return x+1; }
function b() { inline var y = c(); return y+1; }
function c() { return 1; }

This one is forbidden (cycle, throw Error suggesting using metafun/metaret instead):

function a() { inline var x = b(); return x+1; }
function b() { inline var y = a(); return y+1; }

(stupid examples but clear)