Re: tiny function

[Thomas Morley]

2016-07-01 11:50 GMT+02:00 David Kastrup <address@hidden>:
> David Kastrup <address@hidden> writes:
>
>> Thomas Morley <address@hidden> writes:
>>
>>> 2016-07-01 7:05 GMT+02:00 David Kastrup <address@hidden>:
>>>> Thomas Morley <address@hidden> writes:
>>>
>>>>> %% works:
>>>>> tstII =
>>>>> \with { instrumentName = "foo" shortInstrumentName = "foo" }
>>>>> \new Staff \tstII { r1 }
>>>>
>>>> Issue 4911 is supposed to harmonize this by stopping the second example
>>>> from working.  This makes it possible to recognize the syntax without
>>>> knowing the type of \tstII in advance (could be a music expression,
>>>> leading to completely different structure).
>>>
>>> I'm in two minds here.
>>> Hormonizing code is always preferable, but being able to spare the
>>> extra \with would be nice as well.
>>
>> Why?  There are technical considerations underlying this change that are
>> also related to usability changes, like editors having a chance to
>> properly identify and indent parts of an expression.
>>
>> It is not possible to let an argument-less scheme function work in the
>> same manner/syntax as a fixed context modification works right now.
>> Fixing that comes at a high cost, basically requiring special-casing
>> scheme functions in a similar vein as now music/event functions are
>> special-cased.  Which is something that makes it impossible to create
>> structures of music/event functions and other things.
>
> Sigh.  I make a hash of my communication.  This sounds just like a rant.

Nah, I didn't understand it like that.

> But the "Why?" was actually an honest question.  A lot of the work I do
> is focused about making entry more convenient and better reflecting the
> writers' ways of thinking about music.  LilyPond has sort-of a free-form
> syntax that tends to create quite a few ambiguities.  So there are some
> balancing acts involved here.
>
> Now in this case I was working on some parser refactoring and it dumped
> out something like a dozen shift/reduce conflicts (meaning ambiguities
> in the resulting syntax in need of resolution) of which more than a
> third were due to the \with thing.  The particular stuff I was working
> on was of the
>
> xxx = ...
> \xxx
>
> variety where xxx needs to get consulted to decide whether it is still
> part of ... or not.  Now many such decisions can be made on the basis
> "anything of form \xxx cannot become part of ...".  For example, if I
> allow a.b and have seen a, I only need to know whether the next token is
> . or not, and I don't need to know what value/type \xxx has, only that
> it is not a period.
>
> But to make decisions on that level, \xxx basically falls into two
> tokens, the first just saying "this is an escaped identifier" and the
> second actually looking at the type of xxx.
>
> Now the parser works only with very limited and specific lookahead.  If
> I split escape sequences like \xxx into two tokens effectively, the
> parser stops being able to make some decisions timely that it currently
> still can do with a lookahead of a single token.
>
> I am still making a hash of my communication.  Being able to omit \with
> comes at a cost in complexity because
>
> \new Staff \xxx
>
> causes completely different syntactical meaning depending on whether
> \xxx is a context modification or music.  When writing
>
> \new Staff \with { \xxx }
>
> \xxx _still_ can be either a music expression (like \hide BarLine) or a
> context modification, but at that point it does not cause a complete
> rewiring of the parse tree: LilyPond can just evaluate, take a look at
> the resulting expression, and then decide what to do with it, namely
> _how_ to make it part of the resulting context modification.  There is
> still ambiguity but it does not influence how to parse the expression.
>
> So being able to omit \with comes at a cost, and it works only with
> fixed identifiers.  So how to justify the cost?  And that's where "why?"
> comes into play.  User friendliness is an argument.
>
> Now personally, I find it distracting to see something like
> \RemoveEmptyStaves without \with.  I haven't omitted it myself, and it's
> present in most of LilyPond's documentation and examples as well (the
> convert-ly rule has very little actual impact on the code).
> Independently of just having figured out or remembered that this thing
> comes at a non-zero cost in Bison parsing complexity.
>
> Obviously, that's not how you feel about the construct.

Well, not really. As said before, my feelings were ambivalent.

After reconsidering:

It's more a possibility I sometimes use. Mostly because of lazyness in typing.

Writing
\new Staff \with \some-function-returning-a-context-modification ...
instead of
\new Staff \some-function-returning-a-context-modification ...
is not a big deal. A few key-strokes nothing else ...
Though, I thought it was the OP's main point.


Otoh, we can store things like \paper, \layout, \midi, \with and as
off issue 4908 even \header in variables.
But when called, the variable needs to be wrapped in a proper manner,
sometimes not. Example:

ppr = \paper { ragged-right = ##f }

%% works
\book {
  \paper { \ppr }
  { ces''1 }
}

%% doesn't work
\book {
  \ppr
  { cis''1 }
}

%% works
\ppr
{ cisis''1 }

Admittedly, this example is about \paper not \with, more, I use always
fixed values no function calls and other things are coming into the
game.

Though, I'd love to see it consistent for all of \paper, \layout,
\midi, \with and \header, regardless if it's a function call or not,
regardless where called.

That said, I'd now vote _for_ implementing issue 4911 because it's a
step in this direction!
(I'll comment on 4911 for other things tomorrow)

> So I have
> historically already felt bad about the construct and avoided it, and
> the LilyPond code base does look like particularly embracing it either
> even though it's been basically available forever.  It's always sort of
> a bad feeling to let something stop working but I judged the cost and
> said "ok, nobody seems to particularly want that anyway".

As said a above, it's not a real problem for me anymore, but I'd like
to see others joining the discussion.
For me the indenting-problem with editors has a very low priority as
well, but that's only me again ...

> Obviously, I was wrong about that and need to reestimate the cost.
> I might still end up with the same decision after considering all
> available information.  But right now I am obviously missing
> information.
>
> --
> David Kastrup

Many thanks for the detailed informations and thoughts,
  Harm