Re: [GLISS] - alternative viewpoint

[David Kastrup]

Janek Warchoł <address@hidden> writes:

> Hi,
>
> On Sat, Sep 15, 2012 at 10:20 AM, David Kastrup <address@hidden> wrote:
>> Yup.  Here is my multi-stage plan for that:
>
> Great!  It's inspiring to see such a big plan :)
>
>> 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.
>
> I didn't understand this part well, but it guess it's not that
> important to have me understand it now (?).

Take a look in the internals manual.  It knows which engravers access
which context properties.  A Grob is actually just a (substructured)
context property, so it can be documented in the same manner.

> (i write this just to provide you with feedback on the difficulty of
> some of your emails)

This is the developer list, after all.

>> 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.
>
> So,
>   \override BarNumber #'font-size = 5
> would actually result in
>   \override Score.BarNumber #'font-size = 5
> ?

Yes, that's the idea.  As long as you have no engraver at Staff level
looking at the BarNumber properties.  Maybe it would be more robust to
explicitly declare the default context for writing each property.  After
all, that is a one-time job.

Or declare an engraver "canonical" for some properties, so that if
_that_ engraver is moved, the default context moves along.  At the
current point of time, an engraver declares which properties it
reads/modifies/writes (why do we need all three?), and we might let it
declare which it "owns" with respect to the default context.

> Wonderful!

>> 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.
>
> I think i won't understand this w/o an example.

Write an engraver at Staff level which looks at currentBarNumber, and
\override currentBarNumber will just work at Staff level instead of
Score level.

>> #'4 and #4 and 4 should be quite equivalent in most cases...
>
> You mean that they are quite equivalent now or that we want them to be
> equivalent in the future?

Where function arguments are concerned, they are equivalent.  Not
everything is a function argument, and #4 or #'4 cannot be used as a
duration.

> Anyway, being equivalent in most cases is, in my opinion, only
> marginally helpful: exceptions to the "most cases" introduce
> confusion.  If we want to simplify things, we need equivalence in all
> cases.

4 has several different meanings, #4 is a number.  I don't think I want
#4 . to be a valid duration.

>> 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.
>
> If i understand correctly, you mean that we don't have many emails
> from people being confused by pre/postfix issues because these people
> never make it to the mailing list (i.e. they are too discouraged by
> their first Lily try that they quit immediately)?  I think you're
> right.  *We* may never notice that some change simplified things
> (because we're already used to Lily), but newcomers will.

I think that if your first five attempts to do something on your own all
end catastrophically, you'll just quit again.

>> 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?
>
> Good question.  I think this is what Graham had in mind when he wrote
> about "ly vs. ly++".
>
>> 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.
>
> I don't understand what you mean here.

\displayLilyMusic \once\erase Accidental

might choose to display \once\erase Accidental instead of

\once\override Accidental #'stencil = ##f

But for that there must be an easy way to teach \displayLilyMusic about
\erase.

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

If we extend that language, how will Scorio, NoteEdit, Laborejo etc etc
learn about this?

>>     c) MusicXML?
>
> ditto.
>

If we have a convenience macro translating a construct that is
representable in MusicXML (overrides in general are not), how can we
teach our MusicXML exporter to recognize and export it?

>>> 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
>
> +1!
>
>> Now one might argue that this currently is rather a discussion on
>> meta-bikeshedding, namely getting something right that will serve as
>> a template for future bikeshedding, but it is quite clear that with
>> convenience wrappers, everybody actually _can_ contribute his opinion
>> without requiring much expertise.  And it makes some sense as well
>> since we are, after all, trying to hit the sweet spot of naive
>> expectations.
>
> I don't understand what you mean.

You did not even quote the URL of the discussion I referred to, so I
suppose that you are just missing the context.

> You mean that we should fix the "general structure" first, and then
> everyone (i.e. beginners too) will be able to add syntactic sugar like
> autoBeamOff = \set autoBeaming = ##f ?

I don't know what you mean with "fix" here.  Most of the work I do puts
wheels on LilyPond's syntax, making it easy for the user to go where he
wants it to.  However, I tend to stay compatible, and I don't start on
extensive new definitions myself.  So I am basically creating potential
for easily extending and/or redefining LilyPond, but that does not, in
itself, extends or changes the normal vocabulary significantly.

-- 
David Kastrup