Re: Solution for including a file only once

[Hans Aberg]

On 11 Feb 2010, at 18:18, Michael J. O'Donnell wrote:

> At present, I am seeking an add-on solution, involving a definition  
> that
> I can put in a utility file to include. I think I am near finding  
> that.
> I am not ready to hack the lexical analyzer, and I think that should  
> be
> pondered carefully, particularly when a global reconsideration of  
> syntax
> is planned. But at some point, a better integrated solution is  
> desirable.

It may not be so difficult, it has the lines:
<INITIAL,chords,lyrics,figures,notes>\\include           {
         yy_push_state (incl);
 }
 <incl>\"[^"]*\"   { /* got the include file name */
         string s (YYText ()+1);
         s = s.substr (0, s.rfind ('"'));

         new_input (s, sources_);
         yy_pop_state ();
 }

So add something like:
<INITIAL>\\import           {
         yy_push_state (impo);
 }
 <impo>\"[^"]*\"   { /* got the include file name */
         string s (YYText ()+1);
         s = s.substr (0, s.rfind ('"'));

         new_input (s, sources_);
         yy_pop_state ();
 }

with a check if the module has been loaded before, perhaps by making a  
variation of new_input() if LilyPond saves the filenames somewhere.

> Haskell and ML have put a lot of thought into modules, which I think  
> are
> much better conceived than objects in C++.

They come from different traditions, I think. C++ just tries to add  
support for a common C programming practice, where a name space means  
adding a prefix.

Haskell actually does essentially the same, but checks if the module  
has been loaded.

> I don't know Hans' programming ideology, but I think that
> systems like LilyPond should follow best programming language practice
> as much as possible. No matter how simple designers expect the uses of
> the system to be, later practice almost inevitably goes into regions
> where the more advanced structure is important. And I think that  
> modules
> are near if not at the state of the art for organization of  
> programming
> information.

I thought that perhaps getting some hooks might give ideas on how to  
move ahead.

> The association
> of \include with the lexical level is like the old C preprocessor
> attitude. That sort of lexical manipulation is often a good choice  
> in an
> early design, when one is not sure of the right structure, and first
> attempts at good structure tend to be too restrictive. But by now we
> know how to do better without being too restrictive.

LilyPond has expanded to such a degree that it might be beneficial  
with some module system.

> I noticed that Guile also has a module system, and I have a generally
> good impression of the thinking behind Guile. As long as LilyPond uses
> Guile, the first thing to see is whether it can use the Guile module
> system directly for this sort of organization. The Guile macro  
> system is
> also a possible hook for include-like things. Include is essentially a
> parameterless macro invoker. Guile follows work in the Scheme  
> community
> to apply macros at the syntax level instead of the lexical level. Once
> syntax is well defined (which it has been in LISP much longer than in
> other languages), that is usually a better approach than lexical-level
> macros. Modules take similar facilities to the semantic level.

So it might be good if LilyPond can use the Guile module system.

  Hans