Re: banter-style from chord-names-jazz.ly broken, 'case'-problem
Thomas Morley writes: > 2015-04-08 12:04 GMT+02:00 David Kastrup : [...] >>> (display (eqv? -1 DOUBLE-FLAT)) >>> -> #t >>> >>> (display >>> (case -1 >>>((DOUBLE-FLAT) "--") >>>((FLAT) "-") >>>((NATURAL) "") >>>((SHARP) "+") >>>((DOUBLE-SHARP) "++"))) >>> -> # >> That one's easy. As may be expected from the case-tag being in the form >> of an unquoted list, there is no evaluation involved. >> >> So the case statement is comparing to the symbols DOUBLE-FLAT, FLAT, etc >> as opposed to the values stored in the variables associated with the >> symbols. > > The guile manual says: > > " > — syntax: case key clause1 clause2 ... > > key may be any expression, the clauses must have the form > > ((datum1 ...) expr1 expr2 ...) > > and the last clause may have the form > > (else expr1 expr2 ...) > > All datums must be distinct. [...] > " > > "distinct" is not really meaningful ... It also says: All DATUMs must be distinct. First, KEY is evaluated. The the result of this evaluation is compared against all DATUMs using `eqv?'. When this comparison succeeds, the expression(s) following the DATUM are evaluated from left to right, returning the value of the last expression as the result of the `case' expression. So the description explicitly points out whenever something is evaluated. It does not explicitly point out that the DATUMs are *not* evaluated. Given the frequency with which people are surprised at `case' behavior (one frequent surprise is that it doesn't work for strings, for example), it might be worth pointing out explicitly what kind of things *won't* work with case. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: banter-style from chord-names-jazz.ly broken, 'case'-problem
2015-04-08 12:04 GMT+02:00 David Kastrup : > Thomas Morley writes: > >> 2015-04-08 11:45 GMT+02:00 Thomas Morley : >> >>> I started to rewrite chord-namings and stumbled over a problem in >>> chord-generic-names.ly >>> >>> /Documentation/included/chord-names-jazz.ly with uncommented >>> Banter-style is broken. >>> At least since 2.12.3 >>> >>> The problem is in 'step->markup-plusminus' >>> >>> Here you see the old code commented and a possible patch inserted: >>> >>> (define (step->markup-plusminus pitch) >>> (make-line-markup >>> (list >>> (make-simple-markup (number->string (step-nr pitch))) >>> (make-simple-markup >>>;(case (step-alteration pitch) >>>; ((DOUBLE-FLAT) "--") >>>; ((FLAT) "-") >>>; ((NATURAL) "") >>>; ((SHARP) "+") >>>; ((DOUBLE-SHARP) "++")) >>>(case (step-alteration pitch) >>> ((-1) "--") >>> ((-1/2) "-") >>> ((0) "") >>> ((1/2) "+") >>> ((1) "++")) >>> >>> >>> case uses eqv? to compare. (guile-manual) >>> (step-alteration pitch) returns: -1 or -1/2 or 0 or 1/2 or 1 >>> (display (eqv? -1/2 FLAT), etc returns #t >> >> boiled down: >> >> (display DOUBLE-FLAT) >> -> -1 >> >> (display (eqv? -1 DOUBLE-FLAT)) >> -> #t >> >> (display >> (case -1 >>((DOUBLE-FLAT) "--") >>((FLAT) "-") >>((NATURAL) "") >>((SHARP) "+") >>((DOUBLE-SHARP) "++"))) >> -> # >> >> ?? >> >>> Thus I've no clue why the old code fails. >>> Any hint? > > That one's easy. As may be expected from the case-tag being in the form > of an unquoted list, there is no evaluation involved. > > So the case statement is comparing to the symbols DOUBLE-FLAT, FLAT, etc > as opposed to the values stored in the variables associated with the > symbols. The guile manual says: " — syntax: case key clause1 clause2 ... key may be any expression, the clauses must have the form ((datum1 ...) expr1 expr2 ...) and the last clause may have the form (else expr1 expr2 ...) All datums must be distinct. [...] " "distinct" is not really meaningful ... > It would probably make more sense to define an association list for this > lookup, or convert into a cond. > > -- > David Kastrup Thanks for the hint. Cheers, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: banter-style from chord-names-jazz.ly broken, 'case'-problem
Thomas Morley writes: > 2015-04-08 11:45 GMT+02:00 Thomas Morley : > >> I started to rewrite chord-namings and stumbled over a problem in >> chord-generic-names.ly >> >> /Documentation/included/chord-names-jazz.ly with uncommented >> Banter-style is broken. >> At least since 2.12.3 >> >> The problem is in 'step->markup-plusminus' >> >> Here you see the old code commented and a possible patch inserted: >> >> (define (step->markup-plusminus pitch) >> (make-line-markup >> (list >> (make-simple-markup (number->string (step-nr pitch))) >> (make-simple-markup >>;(case (step-alteration pitch) >>; ((DOUBLE-FLAT) "--") >>; ((FLAT) "-") >>; ((NATURAL) "") >>; ((SHARP) "+") >>; ((DOUBLE-SHARP) "++")) >>(case (step-alteration pitch) >> ((-1) "--") >> ((-1/2) "-") >> ((0) "") >> ((1/2) "+") >> ((1) "++")) >> >> >> case uses eqv? to compare. (guile-manual) >> (step-alteration pitch) returns: -1 or -1/2 or 0 or 1/2 or 1 >> (display (eqv? -1/2 FLAT), etc returns #t > > boiled down: > > (display DOUBLE-FLAT) > -> -1 > > (display (eqv? -1 DOUBLE-FLAT)) > -> #t > > (display > (case -1 >((DOUBLE-FLAT) "--") >((FLAT) "-") >((NATURAL) "") >((SHARP) "+") >((DOUBLE-SHARP) "++"))) > -> # > > ?? > >> Thus I've no clue why the old code fails. >> Any hint? That one's easy. As may be expected from the case-tag being in the form of an unquoted list, there is no evaluation involved. So the case statement is comparing to the symbols DOUBLE-FLAT, FLAT, etc as opposed to the values stored in the variables associated with the symbols. It would probably make more sense to define an association list for this lookup, or convert into a cond. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: banter-style from chord-names-jazz.ly broken, 'case'-problem
2015-04-08 11:45 GMT+02:00 Thomas Morley : > Hi. > > I started to rewrite chord-namings and stumbled over a problem in > chord-generic-names.ly > > /Documentation/included/chord-names-jazz.ly with uncommented > Banter-style is broken. > At least since 2.12.3 > > The problem is in 'step->markup-plusminus' > > Here you see the old code commented and a possible patch inserted: > > (define (step->markup-plusminus pitch) > (make-line-markup > (list > (make-simple-markup (number->string (step-nr pitch))) > (make-simple-markup >;(case (step-alteration pitch) >; ((DOUBLE-FLAT) "--") >; ((FLAT) "-") >; ((NATURAL) "") >; ((SHARP) "+") >; ((DOUBLE-SHARP) "++")) >(case (step-alteration pitch) > ((-1) "--") > ((-1/2) "-") > ((0) "") > ((1/2) "+") > ((1) "++")) > > > case uses eqv? to compare. (guile-manual) > (step-alteration pitch) returns: -1 or -1/2 or 0 or 1/2 or 1 > (display (eqv? -1/2 FLAT), etc returns #t boiled down: (display DOUBLE-FLAT) -> -1 (display (eqv? -1 DOUBLE-FLAT)) -> #t (display (case -1 ((DOUBLE-FLAT) "--") ((FLAT) "-") ((NATURAL) "") ((SHARP) "+") ((DOUBLE-SHARP) "++"))) -> # ?? > Thus I've no clue why the old code fails. > Any hint? > > Cheers, > Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
banter-style from chord-names-jazz.ly broken, 'case'-problem
Hi. I started to rewrite chord-namings and stumbled over a problem in chord-generic-names.ly /Documentation/included/chord-names-jazz.ly with uncommented Banter-style is broken. At least since 2.12.3 The problem is in 'step->markup-plusminus' Here you see the old code commented and a possible patch inserted: (define (step->markup-plusminus pitch) (make-line-markup (list (make-simple-markup (number->string (step-nr pitch))) (make-simple-markup ;(case (step-alteration pitch) ; ((DOUBLE-FLAT) "--") ; ((FLAT) "-") ; ((NATURAL) "") ; ((SHARP) "+") ; ((DOUBLE-SHARP) "++")) (case (step-alteration pitch) ((-1) "--") ((-1/2) "-") ((0) "") ((1/2) "+") ((1) "++")) case uses eqv? to compare. (guile-manual) (step-alteration pitch) returns: -1 or -1/2 or 0 or 1/2 or 1 (display (eqv? -1/2 FLAT), etc returns #t Thus I've no clue why the old code fails. Any hint? Cheers, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
