Re: Issue 2702 in lilypond: Patch: Unify the lexer's idea of words and commands across all modes.

[David Kastrup]

Graham Percival <address@hidden> writes:

> On Mon, Jul 30, 2012 at 03:48:48PM +0200, David Kastrup wrote:
>> Graham Percival <address@hidden> writes:
>> 
>> > Does this affect
>> >
>> > {
>> >   \tempo 4. = 120 
>> >   c2 d
>> >   %\tempo "Adagio" 4. = 43.5
>> >   \tempo "Adagio" 4. = 43
>> >   e4. d8 c2
>> > }
>> >
>> > ?
>> 
>> No.
>
> (aside: do we want to disallow all decimals in metronome markings?
> 43.5 doesn't work.  I'm perfectly fine forbidding them, but some
> contemporary composers might want to give exact values)

#43.5 should work.  I already stated that I would prefer having tokens
not mode dependent, and thus prohibit 4. from really meaning 4.0.
However, we already juggle between 4 (the duration) and 4 (the integer),
so that is basically just one more aggravation, and one could similarly
interpret 4. according to context.

In any way, I consider it a bit tasteless that we have to revert to
Scheme for disambiguating stuff that should be part of the regular
syntax.

>> \tempo syntax is insane.  This is one thing that will eventually have to
>> go.
>
> ok, but are we stepping in the right direction here?  I mean, if
>   \relative c' {
>     \tempo "Allegro" 4. = 60
>   }
> works but
>   \midi {
>     \tempo "Allegro" 4. = 60
>   }
> fails, I wouldn't blame anybody for being surprised.

We are not "stepping in the right direction".  This is where we already
are.

>> Whitespace is whitespace in LilyPond without further significance,
>> and we are _not_ going to change this against my very firm
>> disapproval.  It would be the death knell for having LilyPond
>> reasonably useful for computer-generated output, like exports from
>> other music software.
>
> I'm not seriously suggesting it, but I'd argue that significant
> whitespace should have an insignificant effect on
> computer-generated output.  I mean, sure it might take an extra
> hour of debugging, but once you've got your exporter adding the
> right number of spaces, it should work, right?

Do you even have an idea what "adding the right number of spaces"
entails?  You can no longer translate data to output in a linear
fashion, since you always have to track your current indentation level.
You can't, say, call a function for outputting an expression, because
you need to know whether you are at the start of line after or before
indentation, or somewhere else in line.

You _can't_ concatenate code and/or splice it in, because you need to
reformat it using the current indentation.

Have you ever written a program generating non-trivial Python?  Or a
pretty-printer?  Much more complex than writing just a printer, and with
an indentation-sensitive language, _everything_ needs to be
pretty-printed, in context.

-- 
David Kastrup