Re: Data structure for (package) options

[Urs Liska]

Am Dienstag, den 28.01.2020, 00:34 +0100 schrieb 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.

I'm sorry, but I don't fully understand what you are trying to tell me
here. Are you saying that you already had some internal changes in mind
and that storing the package options in an alist is something I
shouldn't really worry about?

BTW: I mistook my own example (shouldn't have started writing late in
the evening ...). What I meant is storing the options in objects, not
assigning symbols:

  (define package-options
   `((edition-engraver . ,ee-options)
     (scholarly . ,scholarly-options)
     ...
    ))

with ee-options and scholarly-options having been bound to tree objects
before.

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

Yes, that's what I intended. It should be a tree implementation with a
given characteristic that basically noone should bother about. There
should be the *possibility* to drop-in a different tree implementation
(with the same interface) if for whatever reason a package might want
to do so (I could imagine that for some algorithmic use of the data it
might be reasonable to consider some sort of self-organizing tree to
optimize access times - but definitely not for the bread-and-butter use
case of package options).

Urs