Re: Substitute for s1*0

[David Kastrup]

Graham Percival <address@hidden> writes:

> On Mon, May 07, 2012 at 11:00:39AM +0200, David Kastrup wrote:
>> James <address@hidden> writes:
>> 
>> > Evidence? 'skip' is exactly what it says on the tin.
>> 
>> But we are not talking about \skip (which actually would have the
>> advantage of _not_ tampering with the current duration in the parser,
>> and the disadvantage that it does not take post-events and thus is
>> totally pointless for this task) but s.  s says nothing on the tin, you
>> need to look it up in the manual on its own.
>
> wait, \skip and s aren't the same thing??

Are you reading what you are replying to?  James stated "'skip' is
exactly what it says on the tin".  But this is not about \skip, but s.
"s" says nothing "on the tin".  It is a single letter.

Besides, \skip and s are not the same thing.  \skip creates a SkipMusic
event

    (SkipMusic
     . ((description . "Filler that takes up duration, does not
print anything, and also does not create staves or voices implicitly.

Syntax: @code{\\skip} @var{duration}")
        (length-callback . ,ly:music-duration-length)
        (iterator-ctor . ,ly:simple-music-iterator::constructor)
        (types . (general-music event rhythmic-event skip-event))
        ))

which does not, when encountered on its own, cause a Bottom context to
be created and which does not take or replay articulations.  You can use
it, for example, to let a staff start with a delay.  s creates a
SkipEvent event which actually creates staves or voices implicitly and
uses the rhythmic event iterator for replaying articulation events:

    (SkipEvent
     . ((description . "Filler that takes up duration, but does not
print anything.

Syntax: @code{s4} for a skip equivalent to a quarter rest.")
        (iterator-ctor . ,ly:rhythmic-music-iterator::constructor)
        (types . (general-music event rhythmic-event skip-event))
        ))


> Leaving that question aside, we're talking about the preferred
> method of having something which does not tamper with the current
> duration but does take post-events.
>
> A number of people think that <> is the ideal tool for a
> non-duration post-event.

> James and I disagree; we think that a different tool (such as a new
> \null or \nullevent) would be easier to read.

What would the internal representation be reasonably?  An EventChord
containing only postevents.  Which is exactly what <> followed by post
events creates.  Now you want to either

a) create an additional new Event type which does exactly the same
b) have \displayLilyMusic <> for some inconceivable reason print \null

I don't get it.  Why break something that is working just fine, just
because it works better than s1*0?

>> > I absolutely take Graham's point that having a not uncommon sytax
>> > expression like '<< a4.(\->\<[^<>\markup {hello} \\ ...'  is ugly
>> 
>> Reality check.  <> is not new.  And it is not what makes the above look
>> bad.
>
> Seriously?  wow, we have radically different standards of
> readability.

You think that '<< a4.(\->\<[^\null\markup {hello} \\ ...' is perfectly
readable and pretty (never mind that it is syntactically invalid line
noise) while '<< a4.(\->\<[^<>\markup {hello} \\ ...' is ugly?

If this is supposed to be an argument, it certainly has a lot of
potential for being made more convincing.

>> Uh, <> (or < >) is precisely that: a chord.  Which is the reason that
>> it works.  Are you arguing that we should abolish chord syntax?
>
> No, we're not suggesting that we abolish chord syntax.  But we
> *are* suggesting that a different method of indicating a
> non-duration post-event would be preferrable, and if we have such
> a method, we shouldn't encourage the use of <> for that task.

So what new internal event do you propose introducing for the sole
purpose of doing the same as <> while looking differently?

> Please stop the straw-men.  Nobody thinks that s1*0 is the best
> method of indicating a non-duration post-event.

So we can agree that <> (or < >) is the best _existing_ method for
providing an anchor for post-events.  It translates into an EventChord
containing the post-events.  Exactly what is needed.  This produces the
best currently valid _internal_ representation for what we want.  And it
does not mess with the parser duration when you input the _external_
representation.

>> Are you really holding a grudge because of the one-time comment from
>> Janek
>
> Please stop the ad-hominen attacks.  James and I are not holding
> any grudges.

    Apart from the fact I disagree that they are not unfamiliar from and
    that I recall I ended up in a debate trying to get a relatively
    small change in to \partial documentation where it was implied that
    everyone knows about multipliers of duration and that \partial 8*3
    was much clearer an example than \partial 4.

Here James complains that Janek objected to James removing the use of
\partial 8*3 in a change of documentation, using a description of
Janek's argument that is totally blown out of proportion.  The change
_did_ go through and was committed by James, so it is not particularly
likely that James bought the argument.  Yet he brings it up in this
discussion and states that we should, in the purpose of this discussion,
come to a different conclusion than the consensus arrived in the earlier
discussion and put into place by him, because of the reasoning
triggering his change in the first place.  I can't find that
particularly compelling.  Feel free to find a description fitting the
facts that you don't consider ad hominem.

>> > Also isn't this a really a GLISS topic?
>> 
>> Reality check.  <> has already worked for eternities.  It would be
>> GLISS to _disallow_ it.  I can see no reason for that.
>
> We're not proposing that we _disallow_ it.  We're proposing that
> there might be a better way,

Do you want to invent a new internal event type for containing
post-events, yes or no?  If yes, why?  If no, do you want
\displayLilyMusic <> to display something significantly different from
<>?

> and if we can agree on a better way, it would be good not to encourage
> the <> method.

Why?

>> Should we also disallow using { } and << >> instead of \sequential
>> and \simultaneous (which have been available since LilyPond 1.1 but
>> do not see much use)?
>
> Now you're just being ridiculous.

Which is the point.  Feel free to prove a qualitative difference to the
ridiculosity of discouraging <>.

-- 
David Kastrup