Re: 2.16 release candidate 3 imminent

[David Kastrup]

"address@hidden" <address@hidden> writes:

> After reading through this e-mail, I'm ok with the patch with one
> caveat about regtests (see below).
>
> On Jan 22, 2012, at 9:08 AM, David Kastrup wrote:
>
>> Music expressions _represent_ the input, as opposed to stream events
>> which represent the typesetting task.
>> 
>
> If this is truly the distinction, then I understand the need for the
> change.  I didn't realize that music expressions needed to be
> one-to-one and onto representations of the input.

They are an intermediate level.  They don't _need_ to be anything.
Music functions are a useful tool for manipulating music at a level much
closer to input than stream events are.  They are employed in _several_
layers in the parser: for postevents, for base material, inside of
chords.  If they can do their work context independent, you don't need
to make them cater for different contexts.

In the context of writing music functions, #{ ... #} is a useful tool.
Since it fires up its own parser, its result is not context dependent.
You can't, for that reason, currently employ it usefully in chord
context.

If I write
myC =
#(define-music-function (parser location) () #{ c #})
then I can't currently write
<\myC>4 or similar.  It would just not work.  And there is no way to
define this function, #{ #} or not, in a manner that could work both in
chords as well as outside (without a Rhythmic Event iterator).

> This is the part that I have the most trouble imagining, not because I
> don't trust you, but because I don't follow the code well enough to
> know how it would result in this.  I'd like to see regtests in one of
> these commits that uses two or three simple functions in the form \foo
> c and <\foo c> that show this distinction.

Is the above simple enough?

-- 
David Kastrup