[Top][All Lists]

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

Wish/suggestion: \import statement

From: Urs Liska
Subject: Wish/suggestion: \import statement
Date: Fri, 07 Nov 2014 11:41:42 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

There has been discussion every now and then about ways to include files only once, with different suggestions but no final outcome (IIRC).

I would like to re-raise the issue with a slightly different perspective.

I think one thing LilyPond could use is encouraging people to use *libraries*. Of course this is easily done, and I assume the majority of power users works that way. But everybody is probably doing it his own way, figuring out solutions and reinventing the wheel. So I think it could be valuable to think about more consistent ways to create and maintain libraries, both private ones and publicly available ones.

Encouraging people to create public libraries (and perhaps on the long run harmonizing that to a central repository) could also help extending LilyPond's functionality without the urge to push everything into LilyPond itself.

Well, this was preliminary context which is not absolutely related to my suggestion. Nevertheless I'd find an addition like the following useful:

Create a new \import command.
The naming isn't mandatory, but I think this is distinguishable from \include.

This command should only include the to-be-imported file if it has not already been parsed.

Additionally it could be a good thing to *selectively* \import material (similar to Python's from .. import). This would consider an "importable" file more like a real module entity than \include which simply includes text as if it were in the same file. It would be nice to be able to define functions (or any other variables, this would also work with music variables) in a module and only parse selected items from a module. Or a module could include submodules, and from the main input file one could choose to only include specific submodules. That way one could create large modules or libraries without forcing LilyPond to parse big amounts of code that isn't actually relevant for the current project.

Just one example to show what I mean:

A library with harmonic analysis tools. There are generic functions (like for aligning stuff) in the main module and submodules for step theory, pitch class theory and functional harmonics.

\import harmonic-analysis
would load everything at once (I'd even suggest this command working with symbolic names and not filenames).

\importFrom harmonic-analysis #'(pitch-class riemann)
would only load the two submodules.
(The submodule would have to \import the main module if it depends on code in it).

What do you think?


reply via email to

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