Re: [PATCH] Add scheme engraver for StaffTab notation

[Werner LEMBERG]

>>   #(for-each
>>     (lambda (elem)
>>       (let* ((sym (car elem))
>>              (chord (cdr elem)))
>>         (ly:parser-include-string
>>            parser
>>            (string-append "\\makeDefaultStringTuning " sym "-tuning"
>>                           " \\stringTuning <" chord ">"))))
>>
>>       '(("guitar" . "e, a, d b g e'")
>>         ("guitar-seven-string" . "b,, e, a, d b g e'")
>>         ("guitar-drop-d" . "d, a, d g b e'")
>>         ("guitar-drop-c-tuning" . "c, g, c f a d'")
>>          ...
>>         )
>>    )
> 
> Disagree.  The current solution has a constant visual pattern (just
> that it does not use whitespace for that).  It's not significantly
> less readable on a pure visual basis (one might want to block-align
> the tuning names).  However, your version is utterly
> incomprehensible on the basis of understanding what it does while
> the original version has each line stand for itself, with a readily
> readable _meaning_ of the line.

It's not clear to me how an alist of tuning names and the associated
string tunings is `utterly incomprehensible'...  Oh well.  It seems we
have to agree to disagree.  Your interpretation of readability greatly
differs from what I perceive as well readable.

> All that ly:parser-include-string is actually on a level of code
> ugliness even below using primitive-eval because it pieces together
> stuff that is not even at a syntactical level.

Yes, but exactly this is the power of `ly:parser-include-string'!  It
is a nice utility to use Scheme's iteration stuff (i.e., `for-each'
and friends) while not too deeply diving into Scheme.  Admittedly, we
don't have to use such things in the lilypond init files; I accept
your veto and won't further push into this direction.


    Werner