Hi,
in my quest for getting things to work more straightforwardly, I am
currently stuck on several frontiers. With regard to parsing music
function arguments, I have in some instances adopted a principle of
"lazy complication". For example, assume that you are in lyrics mode,
and a music function asks for an argument. Coming up is
"string"
Now "string" (actually with or without quotes) can be either a string,
or it can be a lyrics event.
What the music function call does, is running _both_ tentatively across
the predicate. If neither works and we are looking for an optional
argument, the optional argument gets skipped (or if it is non-optional,
we get a syntax error). If it works only as a string, it gets accepted
and we move on. If it works only as an event, it is parsed as an event
including any following parts of an event. If it works as either, it is
parsed with an open mind, stopping when encountering a token no longer
fitting into either category, and is returned as the simpler of the
valid variants. Of course, your predicate better not accept or refuse
arguments based on, say, their duration, or Lilypond's choice of what it
is going to look for might be premature.
I am currently more or less blocked on two endeavors:
a) unifying the treatment of pitch and duration arguments with the rest,
so that you can ask for things like "duration-or-music-or-markup".
b) a good scheme for integrating music functions inside of chords with
the rest.
Currently, music inside of chords consists of note-event material with
articulations initialized by their individual postevents, whereas music
outside consists of event-chord material, with the note-event material
from the individual chord elements followed by the chords postevents.
The "principle of lazy complication" would keep material as simple as
feasible until a more complicated version is asked for.
That is, when a music function asks for a "scheme?" argument and the
input is just c', it gets a pitch. If it asks for a "ly:music?" event,
it gets a NoteEvent (not an EventChord). If it asks for an EventChord,
it gets one.
You could write a function
typecast =
#(define-scheme-function (parser location pred arg) (procedure? scheme?)
#{ $(define-scheme-function (parser location x) (pred) x) #arg #})
and you could, say call
\typecast #ly:duration? #4
and get back a duration.
Somewhat less pleasantly, you can say
\typecast #ly:music? #"text"
What's less pleasant about this? The duration would have to be either
kept unassigned, or assigned to the current default duration in the
parser. The latter would happen "naturally" when writing
\typecast #ly:music? $"text"
or you can tack a duration on yourself:
\typecast #ly:music? $"text" 4.
(this would not even need the typecast in a music context).
Another disadvantage is that you don't get more complex things than you
ask for. That makes \displayMusic and \displayLilyMusic work quite more
straightforwardly, but it also means that if you expected to disassemble
an event-chord for simple input, you'll get surprised.
Another disadvantage is that assembly-on-demand can't track the origin
of simple things like pitches or strings, since only after becoming a
music expression can origin info be attached, not while it is still a
pitch or duration or string or unsigned.
It also means that after
x=c'
that x will likely contain a pitch instead of a music expression. This
is not all that tragic since you will be able to use it in pretty much
all circumstances where a music expression can be used. But if you
depend on it being a more complex type, you might be unpleasantly
surprised.
All in all, such a change should make programming and inspecting data
structures much more straightforward, and particularly save the
programmer from the "let's see what complex structures Lilypond creates
from simple input and devise a scheme how to get at the simple things we
actually wanted" phenomenon.
But it is definitely not going to be an upwards-compatible change.
It would remove the stumbling blocks for the listed two problems, and
will make things nicer overall.
Anybody has a better idea?
--
David Kastrup
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
