lilypond-user
[Top][All Lists]
Advanced

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

Re: Two optional arguments


From: David Kastrup
Subject: Re: Two optional arguments
Date: Wed, 15 Jul 2020 13:08:30 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Urs Liska <lists@openlilylib.org> writes:

> Am Dienstag, den 14.07.2020, 22:57 +0200 schrieb David Kastrup:
>> 
>> That is an incorrect description.  This only happens when you comment
>> out only the first value.  When you comment out both optional values,
>> the first value that is seen is "bar" which is a valid value for a
>> symbol.  If you instead write #"bar" instead, this can only become a
>> string argument and not a symbol and consequently both optional
>> arguments are replaced by their default.
>
> This is something I didn't know and which I find surprising. I would
> really expect using quotation marks indicates something is a string.

Quotation marks form words (and symbols from there as needed)
independent of other syntactic considerations.

Something like

"\\(" = #(make-span-event 'PhrasingSlurEvent START)

in ly/declarations-init.ly defines a symbol consisting of the letters \
and ( .  As opposed to symbols that happen to meet LilyPond word syntax,
you cannot sensible do so without quote marks.  You can invoke that
symbol as

\"\\("

if you want to.

> I find it practical that a value without quotes can be parsed as
> string or symbol if the parser knows the expectations, but explicitly
> adding the quotes would seem like an explicit statement.

It is.  It is a statement about lexical word boundaries.  Scheme and
LilyPond have different conventions here.  Using quote marks, you can
mostly punch through in case of need.

> But I assume much thought has gone into these considerations, so I
> won't question it.

Criticising but not questioning it has connotations of
passive-aggressiveness.

Not everything in LilyPond's syntax is quite the bee's knees.  I am
certainly the go-to culprit for trying to beat some kind of logic and
predictability into a preexisting framework while trying to minimise
collateral damage.  You'll find that the lexical entities STRING and
SYMBOL were completely indistinguishable to the parser up to

commit f9056caac3bda31437ed004d775fbae14ca61bf3
Author: David Kastrup <dak@gnu.org>
Date:   Fri Nov 2 17:56:23 2012 +0100

    Issue 5113/2: Parser: discriminate quoted and non-quoted strings
    
    Checking quoted strings for syntactic correctness seems spurious, as does
    splitting them into multiple symbols.  Now "x.y" is treated as a list
    of two symbols without the quotation marks, but as a single string or
    symbol when given quotation marks.
    
    This allows using quotation marks for creating arbitrary symbols, and
    consequently specifying key lists using quoted strings without the
    strings being split in other components or being rejected because
    of syntactical reasons.

in version 2.19.59 so your expectation was never viable in LilyPond's
history until comparatively recently (in version numbers and/or stable
releases), and changes here would likely break existing documents.

Moving LilyPond forward in abilities and overarching concepts while
minimising collateral damage is not easy.

I remember quite well when word syntax was changed to cover things like
Forbid_line_break_engraver (allowing to use the same lexer mode for
music and context modifications) and glyph-name-alist (allowing
\override et al to stop having to use #'glyph-name-alist for naming a
property) and Valentin complained that stuff like c-° stopped working
(since it changed from c with a text script to being an identifier).

But such collateral damage has been rather limited in extent,
fortunately.

-- 
David Kastrup



reply via email to

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