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
Re: variable names
Erik Sandberg writes: not a bug; won't fix. ok, removed from cvs. btw: is this documented? -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ bug-lilypond mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: variable names
On Tuesday 17 August 2004 20.57, Han-Wen Nienhuys wrote: [EMAIL PROTECTED] writes: Added this to cvs: %critical % \header {texidoc = Variable names can not be set to pitch names } \version 2.3.11 a = {c c c c} not a bug; won't fix. ok, removed from cvs. erik ___ bug-lilypond mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-lilypond