Re: Naming _another_ lacking puzzle piece

[David Kastrup]

Reinhold Kainhofer <address@hidden> writes:

> On 2012-10-13 09:32, Werner LEMBERG wrote:>> Maybe \push\override
> ... but this has the disadvantage that you
>>> never actively see a \pop.  Hm.  Maybe we should rename \undo to
>>> \pop then?
>>
>> I think that we either need a consistent use if \push and \pop, or we
>> should refrain using it.  Given that the Scheme functions handling the
>> stack are not mapped one-to-one to user commands, as you've shown in a
>> previous mail, I think we should avoid \push and \pop.
>
> To me it is not only this inconsitency, but rather that the names
> push/pop come from programming languages and concepts.

Uh, that is because they are a plastic visualization here?

> Lately, I have seen many suggestions that would turn lilypond more
> into a programming language and away from being a description of
> music.

Reality check: LilyPond already _has_ stacks for properties.  Nobody
forces you to use any of the new commands if you don't care for stuff
working in a better organized manner than flat variables would give you.

> Now, while lilypond really is a programming language, in the past we
> have tried to hide the concepts (e.g. queue theory) from the user,
> with more or less success.

You can _perfectly_ well keep the user uninformed about what you call
"queue theory" and have things work (and break) just as they do now.

> David's attempts to get rid of the #' in propery names is a great step
> in this direction, but using push/pop would be a huge step in the
> wrong direction, IMO.

Nobody forces you to use them.  They are a solution to a problem you
refuse to acknowledge, so there is no need for you to deal with them.
You don't want property values saved on the property stack, so you are
perfectly free to save them somewhere else using \applyContext and
restore them from wherever you saved them.  I don't quite see how this
makes LilyPond _less_ of a programming language as it means quite more
cumbersome programming, but of course you can do that, or ignore the
problem altogether and deal with the cost of that.

But then there is no reason to complain that others _get_ the tools for
working with the mechanisms LilyPond provides internally.

The main motivation is to be able to provide user-readable ways of
writing _working_ versions of \crossStaff without strange side effects.
As you probably never want to _read_ the functions in
music-functions-init.ly anyway, there is no reason to be annoyed just
because people have been able to write working functions using LilyPond
rather than the Scheme interfaces make-grob-property-set or
make-grob-property-override.

You are _not_ forced to write better working music fragments than
before.  But there is no point in making it harder for others and for
the people writing parts of LilyPond herself to work with her.

-- 
David Kastrup