Re: [GLISS] - alternative viewpoint

[Janek Warchoł]

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 (?).
(i write this just to provide you with feedback on the difficulty of
some of your emails)

> 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
?
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.

> #'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?

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.

> 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.

> 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.

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

ditto.

>     c) MusicXML?

ditto.

>> 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.

> Meta-bikeshedding makes some sense for prestructuring this space, but
> after that, filling in the blanks is pretty much possible for everyone.
> In some respects, this may be part of "personal style collections", but
> of course some stuff makes sense to be part of the core as well.

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
?

cheers,
Janek