Data structure for (package) options

[Urs Liska]

I didn't have time to really think about much (about LilyPond) the past
week, just enjoyed seeing so much constructive discussion.

I think the first thing I'd like to go for with the package/extension
mechanism is storing and handling (package) options.

There are three use cases which are differently closely related to the
actual package mechanism but should be dealt with together:

 * package options
    * specified, typed and preset with default values by a package
    * handled by getter and setter functions
 * custom options
    * behave like package options
    * not associated with a package but explicitly called for in user
      code
 * custom data
    * use the option syntax/infrastructure to store arbitrary data
    * for example a music tree as described in Jan-Peter's templating

I think package options should be handled in one association list,
hidden in a Scheme module and only accessed by specific accessor code.
The list elements should have the package name as car and an option
*object* as cdr:

  (define package-options
   '((edition-engraver . ee-options)
     (scholarly . scholarly-options)
     ...
    ))

I expect the number of packages loaded in a document ranging from "a
few" to "a few dozens", so probably a simple alist should be the right
data structure?

Package and custom config options are organized as a tree. From my
experience so far the nodes in that tree have 1-10 children each, while
I can imagine this to be 20 to 30 or even 50 in rare cases, but surely
not more.

It seems reasonable to not store a package's options as a nested alist,
though. I'd rather consider using a tree implementation in a class,
which would for example make it cleaner to encapsulate the behaviour
and e.g. implement type checking in that class rather than in the
accessor functions, or enable alternative tree implementations if that
should become interesting for custom data storage.
We have a tree implementation in oll-core at 
https://github.com/openlilylib/oll-core/blob/master/scheme/oll-core/tree.scm
Would that be something to use here?

My idea is to put that in an .scm file, say, scm/options.scm, and the
accessor code in a file ly/options.ly.

Additionally there's a file ly/packages.ly that will define a
\usepackage command. \usepackage will check if there's already an
element in the options alist for the given package name, and if not it
will create one with a new tree object. The package file is then free
to register options which will implicitly be stored in the tree object.

Does that look like a viable approach?

Urs