Re: Naming _another_ lacking puzzle piece

[David Kastrup]

"Trevor Daniels" <address@hidden> writes:

> David Kastrup wrote Sunday, October 14, 2012 9:21 AM
>
>
>> "Trevor Daniels" <address@hidden> writes:
>>
>>> 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.

Well, I did the detective work of tracking down _when_ the change was
made (October 2005 by Han-Wen).  So there is already a history of
LilyPond with this decision made differently.  The decision, however
little record of its motivation I have been able to dig up beyond the
commit itself, was not an accident.  There was clearly code added for
that exact purpose.  "Who does not know history is bound to repeat its
mistakes."  It would appear that we _have_ a history, we don't know it
any more, and I suspect we are bound to repeat its mistakes.

So I am trying to reverse-engineer the reasons for that decision, and
what I arrive at appears plausible to me.

And the current discussion appears to match my conclusion, this
conclusion being "for typical use of these user-level commands,
stack-like semantics appear to cause surprises that most normal(TM)
users are not well-equipped to deal with."

The current programming layer and naming conventions for Scheme
programmers are a misleading piece of incoherence, but at the LilyPond
user level, a reasonably straightforward non-stack behavior is the
default.  A stack depth greater than 1 can only be caused by
non-user-level code, and that non-user-level should be written in a
fashion cleaning up after itself.

What \temporary does is provide a LilyPond interface for writing such
non-user-level code cleanly.

-- 
David Kastrup