Re: Packages/modules

[Urs Liska]

Am Mittwoch, den 22.01.2020, 11:43 +0100 schrieb Urs Liska:
> Am Mittwoch, den 22.01.2020, 11:06 +0100 schrieb David Kastrup:
> > Urs Liska <address@hidden> writes:
> > 
> > > Am Dienstag, den 21.01.2020, 11:19 +0100 schrieb Urs Liska:
> > > > > 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.
> > > > > 
> > > > 
> > > > I'll be more verbose than probably necessary, just to make sure
> > > > we're
> > > > talking about the same thing.
> > > > 
> > > > ...
> > > > 
> > > > If I got you right then from my experience with openLilyLib and
> > > > creating project environments (which basically are the same as
> > > > packages), I would say:
> > > > 
> > > >  * I'm all for hiding names in packages by default and having
> > > > to
> > > >    explicitly expose/export the package's interface
> > > >  
> > > 
> > > One more implication: If variables and functions have to be
> > > explicitly
> > > exported it will be easier for external tools (like Frescobaldi)
> > > to
> > > add
> > > proper support for extensions.
> > > 
> > > I assume that at one point Frescobaldi will
> > > 
> > >  * know about available (core and external) extensions
> > >  * provide ways to "use" an extension (as part of the Score
> > > wizard
> > > and
> > >    locally)
> > >  * at that point know about the options that can be passed to
> > > that
> > >    package
> > >  * provide autocompletion and highlighting for available symbols
> > >    exported from extensions
> > >  * provide actions to generate the code for getting and setting
> > > package
> > >    options
> > > 
> > > So when planning the syntax of that export it would be good to
> > > take
> > > the
> > > needs/interest of IDEs into account that will not work with the
> > > result
> > > as LilyPond does but that parse the package files themselves.
> > 
> > Maybe we should have single-command exports after all
> 
> You mean that a package has to export every function or variable
> separately? I think that would be good wrt self-documentation.
> 

This gave me another idea: How would it be if elements (functions,
variables, whatever) exported by packages would have to be addressed
through a package namespace:

* scholarly.annotate exports \criticalRemark
* this can't be used with \criticalRemark but (syntax of course up to
the parser maintainer ;-) ) \scholarly.annotate.criticalRemark

That way the global namespace would be less pollutable, and identical
names in different packages wouldn't be an issue.

A user can still do something like

  criticalRemark = scholarly.annotate.criticalRemark

as a local shorthand.

Urs