search

EMGroup / js-eden

Javascript EDEN
emgroup.github.io/js-eden
Other
10 stars 5 forks source link

Symbols looked up using ID not name #111

Open knicos opened 8 years ago

knicos commented 8 years ago

Remove names from symbols and their lookup, allowing multiple (multilingual) names for each symbol. This also allows the parser to generate more efficient array index based code instead of hashed string dictionary lookups.

ElizabethHudnott commented 8 years ago

I'm wary that this potentially has very negative side-effects for the kind of "craft" approach that Meurig and I are advocating the benefits of. The utility of advanced users like me, Jonny, higher level ability students and to some extent Meurig himself in being able to rapidly prototype interesting extensions by linking to JavaScript APIs has been one of the successes of the JS-EDEN to date. We really need to be able to do root.scope.lookup(name) in order to continue doing this. If multiple names return the same symbol and the compiler itself uses a different method call that uses IDs then that's cool though. It's also going to make debugging a pain in the arse, as the compiled code will be even more gobbledegook than it is now.

How great is the performance difference between arrays and hash tables? I kind of feel that it's the browser manufacturer's responsibility to write a decent hash table implementation. I also spotted that when in non-live mode the current implementation only performs a lookup once per script for EDEN code (without embedded JavaScript) and caches it in a local variable called something like _o_xxx.

knicos commented 8 years ago

A root.lookup function will still exist with exactly the same functionality.

Hash lookups will never be as fast as array indexing. The google optimisers are keen to point this out. I've run the tests: array iteration is 50x faster in my browser so I think this is well worth doing.

How often do we need to debug compiled code? If we can debug the eden form. Also, we have the translation tester for checking it maps to the correct javascript.

The current implementation caches everything in locals. However, this causes massive code bloat within javascript because of all the closures. (I'm talking gigabytes of javascript!!!).

knicos commented 8 years ago

The main reason for symbols without names, however, is multi-lingual.

ElizabethHudnott commented 8 years ago

Okay. That's good, so long as we're not losing anything.

I'm surprised that the difference is as much as 50x. Do we win a prize for having created the biggest JavaScript application?

I do regularly step through combinations of JavaScript and EDEN. I wonder, does JavaScript support something like Eclipse's "detail formatter" facility to convert the IDs back to names?

knicos commented 8 years ago

Another option is to simply switch the parser into a debug mode which means it uses the old (current) lookup mechanism when generating javascript.

Its 48.4x faster at array iteration on my machine, so we should at least help ourselves by getting every ounce of performance we can from the core and not suffer when people start building larger models.

ElizabethHudnott commented 8 years ago

Yeah, would be great to have the performance boost.

Switching sounds more portable solution than the "detail formatter" thing, as imagine it isn't possible to write cross-browser debugger plug-ins.

I'm still not quite sure how it would work though. Doesn't this permeate everything, as in, for example, the list of subscribers would become a list of numbers?

knicos commented 8 years ago

It does and is a big change that I won't be doing just yet.