Hoist enclosed references

[rkoeninger]

The $.functions and $.symbols objects are replaced with a $.globals object whose values are Cell objects that contain properties for f (functions) and v (symbol values). eternal function has been added that gets or (adds and returns) a Cell for a particular name of function or symbol. Could be separate objects, but just kept them combined like in ShenSharp.

Fabrs are re-integrated from the attempt at statement-oriented syntax. Fabrs now carry a JS expression and a map of substitutions. Each lambda gets wrapped in an immediately-invoked lambda in order to enclose over the eternal-ized Cell objects for the global functions, symbol values and idle symbols (to prevent repeated invocation of Symbol.for) in that function scope.

• Added Fabrications and functions for working with them
• Added globals, Cell, eternal
• Pre-rendered kernel hoists eternal global references all the way to the top of the kernel init function's scope
• Updated to Shen 21.2

[rkoeninger]

apparent performance improvement as of 527aae4 (hoisting & enclosing over idle symbols) :

scenario	prev	curr
test suite (sync)	11s	7s
test suite (async)	1m 4s	56s
web startup	1200ms	950ms

these are on my fairly fast machine, but as relative times, they look good

working on hoisting reference cells containing global functions

[tizoc]

Those numbers look great.

[rkoeninger]

At this point, Firefox startup time has only improved from 25s to 22s.

[rkoeninger]

Hoisting global function references has resulted in no noticeable performance benefit strangely ( a603055 )

It's also significantly increased the size of the deployable bundle (~700KB to ~1100KB)

On the other hand, Firefox startup went from 22s to 16s so I guess we're keeping this change.

[tizoc]

@rkoeninger what does the transformation entail? (sorry, I don't understand what is going on in that commit you linked).

[rkoeninger]

Replacing reference Cell objects with a 2-element array had no effect on performance so I'm reverting that.

[tizoc]

Ahhh, ok, but it is just a matter of representation, right? Not what you described here to be able to reference the functions locally (with an indirection to allow redefinitions, but still locally): https://github.com/rkoeninger/ShenScript/issues/7#issuecomment-526446503

[rkoeninger]

Yeah, that last comment about Cell vs array was just how the container that holds onto the optional function pointer and optional symbol value are stored. Accessing an array index might have been a little faster than a named object member, but with small objects with consistent structure, I don't think it makes a difference. JS engines are good at optimizing objects as long as their keyset doesn't change.

[rkoeninger]

More cleanup to do before merging, but I think this is as good as it gets for the hoisting & enclosure concept.

I was having trouble when trying to hoist & enclose idle symbols that started with capital letters, at least in some instances, not sure why. Like $.t($.l(F => F(s`X`))) being converted to (X$sym$ => $.l(F => F(X$sym$)))(s`X`). It wasn't a problem until testing more involved defprologs and datatypes.

[rkoeninger]

@tizoc Updated PR description if that answers any other questions

[tizoc]

Accessing an array index might have been a little faster than a named object member, but with small objects with consistent structure, I don't think it makes a difference.

Yes, that was the conclusion I got after doing some tests, Array and fixed-structure object were the same

[rkoeninger]

Might refine this more over time, but it's working so I'm merging.