glathoud / fext Goto Github PK

The recent improvements have broken some of the nashorn support.

Task: fix this!

After that fext.js is ready for integration into production.

AFAIK all browsers support a non-modifiable undefined so we don't need that extra variable __fext_undefined__, let's remove it.

Thanks to Frederico Kereki for the feedback.

https://github.com/glathoud/fext/blob/master/misc/d_performance_feasability/d_perf_feas.d

gives some first results on the isOdd/isEven example, things working fine so far. I guess in the D spirit of fast compiling it would be better to:

• stick with subfunctions (no self-made inlining/unrolling),
• have at most 1 or 2 expansion levels,
• and let the user actively set pragma( inline, true ) and call dmd -inline or equivalent.

To better evaluate the expansion, I guess the is0mod3/is1mod3/is2mod3 example is better. Won't write it by hand => Need to polish a bit the JS code generation, to make it easier to convert it to D.

Reason: performance would be great + mutual recursion syntax then allowed

see also https://github.com/glathoud/fext/tree/master/misc/d_performance_feasability

So that we can integrate fext's generated code directly in transfun: glathoud/transfun#7

[this deals with the generated code, in particular the tail call elimination]

Frederico Kereki suggested to use destructuring when "updating" the variables, so that intermediary variables are not needed.

Paying attention to performance and IE11 compatibility (=no destructuring), the plan would look like this:

• add a hidden option "destructuring", deactivated by default,
• measure the performance with and without destructuring, at least in FF and Chrome
• if positive results, make the option activated by default except in IE

Permits generally to write shorter code, and in particular in IE11 to make arrow functions easy to use, as in fext("x => x+1")

...and write up a bit about it

deactivate one or all code generations

For performance reasons it is often best to stick to direct parameter transmission, but that can lead to many parameters, as in the sortedSearch example, see #11

Reason (performance): when parameter names are simply "copied", the corresponding (superfluous) assignments can be completely eliminated by fext.js

Reason (implementation): we are using new Function which has no access to the target scope, so closure cannot be used.

Task: implement "argument macros" shortcuts as fext.__args in:

function sortedSearch(sortedArray, x, /*?fun?*/less, /*?fun?*/equal)
{
     // ....
      return improveFirst(  // UNCHANGED
            sortedArray, x, less, equal, isFirstFound, isLastFound
            , first_found, last_found, i, j, imax, jmin
        );
}

// ...

   // --- Private details

    function improveFirst(  // UNCHANGED
        sortedArray, x, less, equal, isFirstFound, isLastFound
        , first_found, last_found, i, j, imax, jmin
    )
    {
 // ...
  return mret(  // CHANGED
            improveLast
            , fext.__args
        );
    }

Other argument macros could be:

return mret( someFun, a, b, c, fext.__lastArgs );

// equivalent to:
return mret( someFun, a, b, c, fext.__args(3) );

and:

return mret( someFun, fext.__firstArgs, x, y, z );

// equivalent to:
return mret( someFun, fext.__args(0, -3), x, y, z ) 

The optional call syntax fext.__args(a [, b] ) would be similar to that of Array.prototype.slice

At the moment nashorn spits a strange error:

[error] fext: caught error while compiling the implementation: java.lang.NullPointerException
[error] #22 failed on graph_recursion_test: java.lang.NullPointerException

Within ES6 inlining could be feasable AND safe provided we forbid var within the bodies.

The sortedSearch example shows the suffering of having a great tool like new Function(...) but no access to the local context.

Until JS has tools similar to D's template mixins and string mixins, we might consider an optional activation of the One Evil Thing.

For more background, see the discussion on comp.lang.javascript.

Result

Added a .getImplEval method to support eval, as in:

    // First "declare" all functions so that co-dependencies can be
    // solved.
    //
    // Use `mfunD` to debug
    var improveFirst = mfun( improveFirst )
    ,   improveLast  = mfun( improveFirst, improveLast )
    ;
    
    // Now we can implement them, using evil access to the local
    // lexical scope so that we do not need to write parameters
    // repeatedly 5 times (see above `function sortedSearch(...)`).
    improveFirst = eval( improveFirst.getEvalImpl() );
    improveLast  = eval( improveLast.getEvalImpl() );

For a complete use case see sorted_search_local about here

IE11 supported