Urs Liska <li...@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 <d...@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