Re: Substitute for s1*0

[David Kastrup]

    "Now let's consider this calmly-" began Atticus, but Mr. Gilmer
    interrupted with an objection: he was not irrelevant or immaterial,
    but Atticus was browbeating the witness.

    Judge Taylor laughed outright. "Oh sit down, Horace, he's doing
    nothing of the sort. If anything, the witness's browbeating
    Atticus."

    "To Kill a Mockingbird", Harper Lee

James <address@hidden> writes:

> On 7 May 2012 22:28, David Kastrup <address@hidden> wrote:
>> Pavel Roskin <address@hidden> writes:
>>
>>> On Sun, 06 May 2012 10:34:24 +0200
>>> David Kastrup <address@hidden> wrote:
>>>
>>>> Quick: tell me what you would expect without too much thinking
>>>> (imagine you are a naive user) from the following:
>>>>
>>>> \new Staff <<
>>>>   \relative c'' { c4 d e f s1*0-\markup Oops c d e f g1 } \\
>>>
>>> A spacer 1 unit wide and 0 units high.
>>>
>>>>   \relative c' { c4 d e f <>-\markup Wow c d e f g1 }
>>>
>>> A rhombus.
>>>
>>> I'm fine with whatever works for now, but please keep in mind that
>>> Lilypond it written not just for programmers.
>>
>> I have not yet seen a proposal that would be more suitable for
>> non-programmers.  The counterproposal from the "don't let programmers
>> take over" is not to let users know about the ready availability of
>> this construct.  I consider that inappropriate.
>
> @David
>
> It is and I don't think anyone has said that; you might have inferred
> that - and perhaps that is the strawman that was being bandied about.

I don't see that this is a strawman.  The topic was to document the
existing behavior of <> (I am writing it without a space currently
without implying that this should be the way it should appear: for
better or worse, it gives it a bit more of identity) and, because of its
more straightforward and simple semantics, to use it in place of the
currently used s1*0 which has the principal drawback of changing the
current duration in the parser to something with potentially very
surprising side effects if you forget changing it back.

The alternative of documenting and promoting the use of <> over s1*0 is
not documenting and promoting its use over s1*0.

> However you obviously have taken this much more personally than you
> should have. I am sorry for that. That was not my intention.

If you state that you'll take your coat and leave and Graham states that
I am belittling him, taking his enjoyment of LilyPond to a new low and
making him glad to go on vacation and not hear of it for a while and
refusing to even look at further postings from me, would it not be
rather strange and/or impolite _not_ to take this personally if this is
the result of my person bringing forward a proposal and defending it in
an apparently completely inappropriate manner that has caused it?

I can't replace either of you.  I am already doing all I can.  People
are banking their trust and money on me to boost LilyPond development,
not sabotage it.  And the boost may well be temporary and run out of
steam soon enough when the monetary support dries up, while the sabotage
will persist.

> @Others
>
> It isn't about that s1*0 isn't ugly (it is), but <> is also ugly - to
> a casual user - someone like me doesn't look at that and think 'ooo I
> can see the internal workings of how that would make sense' like M.
> Sceaux et al. All I (and so most other users will see) is some other
> cryptic syntax.

Well, par for the course.  A reason not to go through would be if the
change would be terribly to the worse, and that, as it appears, is
Graham's contention.

> The justification has so far been this
>
> 1. Some programmers like it because it does something inside the code
> that I have no idea about and therefore makes some other functions
> easy to do and its a wonderful idea. It doesn't appear to me to mean
> that suddenly lots of our \markup bugs or \markup limitations will be
> fixed (please correct me if I am wrong).
>
> 2. If we re-document this ugly-and-cryptic syntax with another
> ugly-cryptic symbol things are better and a big light bulb will go on
> in my (casual user) head as I see how suddenly my LilyPond coding is
> now going go be so much easier.

Nope.  The difference is that <> is easier to explain and comprehend.
s1*0 is composed of several pieces and concepts: a spacer rest, and a
duration with a factor, and the factor having a special value that is
not obviously legal, nor does it have an obvious meaning.  In addition,
the multiplied duration will spill over to the next element taking a
duration, unless that element gets an explicit duration.

Have you read and understood all of the above paragraph? Because it
would be a good idea if you have when you are to continue using s1*0.
It will make it easier for you to figure out what the problem is if you
get into a problem with it.

