lilypond-devel
[Top][All Lists]
Advanced

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

Re: markup-command and markup-command-list signatures


From: David Kastrup
Subject: Re: markup-command and markup-command-list signatures
Date: Fri, 30 Apr 2010 11:47:34 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Nicolas Sceaux <address@hidden> writes:

> Le 29 avr. 2010 à 20:27, David Kastrup a écrit :
>
>> What type signatures would be actually permissable under the assumption
>> that they are supported by lexer and parser?
>> 
>> It is somewhat clear to me that we can't have markup-list followed by
>> markup in the arguments.  Anything else?
>
> I'd say, a markup-list command signature should follow the pattern:
>
>    scheme* markup* markup-list*
>
> that is, any number of scheme arguments, then any number of single markup
> arguments, then any number of markup-list arguments, even though I don't
> know if having several markup list arguments is useful or not (and if it's
> doable).

I've read the syntax back and forth now and am of the opinion that
{ scheme | markup | markup_list }
should work fine for both markup and markup-list commands: namely no
restrictions regarding order and content.  A markup-list is always
delimited and recognizable in the syntax.  Some forms may be more
efficient to execute, but that's an implementation detail.

I am not sure yet that the Scheme macro markup builder will be equally
happy with this generality but see no immediate reason why it shouldn't.

There does not seem to be a compelling syntactical reason that a
composed sequence like
\raise #0.5 \bold \italic {   }
is restricted to commands with signature
{ scheme } markup
rather than
{ anything } markup

but it currently appears to be an optimization consideration.  So I'll
likely keep that around.  Strictly speaking, one can always convert
(function markup scheme scheme)
into
(function scheme scheme) or even (function)
using closures.  So one would not need to change the original evaluator,
and still get the same efficiency for the old input, while supporting
more forms.

But for now, I'll just keep composition to the existing
{ scheme } markup
signature.

-- 
David Kastrup





reply via email to

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