Dynamically loadable language libraries

[unthingable]

Adds ability to load alternative languages via lang command. ATM this is a PoC, comments and critique welcome and appreciated, especially on ways to better name and organize things, currently they be clunky.

Default behavior of Orca is unchanged. Language implementations can be replaced on the fly with the lang command:

• takes a ;-separated list of names
• languages are loaded incrementally, each can (re)define all operators, or some, or even none at all
• original implementation is called default
• clr is a special name, removes all operator definitions

Internally, the language is a dict of operator definitions, now there are several, placed in library directory where library.js originally was. For now, only the original (default) and base (not useful by itself but added as a basis for new definitions).

New language definition foo can be added by defining library.foo, and then:

• lang:foo to load foo operators on top of default (or currently loaded composite library)
• lang:clr;foo to clear definitions and then load foo operators
• lang:clr;default to restore default behavor (with current default clr is probably unnecessary unless there were different operators not defined in default that needed unloading)

Changes:

• Moved library.js to library/default.js
• library changed from an object of operators to object of objects of operators, original library became library.default
• Added lang command
• Added this.library attribute to Orca class, for dynamic overloading
• Current lang name is displayed for first 25 frames (frame counter resets when changing languages)
• Updated README.md

[unthingable]

Editor ate trailing spaces, sorry.

[unthingable]

One of the uglier parts. Is there a better way to organize and load these so that new definitions can be added without modifying index.html? Can one JS file import another?

Ideally this would be user loadable.

[unthingable]

A way to provide documentation for alternative languages is obviously needed, as well as some additional implementations.

The hackability is very well done in Orca, this was a fairly simple change thanks to that. I hope I didn't break that.

[unthingable]

An open question: how to organize files in library/ directory and prevent name collisions if it gets big.

Because of incrementality language definitions can be as small as a single operator (loaded after default). Then the convention could be:

• One file per language definition
• Multiple definitions grouped together, one file per contributor? Per "collection"?
• Name prefixes assigned per collection? E.g. orca123 for Orca language from version 123

[unthingable]

Also, "language", "implementation", "spec" and "library" have all been used to name the same thing (a collection of operator definitions comprising the language). What should the canonical name be?