lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Future of OpenLilyLib


From: Jean Abou Samra
Subject: Re: Future of OpenLilyLib
Date: Mon, 21 Nov 2022 23:28:37 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1

Le 21/11/2022 à 23:02, Kieren MacMillan a écrit :
Then they should definitely be added: those were things Urs and I discussed (a 
fair bit off-list) as principle obstacles to the integration of “external” code 
(mostly equivalent to OLL at the time) into the ’Pond ecosystem.


The first step to adding non-trivial things that need discussion
is opening an issue. Do you feel like doing that?


I feel like the moment we have a real module system, two things will happen 
fairly quickly:

1. Many \include files (which are, to be fair, pretty cumbersome, especially in 
any reasonably complex file set) will become modules… and modular stylesheets 
will suddenly become exponentially less of a headache to implement.

2. The uptake (and thus maintenance) of really-helpful-but-currently-obscure 
code (e.g., the EE) will ramp up.

What’s required to add those two things you’re talking about?



One would add a new keyword in the parser akin to \include
(\import? \load?). Not importing a module more than once
should be almost trivial (just remember which modules have
already been imported). The namespacing thing is less
trivial, but you can probably get along by creating a
new parser, and use-module! its namespace into the main
file's namespace, or its public interface if you want
to get public names only. You'd also need some sort of
syntax like

\public var = val

e.g.

\public func =
#(define-music-function ...)

as an equivalent of

#(define-public var val)

Again, some hacking time but nothing hard if you know a bit
about the parser, really. (But the entry barrier to the parser
*is* high.)

One additional idea of mine in the category of "I don't know if
it's a good or a bad idea" is structuring LSR snippets / modules
as


... module code ...

\endModule % or whatever name

... example ...


where \endModule would act as a "trap" interrupting the parsing,
but only if the file is included. If the file is compiled as
main, it would continue parsing, and after \endModule you could
put some examples and tests for the snippet / module functionality.


Jean



Attachment: OpenPGP_signature
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]