Re: Future of OpenLilyLib

[Valentin Petzel]

Hi Jean,

> I would change the tense:

>

> [Independently of OLL,] non core developers *are* able to implement

> new features with Scheme code that *can* potentially be included in

> base LilyPond if proven reasonable.

>

> Don't you agree?

I do agree that users are able to implement feature with Scheme code, but handling of such code is usually a matter of copying snippets, eventually outsourcing them into a file. With a module interface a user could implement his feature as module and publish this module. Then it would be very easy for other users to use this feature in own project, and we might see: Some modules are experiencing so frequent use that they might be well suited for actually being part of core Lilypond.

I did not intent to say that non core developers have absolutely no way of testing out functions, but that it would be much easier to have an ecosystem where such functions can be tested.

> It is true that not every feature fits. However, in practice, I

> have encountered few features that fit neither in an LSR

> snippet, nor in LilyPond's core, nor as some kind of mix between

> the two where the core receives some generic tools useful for

> other purposes as well, while the LSR snippet makes use of these

> tools for a very specific purpose.

But this might just be a result of the missing infrastructure :). If the extension methods we offer are simply snippets then it is clear that we will mostly get snippets and be bound to snippets. On the other hand a module could be thought as a snippet+.

> - a module should only be loaded once, even if imported twice in

>   different locations,

> - a module could (optionally?) have its own namespace (Guile module

>    object) with private definitions, and only export the definitions

>    it needs.

I think Include files provide something similar to loading modules, but in the most primitive form possible, that is simply text insertion. I do agree on your points. @1: A Lilypond file could simply start with a declaration of required modules, which are then sourced at the start. @2: Definitely sensible, unnamespaced modules are prone to unwanted behaviour.

I’d add that a module could not only contain ly files but also scm files, and they could be loaded similar to base Lilypond’s scm/* and ly/* files, allowing for control bigger than a single session. Then we could simply use define-public for public definitions.

Cheers,

Valentin

signature.asc
Description: This is a digitally signed message part.