Re: Variable names of the form section.N.S core dump the parser
Aaron Hill writes:
> 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?
Why?
> 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?
Why?
>
>
> \version "future"
>
> foo = { c2 } % Works, providing \foo does not exist.
> bar = { c4 4 } % Warns, since \bar does exist.
Why would that warrant a warning? What is the problem you try warning
about?
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Variable names of the form section.N.S core dump the parser
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.
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Variable names of the form section.N.S core dump the parser
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?
\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.
-- Aaron Hill
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Variable names of the form section.N.S core dump the parser
Le 24/05/2022 à 16:40, Jean Abou Samra a écrit : this is trying to set a key inside a music function I have to correct myself. \section is defined as a music identifier, not a music function. The result is the same though. ___ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Variable names of the form section.N.S core dump the parser
Le 24/05/2022 à 16:37, Trevor Bača a écrit :
Hi,
The dot-chained variable names that became available in recent versions of
LilyPond are great, particularly because they allow numerals:
%%% EXAMPLE 1 %%%
\version "2.23.8"
movement.1.notes = { g'4 }
\new Staff { \movement.1.notes }
%%% END %%%
But LilyPond's parser errors when a variable is named like this:
%%% EXAMPLE 2 %%%
\version "2.23.8"
section.1.notes = { g'4 }
\new Staff { \section.1.notes }
%%% END %%%
GNU LilyPond 2.23.8 (running Guile 2.2)
Processing `test.ly'
Parsing...ERROR: In procedure ly:parse-file:
In procedure caar: Wrong type (expecting pair): #))((display-methods
#) (name . SectionEvent) (types section-event
event)) >
The error appears to be very narrow.
Because this works ...
%%% EXAMPLE 3 %%%
\version "2.23.8"
section = { a'4 }
\new Staff { \section }
%%% END %%%
... and so does this ...
%%% EXAMPLE 4 %%%
\version "2.23.8"
section.1 = { b'4 }
\new Staff { \section.1 }
%%% END %%%
... which appears to mean that the error occurs only when a variable is
named in the form ...
section.N.S
... with numeric N and string S.
The workaround is to use a different variable name, and so the issue is
probably low priority.
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.
(Note that the error is not a core dump, just a regular Scheme
error. If you get a core dump, that means LilyPond crashed
more seriously, usually without much indication of what
happened, and it is normally a bug.)
Jean
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
Variable names of the form section.N.S core dump the parser
Hi,
The dot-chained variable names that became available in recent versions of
LilyPond are great, particularly because they allow numerals:
%%% EXAMPLE 1 %%%
\version "2.23.8"
movement.1.notes = { g'4 }
\new Staff { \movement.1.notes }
%%% END %%%
But LilyPond's parser errors when a variable is named like this:
%%% EXAMPLE 2 %%%
\version "2.23.8"
section.1.notes = { g'4 }
\new Staff { \section.1.notes }
%%% END %%%
GNU LilyPond 2.23.8 (running Guile 2.2)
Processing `test.ly'
Parsing...ERROR: In procedure ly:parse-file:
In procedure caar: Wrong type (expecting pair): #))((display-methods
#) (name . SectionEvent) (types section-event
event)) >
The error appears to be very narrow.
Because this works ...
%%% EXAMPLE 3 %%%
\version "2.23.8"
section = { a'4 }
\new Staff { \section }
%%% END %%%
... and so does this ...
%%% EXAMPLE 4 %%%
\version "2.23.8"
section.1 = { b'4 }
\new Staff { \section.1 }
%%% END %%%
... which appears to mean that the error occurs only when a variable is
named in the form ...
section.N.S
... with numeric N and string S.
The workaround is to use a different variable name, and so the issue is
probably low priority.
Trevor.
--
Trevor Bača
www.trevorbaca.com
soundcloud.com/trevorbaca
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
