Re: Data structure for (package) options

[David Kastrup]

Urs Liska <address@hidden> writes:

> Am Dienstag, den 28.01.2020, 00:34 +0100 schrieb David Kastrup:
>> Urs Liska <address@hidden> writes:
>> 
>> 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?

a) the storage format is something you should not worry about with
   regard to efficiency
b) xxx.xxx.xxx syntax for organising material should not be shied away
   from if convenient since it is comparatively straightforward to stop
   alists from being a mandatory underlying data structure
c) don't choose between tree or flat organisation for reasons of
   efficiency: only take user convenience into account

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

This prescribes a particular data structure.

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

in contrast will at the _current_ point of time use a particular data
structure but we can do a switcheroo underneath in some near future.

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

I think that our basic data structures should be accessible at the
LilyPond syntax level without even going down into Scheme.

-- 
David Kastrup