lilypond-devel
[Top][All Lists]
Advanced

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

Re: Naming _another_ lacking puzzle piece


From: Trevor Daniels
Subject: Re: Naming _another_ lacking puzzle piece
Date: Sun, 14 Oct 2012 10:26:39 +0100

David Kastrup wrote Sunday, October 14, 2012 9:21 AM


> "Trevor Daniels" <address@hidden> writes:
> 
>> Joe Neeman wrote Sunday, October 14, 2012 12:14 AM
>>>
>>> In other words, we have a "pop-push" and a "pop". In the context of
>>> Reinhold's email, you were suggesting (although perhaps not seriously)
>>> adding a "push". Now, I'm happy to have "push" and "pop," but I think
>>> "pop-push" is a bad interface for a stack. The reason that we have gotten
>>> away with it for so long is because our interface ensures that the stack is
>>> almost always empty anyway (since the only way to "push" is with \once, and
>>> that always pops immediately). Once we start talking about composability,
>>> the deficiencies of pop-push become clear.
>>> 
>>> So my proposed set of orthogonal commands would be push and pop (again,
>>> with more intuitive names). I also suggest adding clear for convenience.
>>> Everything else would be syntactic sugar on push and pop.
>>
>> I would be happier with this change.  Why not just change the action
>> of \override to be push alone?  As its current implementation pretty
>> well ensures all the stacks are empty, changing its action to be push
>> rather than pop+push would have a limited effect on existing scores,
>> wouldn't it?
> 
> Exactly _because_ the current implementation pretty well ensures that
> all the stacks are empty or close to empty, changing its action to _not_
> ensure empty stacks would have a _large_ effect on existing scores.

I'm not so sure.  Scores which contain matched \override-\reverts would
continue unchanged.  Scores which use \voiceOne-\oneVoice would
continue unchanged (other than a build-up of stacks, but Joe's suggestion
to change \oneVoice to a clear-to-default action would fix that).  Scores
which contain sequences of \overrides to the same stack would maybe 
behave differently on a \revert, but how common is that likely to be?
People using sequences of \overrides are likely to not use \revert, rather
just setting the property to whatever value they want next.  But this
would cause stack build-up.  How serious is that likely to be in practice?  
(A real not a retorical question.)

(I want to pursue this in order to end up with the simplest possible
interface consistent with correct behaviour.  It will be undeniably
harder to explain, and for the users to understand, an interface which
provides both the 'flat' implementation and the push/pop implementation.
I'd rather ditch the flat one and concentrate on explaining push/pop
(maybe using different words) rather than trying to explain both.
Whatever reasons Han-Wen had for adopting a flat implementation
in 2005 may no longer be valid.  We need to consider the optimum
implementation suitable for LP as it is today - taking both functionality
and understandability into consideration.) 
 
>> I think the point is that \undo will never be ostensibly be written with a
>> following \override but rather as \undo \voiceOne.  Its action then would
>> be to pop all the \overrides within \voiceOne, returning the state to
>> \voiceThree, \oneVoice, or whatever it was before \voiceOne was
>> called.
>>
>> Even so, if the \undo\override did not exactly match the top of the stack 
>> it should throw a warning.
> 
> The warning could only be thrown at the time the music is actually
> iterated, not at the time the \undo is encountered.  That would mean
> that \undo\override would have to write significantly different data,
> presumably creating music types of its own.  The warning would be
> generated at an unexpected time of interpretation.  I don't really think
> this is worth the trouble.

OK, you're probably right, but it will cause surprises.  But maybe to
no greater extent than other features and only to users who don't 
inwardly digest the documentation (once written).

Trevor

reply via email to

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