lilypond-user
[Top][All Lists]
Advanced

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

Re: stemNeutral problem


From: David Kastrup
Subject: Re: stemNeutral problem
Date: Thu, 13 Sep 2018 16:38:11 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Aaron Hill <address@hidden> writes:

> Token(s)            Stem.direction (Stack)
> ------------------------------------------------
> \stemDown           Down           ()
> \once \stemUp <{>   Up             (Down)
> \stemNeutral <...>  <undefined>    (Down)
> <}>                 Down           ()
>
> This behavior is identical the first version, where now neutrality is
> indicated by a lack of value.  It is still slightly counter-intuitive
> because the effect of \stemNeutral does not persist beyond the scope
> of the \once.

The current behavior tries to keep surprising behavior close to the
cause of the surprise.  Basically it prefers "huh?" over "WHAT?!?!?!?!".
It's not trivial to do significantly better.

> This discussion is particularly interesting as I have found myself
> working through "Principles of Compiler Design" (Aho/Ullman) again
> after having perused it far too quickly when I was much younger and
> much less equipped to fully appreciate it.  One relevant realization I
> have is that it seems there is no worthwhile amount of effort one can
> expend to design a language with precision and unambiguity such that
> it can fully prevent someone writing nonsense as input.  I think it
> was Chomsky who came up with something like: "Colorless green ideas
> sleep furiously."

Chomsky was more about differences in being well-formed and
well-meaning.  I mean, between syntactic correctness and semantic sense.

I'd not attribute "nonsense" to the input written: such combinations
easily come about when combining various settings into semantic blocks
and such blocks into meaningful actions, and that is actually exactly
what happens when the equivalents of \graceOn and \graceOff influence a
block of properties that are useful to change for other reasons as well.

For some things, the stack model works well.  For some other, less well.

-- 
David Kastrup



reply via email to

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