Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dynamically loadable language libraries #248

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

unthingable
Copy link
Contributor

@unthingable unthingable commented Oct 25, 2020

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

@@ -70,13 +70,13 @@ To display the list of operators inside of Orca, use `CmdOrCtrl+G`.

## MIDI

The [MIDI](https://en.wikipedia.org/wiki/MIDI) operator `:` takes up to 5 inputs('channel, 'octave, 'note, velocity, length).
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Editor ate trailing spaces, sorry.

<script type="text/javascript" src="scripts/core/library.js"></script>
<script type="text/javascript" src="scripts/core/library/library.js"></script>
<script type="text/javascript" src="scripts/core/library/base.js"></script>
<script type="text/javascript" src="scripts/core/library/default.js"></script>
Copy link
Contributor Author

@unthingable unthingable Oct 25, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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?

@unthingable unthingable mentioned this pull request Oct 31, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant