Re: [GLISS] - alternative viewpoint

[David Kastrup]

"Phil Holmes" <address@hidden> writes:

> OK - so there's been a lot of discussion of pre- and post-fix, and a
> load of other stuff I don't understand.So I had a think about what it
> is about lilypond syntax that p**s me off.  And I concluded that it's
> nothing to do with whether we write c4 /p for a quiet crochet c, as
> opposed to /p 4c.  I really don't care.  When I was a tyro, I just
> read that and accepted it. What does get me more concerned is how hard
> it is to find some of the correct ways of tweaking output.  Using
> voice.SomeValue (or is it Voice.someValue) when it should be
> staff.Somevalue (or was it Staff.someValue) frequently results in no
> change to the output.

Yup.  Here is my multi-stage plan for that:

a) an \override is really just a subset, namely a change of the context
property named after a grob.  For efficiency reasons, that context
property is not organized as an alist but something more complicated
implemented on top of a pair.  Properties have to be reorganized to
make a hierarchical \set strictly equivalent to an \override.

b) our C++ engravers announce to the type system (and via that, to the
documentation) which context properties they read, modify and write.
There is no reason that this does not also include the Grob descriptions
which are even now a special case of context property.

c) Scheme engravers have no way to "register" like a C++ engraver,
telling the type system what they want to be called, and which context
properties they are accessing.  This needs to change.

d) \override xxx is equivalent to \override Bottom.xxx, with Bottom
being a context without \defaultchild (to be recursively created from
the current context, if that is not a bottom context, by creating the
respective defaultchildren in sequence until hitting bottom).  If all
our engravers had correctly registered the context properties they read,
\override xxx could instead set the property in the context closest to
bottom that will actually _look_ at the changed property.

Of course, this is not without drawback either: if there are multiple
engravers looking at that property at multiple levels and you are
interested in overriding the behavior of the engraver in an outer level,
the unspecific override will be done in the inner level and again not
have an apparent effect.

However, it would be a second-tier nuisance instead of a first-tier
nuisance.

> And is it \override or \set?  And \revert or \override back to
> something else.  And finding what comes after the \override
> staff.Something - is it ##f. or #'4 or 4 or { 4} or what?

#'4 and #4 and 4 should be quite equivalent in most cases...

> If you follow what is asked on -user, it's this stuff that causes
> confusion, not pre- or post-fix.

One might argue that users who are able to write to a mailing list after
looking for it in the manual make up for less than 1% of our targeted
demographic group, users who come to LilyPond not primarily since they
enjoy being in total control over the data structures their typesetting
program uses.

And particularly for those it makes a big selling point if naive
expectations disregarding the technical necessities and implementation
constraints happen to hit the mark semi-regularly.  Of course, we can't
make that 100%, but 80% is a lot more encouraging than 2%.  If you get
everything wrong at first try, that's a big turnoff.  Even if some smart
helpful guy explains to you why everything is wrong.

> Now - I have no idea if this is possible or not, but when I put some
> of these complex overrides into my converter, the commands to the
> converter use a C-like syntax.  For instance, I've written a feature
> that allows the converter to scale durations:
>
> scaleDurationsOn(n,m)
>
> I personally think that providing more of these simple syntax features
> would make it much easier for the average user: we do have a few
> shortcuts of this type: for example:
>
> autoBeamOff = \set autoBeaming = ##f
> melismaEnd = #(context-spec-music (make-property-unset 'melismaBusy)
> Bottom)
>
> Why not focus on making the slightly complex part of Lilypond much
> simpler (not the very complex, like customer scheme functions - if you
> can do that, you don't need help)?

Quite agreed.  That is what I call "extending the vocabulary", and
making that feasible continues to be a main objective of my work on
music functions.  We got a few new people on the user list contributing
music functions so far, but those contributions are not convenience
wrappers but actually do complex jobs.

There are several lashback issues connected with convenience wrappers,
and they focus around the question:

    To what degree does a convenience wrapper become part of LilyPond's
    language?

There are several questions following from that starting point.

    a) reflection.  Should \displayLilyMusic recognize expressions that
    can be produced by a wrapper and output them?  If we answer "yes" to
    that question, it would make sense to provide some infrastructure
    for specifying appropriate reverse engineering rules to LilyPond in
    a manner that is not significantly more complex to specify than the
    wrapper itself.

    b) When and how are third-party tools supposed to learn about such
    wrappers when they are supposed to be part of LilyPond?

    c) MusicXML?

> And getting rid of case-sensitivity in a lot of this?

You need to elaborate.  It is not clear what you mean with that, and
what kind of remedy you envision.

> And providing error messages when an override has no effect because it
> was at the voice context and should have been at staff?

See above.  If the system knows what needs to be done, there is little
point in warning rather than doing it.  Of course, if "Voice" has been
explicitly specified rather than via the implicit "Bottom.", using the
same mechanisms and internally available information for producing a
warning seems reasonable.  Basically I prefer the behaviors:

a) implicit default choice is non-working -> make the right choice instead
b) explicit choice is non-working -> obey but warn

So with regard to "naive expectations", I consider it sensibly if
explicit ineffective instructions are not exchanged for something else
but a warning is provided, and implicit ineffective instructions are not
a desirable part of the feature set, so the implicit behavior should try
to fall back to effective behavior where this does not appear in open
conflicts with instructions.

-- 
David Kastrup