Re: Variable names of the form section.N.S core dump the parser

[Jean Abou Samra]

Le 24/05/2022 à 18:06, Aaron Hill a écrit :
> On 2022-05-24 7:40 am, Jean Abou Samra wrote:
> > Because there is now a command called \section, so this
> > is trying to set a key inside a music function, which is
> > not an alist ... This is unfortunate but unavoidable.
>
> Would it be practical for LilyPond to detect and warn when a built-in 
> is being redefined?
>
> Granted, one thing I really like about LilyPond is that one can easily 
> redefine things as needed.  But would it be burdensome to require a 
> little bit of extra syntax that makes clear the user's intention to 
> redefine something that already exists?



I don't see a very obvious advantage. You will get no problem if
redefining a built-in like "bar = ..."; instances of \bar
or #(bar ...) occurring in LilyPond's internal code will
not be affected (since a change in the 2.23 series) and
it will work just fine. If the user writes \bar to mean
_both_ a bar line and a reference to their "bar" variable,
I'd expect them to notice something is off. Thus it makes
most sense with nested assignments, where you might not be
aware that the variable being modified as an alist was
already defined before. I don't see a lot of usage of
nested assignments out there, so I'm not sure the warning
would guard against common enough a situation to warrant
being special-cased, although I could be convinced otherwise.

On the other hand, it might be reasonable to error out or
at least warn on the assignment "alist.key.keyTwo.keyThree = ..."
if `alist` is not an alist in the first place.

Jean






> %%%%
> \version "future"
>
> foo = { c2 }     % Works, providing \foo does not exist.
> bar = { c4 4 }   % Warns, since \bar does exist.
>                  % (Could be made to fail in a "pedantic" mode.)
>
> \redefine bar = { c8 4. }  % Explicitly redefine, no warning needed.
> bar := { c8 4. }           % Same, with a possible syntactic shorthand.
> %%%%