Re: Data structure for (package) options

[David Kastrup]

Urs Liska <address@hidden> writes:

> 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?

Before we devolve into an efficiency discussion here, let me sketch one
of my "should make sense" projects": our access of alists mostly is
through our own accessor function ly:assoc-get .  If the elements on an
alist could not just be a key-value pair but a hashtable (for looking up
key-value, of course) or a vector (I think I'd prefer it being 1-based
in spite of making the Scheme indexing less obvious), our lookup
routines should be able to deal with that.  Some alists could be
compressed on use, making things like drumtables and note alists
efficient behind the scenes.

Such a replacement would work transparently for things like

package-options.edition-engraver = #'ee-options

or similar.  So basically there is long-term potential for efficiency to
mostly become a non-issue.

> 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?

Whatever we do, it should be an implementation detail the user _and_ the
package programmers do not really need to know about.  There should be
accessors hiding the organisation.

-- 
David Kastrup