Re: Extension management, first sketch

[David Kastrup]

Urs Liska <address@hidden> writes:

> Am Montag, den 20.01.2020, 10:27 +0100 schrieb Urs Liska:
>> * A core extension library shipping with LilyPond will be initiated. 
>>   Extensions that are considered core functionality (prime
>> candidates:
>>   edition-engraver, stylesheets) will eventually be moved here from
>>   openLilyLib, additionally special functionality (e.g. gregorian.ly,
>>   arabic.ly) may over time be moved there to expose the difference
>>   between core functionality and use-case specific modules more 
>>   clearly. These tools will then be called through `\loadModule`
>>   instead of `\include`, which will be easy to handle with
>>   convert-ly rules. Probably it would be a good idea to eventually 
>>   expose *all* non-standard notation through explicit packages
>>   and have that nicely describe in the LM. This too will not be
>>   called openLilyLib.
>
> Thinking about it I would go one step further:
>
> Currently we have a /ly folder in the installation which contains core
> files like music-functions-init.ly on the one hand, and on the other
> hand optional files that users can \include for specific functionality,
> such as the ones I have given as examples above.
>
> I think now that *all* the files that are not included unconditionally
> but only upon user request should be treated as packages. This will
> make the code structure clearer, since there is a clear distinction
> between the files LilyPond needs/uses for its startup (then *all* files
> in /ly) and optional files at the user's disposition.

Seconded.

Regarding \loadModule :  LaTeX has \documentclass for defining a
document layout.  LilyPond does not have files dedicated to that purpose
yet so that's something for later.

With regard to packages, LaTeX has \usepackage from user documents and
the sort-of equivalent \RequirePackage from package code (not sure what
the rationale for the difference is, there may be something related to
when loading is allowed) and a counterpiece \ProvidePackage.

Emacs has
    require is a built-in function in ‘C source code’.

    (require FEATURE &optional FILENAME NOERROR)

      Probably introduced at or before Emacs version 15.

    If feature FEATURE is not loaded, load it from FILENAME.
    If FEATURE is not a member of the list ‘features’, then the feature is
    not loaded; so load the file FILENAME.

    If FILENAME is omitted, the printname of FEATURE is used as the file
    name, and ‘load’ will try to load this name appended with the suffix
    ‘.elc’, ‘.el’, or the system-dependent suffix for dynamic module
    files, in that order.  The name without appended suffix will not be
    used.  See ‘get-load-suffixes’ for the complete list of suffixes.

    The directories in ‘load-path’ are searched when trying to find the
    file name.

    If the optional third argument NOERROR is non-nil, then return nil if
    the file is not found instead of signaling an error.  Normally the
    return value is FEATURE.

    The normal messages at start and end of loading FILENAME are
    suppressed.

    [back]

and a matching

    provide is a built-in function in ‘C source code’.

    (provide FEATURE &optional SUBFEATURES)

      Probably introduced at or before Emacs version 15.

    Announce that FEATURE is a feature of the current Emacs.
    The optional argument SUBFEATURES should be a list of symbols listing
    particular subfeatures supported in this version of FEATURE.

And of course Guile has modules.  Do we already have a thought about how
to relate to the module system?  With regard to namespaces, there may be
something to be said for requiring explicit export in the long run?

-- 
David Kastrup