[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Syntax change proposal:

From: David Kastrup
Subject: Re: Syntax change proposal:
Date: Thu, 26 Jul 2012 00:39:11 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

Keith OHara <address@hidden> writes:

> David Kastrup <dak <at>> writes:
>> One problem I currently struggle with is supporting something like
>>  \tempo 4. = 200
> Your patch to re-allow \tempo in midi blocks will also need to restore 
> mention of the extra-space-trick "\tempo 4 . = 90" in the docs, and in 
> your convert-ly rule.
> That is, your patch as posted now converts my
>  \midi{\context{\Score tempoWholesPerMinute = #(ly:make-moment 105 8) }}
> to \midi { \tempo 4. = 35}  which gives an error.

Oh great.  I did not realize that.  Documentation/changes.tely happily
claims this works.

>> The flexibility of #{ ... #} depends on not having too many modes.  It
>> would be nice if #{ 4 #} could be used for a duration, and #{ 4.0 \cm #}
>> for a dimension.  
> That's a good point.  You can't use #{ 4.0 \cm #} anyway without context 
> telling LilyPond that \cm is the pre-defined unit, as opposed to a user 
> variable.

\cm _is_ a user variable.  You can write
\layout { m = 100\cm
          paper-width = 0.5\m

> The pre-defined \cm is acted only in limited contexts -- the same 
> contexts where we are allowed to type decimal numbers without a leading #. 
> We would like those contexts to be even more narrow, immediately after the 
> '=' operator.

I don't see why one would not want that for function arguments.  What's
good for assigning to variables is good for assigning to function

> I see that the parser is tangled, with 'scalar' used for several distinct
> things.  If you could untangle the parser so that 4.0\cm matches a distinct 
> pattern (not just bare_number in INITIAL lexer mode) and set a lexer mode 
> that accepts 4.0\cm when that pattern is valid, then we could type 
> \midi{\tempo 4. = 90}

\tempo can just switch lexing modes.  It would also be thinkable to let
music functions generally switch, but since they are generally parsed
using lookahead, there is no good point for switching back: if the
lookahead has already been scanned in the wrong mode, there is no
reinterpretation for it.

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]