Re: banter-style from chord-names-jazz.ly broken, 'case'-problem

[Thomas Morley]

2015-04-08 12:04 GMT+02:00 David Kastrup <address@hidden>:
> Thomas Morley <address@hidden> writes:
>
>> 2015-04-08 11:45 GMT+02:00 Thomas Morley <address@hidden>:
>>
>>> 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) "++")))
>> -> #<unspecified>
>>
>> ??
>>
>>> 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