Re: Packages/modules

[David Kastrup]

Urs Liska <address@hidden> writes:

> OK. The *current* behaviour of oll-core is:
>
> * loaded packages and modules (let's for now keep the existing names)
>   are accounted for in an alist.
> * if the requested package/module is already loaded:
>   * if options are passed, try setting them (overriding defaults
>     and/or values set by an earlier loading)
>     => This behaviour has to be discussed

Sounds to me like overriding defaults is perfectly reasonable (else
specifying options wouldn't work at all) and overriding values set by an
earlier loading should flag an error.

Maybe packages should have two ways of overriding a default: set a
default and require a value.

A request in a user document is always treated as a requirement, two
packages setting defaults leads to an error (or a warning and a revert
to the original default?) unless some package (or the user) requires a
particular setting which takes priority.  And of course different
requirements cause an error.

Or is this too contrived, and only requirements should be allowed?

>   * of no options are passed simply continue
>   * (exit)
> * look up the file (according to some logic (separate discussion)
> * if the file is found load the package/module
> * otherwise issue a warning, suggesting follow-up errors might come

I think the usual course should be an error.  Warning only if using a
special optional load (separate command or option for that).

>> And of course Guile has modules.  Do we already have a thought about
>> how
>> to relate to the module system?  
>
> Yes, that's right! \loadModule is definitely a bad name.

I was not as much worrying about the name, actually, but about the
semantics.  Seems to me like defaulting to a separate module might be a
reasonable thing.  It would require exporting whatever you want to use
from outside the module.

> In LilyPond there's a fundamental difference between \include and 
> #(use-modules, which is not the case in oll-core. There "modules" are
> essentially the same as packages, just used to organize packages in a
> hierarchical fashion:
>
> * scholarLY includes modules:
>   * annotate
>   * choice
>   * staff-cancellation
>   * ...
> * snippets can be addressed like
>   \loadModule oll-misc.layout.horizontal-spacing
>
> Actually it would make transition smoother if we choose completely new
> names for the functions.
>
> So:
> * I suggest not to discern between "use/load" and "require",
>   just have one command that behaves like require.
> * (caveat: handling of config options when given to a
>   secondary call)
> * Is the "\load" prefix the best choice?
>   * \loadPackage
>   * \usepackage
>   * \use
>   * \package
>   ?

LaTeX has \usepackage and \RequirePackage either of which don't really
match LilyPond naming conventions.  A bit of a pity: I'd have opted for
\usepackage otherwise.

> * Do we need a word for the (current) "module" at all?
>   What about
>   \use scholarly.annotate
>   or
>   \use \with { subs = annotate.choice } scholarly
>   ?
>
>
>> With regard to namespaces, there may be
>> something to be said for requiring explicit export in the long run?
>> 
>
> Although I know this is important I don't feel comfortable having an
> opinion about this type of issue.

Ok.  One thing to think about is that we want package files to be
contributed by "ordinary" users.  But something like

\exportSymbols transposeSequence,instrumentGroup,scratchMyBack

would be perfectly feasible syntactical sugar.

-- 
David Kastrup