Am Mittwoch, den 15.07.2020, 13:08 +0200 schrieb David Kastrup:
> 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.
OK. Totally clear once you're aware of it.
>
> > 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.
Let me rephrase my sentence, in case this is a serious comment (I tend
to sometimes forget that sometimes you have to be really exact on this
list): "I withdraw any explicit or implicit criticism of LilyPond's
current parser behaviour with regard to optional arguments because I
assume much thought has gone into these considerations, which I don't
question."
Urs
