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
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