In contrast to that, <> is in the mathematical sense trivial or
elementary: it is a chord in the sense of the language (namely it starts
with < and ends with >), but a chord containing no components that would
have an effect or side effect.  Which is the reason why it does not even
have the side effect of advancing the current time, and that is exactly
what we want from it.

> It feels like it is being forced by developers for no other reason
> than it suits those developers only. That is what galls.

Who is forcing whom here?  The proposal has been nipped in the bud by
head contributors declaring their intention to quit rather than
accepting it, before the proposal even had a chance to enter into the
regular course of becoming an issue in the tracker.

I have explained the technical reasons why

a) alternatives with the same semantics are not possible with the
   current parser.  Even if the parser is changed, it means that
   snippets intended for earlier than 2.15.40 will not be able to make
   use of those alternatives.
b) calling the input something else by letting it look the same
   internally will mean that \displayLilyMusic will show something
   significantly different from the input.

The last point is not necessarily a killer: if you do
\displayLilyMusic { c\cr }, the output will be { c\< } and people are
able to survive.  But that's switching between two representations more
or less equally related to CrescendoEvent (the actual thing getting into
LilyPond's bowels), whereas < > is elementary, and something like \null
would not be.

> This is exactly what I went through with the vertical spacing changes
> (I've already mentioned this) because a small group of people
> understood what the hell a non-staff-staff-affinity is (for example)
> and because us non developers - I'm trying very hard not to use words
> like 'lesser' or 'pleb' - cannot say 'hang on a minute I don't
> understand this, it makes no sense, what does this mean in English?

Again, no, it is exactly _not_ like that.  non-staff-staff-affinity was
a question of changing an existing design and replacing it.  <> is about
documenting and recommending a natural use of an existing feature in its
most elementary form.

Now for the non developers, "What does this mean in English?" is a
perfectly valid question.  The place to answer this question is in the
documentation, and the idea I brought forward is documenting it.  In the
course of preparing such a documentation, it would be put up on
Rietveld, and made the topic of an issue and discussion.

And Graham and you have made _very_ clear that you will not tolerate
this course.  You refuse the stage of letting an explanation being
written up and its merits discussed.  To the degree where you will
rather leave the project than let this happen.

> and then get bashed down just because we (lesser mortals) cannot then
> come up with an alternative solution.

Neither can the programmers, given the current constraints of the
parser.  You may believe that they tell you this just to spite you, and
it may be galling to have to trust them on that.  But I am not
responsible for what is galling you.

> That's a silly stance to take and it annoyed me then and it's annoying
> me now. Everyone got caught up with how clever it all was without
> thinking, how someone who didn't even know the different between a
> staff, a system and a line of music would understand those silly
> function names.
>
> I used to think things like GOP and GLISS was excessive bureaucracy,
> but after the vertical spacing changes and now this, I can see why
> they do work and I don't envy Graham stepping up to do that. It gives
> more of us a bit of voice.

This is not what has happened here.  In this case, a proposal was
shouted down before it could even enter the channels.  True, lynch
justice does not require "bureaucracy" and gives the "little people" "a
bit of voice".  I don't want to have it take over the style of work on
LilyPond, nevertheless.

> Off the top of my head with no thought:
>
> a\sharp b\flat c\beginSlur\beginCresc d e f\endSlur\forte
>
> @sharp{a} @flat{b} @address@hidden d e address@hidden@forte

In short, you are burning my proposal of _documentation_ in effigy for
being annoyed at decisions made long ago.  <> became a construct useful
for this purpose in 2003.  Incidentally, the same month that s1*0 first
appeared in the documentation.

You can start by writting
\simultaneous { ... } instead of << ... >>, and by writing
\sequential { ... } instead of { ... }.  Again, those more
self-explanatory variants of those commands have been readily available
for a long time now.  It may be a historical accident that this is not
the case for \chord { ... } (don't try, it does not exist), or you could
have written \chord { } instead of <>.  But the design of LilyPond's
syntax has a long history, and blaming me for it is not fair.

> and (before) anyone starts about 'well how would you do ....' or start
> to explain how you cannot '...parse the lexer up to an alist in the
> top-level lambda function blah..' misses the point that that it is
> *very easy* to come up with a syntax for non-programmers.

Well, I did not come up with the syntax.  Han-Wen did, in 2003.  He
asked about opinions then, and basically got a thumbs-up.

> How you program a syntax like that is, I accept a very different beast
> and would it really stand the test of time? who knows. Tex hasn't done
> too bad has it? I barely know it but can easily understand the syntax
> of a non-compiled file.

No, you can't.  Try telling the output of
<URL:www.tug.org/TUGboat/tb19-4/tb61carl.pdf>.  You are presumably
talking about LaTeX, and well-structured LaTeX at that.  TeX can change
its syntax under user control in midflight.  I have a rather solid
reputation in the TeX world (I made my money with it before moving to
LilyPond), and trust me, in the department of syntax and easiness of
understanding, there is nothing worse.

As a programming system, it is a blind and a lame subsystem tied back to
back and with different brains.  The lame subsystem, TeX's "mouth",
can't execute assignments or make other permanent changes, but it can
can evaluate conditionals based on the values of variables it can't
change.  The blind subsystem, TeX's "stomach" can actually make
assignments to variables and cause other effects, but it does not have
conditionals for making any decisions based on their values.  Both run
at different times and with different semantics.

If you think I probably don't know TeX well enough to know what I am
talking about, check
<URL:http://tug.org/pracjourn/2008-1/news/knuth.html>.

> The jokes about Haskel and Perl might be funny to programmers but
> there is more than an uncomfortable grain of truth in the sarcasm.

"jokes"?  I don't think that Graham was in a laughing mood when he
lambasted my proposal.

> I'm not of course advocating redesigning the syntax, but what I am
> saying is that if you actually give proper justification and
> *explanation* why another 'cryptic' syntax better then there is no
> problem and you can bring people along with you,

Are you being serious?  I listed a number of cases where the use of s1*0
will blow up.  I demonstrated how existing manual examples will fail
when combined with \addlyrics.

When Nicolas commented that this should settle the matter, you responded
by saying you'll fetch your coat and leave.  And Graham stormed out
because of refusing to be belittled.

What is "proper justification" in your book?  Pointing out where the
current examples will fall down and lead to problems when reused in user
code apparently isn't: it is instead an insolence intended to make "the
pleb" feel bad.

> even if they still disagree:
>
> Case in point: The new G Clef redesign last year? I disliked it (still
> do), but understood the arguments, we had lots of examples, pngs,
> comparative screen shots and I even had personal emails from some of
> the devs explaining why it was better and instruction on how to revert
> and build my own version if I wanted to use the old clef - I still
> disagreed that it looks better but I appreciated the gesture. So I am
> more than used to being in the minority.
>
> Here there has been no discussion at all. It's been 'stomp stomp
> stomp', right now lets get down and put it in the code.

No, it has been 'stomp stomp stomp', right now lets put the foot down
and avoid anybody being allowed to even think of _starting_ proper
procedures, an issue, a proposed patch, a regular discussion.

The proposal had to be _rooted_ _out_ before it could even be treated
fairly, since a fair treatment would most likely have resulted in its
ultimate acceptance.

There _has_ been a preliminary "discussion" (if you count one side
putting their hands on their eyes and ears and shouting "lalala, I can't
hear you" a discussion), and it resulted in a proper and fair discussion
on the merits being canceled.

I have already expressed my intent and willingness to let the proposal
die in order not to harm LilyPond development.

I don't presume to understand humans: I have been diagnosed with
personality disorders also connected with a lack of empathy.

But do you really believe you paint a fair picture if, after thrashing
and burning my proposal disregarding any factual argument and explicit
example I made, you claim _your_ side has been "stomped over" without
the benefit of a proper discussion?

This is not a rhetorical question.  I don't understand humans and am, in
some manner of the word, a sociopath.  But I at least want to understand
your characterization of the situation.  For whatever it is worth.

> Now David thinks he is the focus of ire and has lost necessary sleep
> over it. That is unfortunate (and wrong).

I lose sleep easily, anyway.  Why, last night alone the mare buzzer went
off twice, but no foal yet.  And no, that is not a metaphor for
anything.

But I consider it entirely likely that I'll be losing sleep for longer
over this issue than the mare will take to deliver.

-- 
David Kastrup