Carl Sorensen wrote Sunday, December 06, 2009 9:59 PM
On 12/6/09 9:50 AM, "Trevor Daniels" <t.dani...@treda.co.uk>
wrote:
I changed it because "string" is a keyword in Scheme.
It is even used as such in the same few lines of code.
Although "string" can be used as a variable name I don't
think it should be - it seems bad practice to overload
keywords in this way.
I don't know of string as a keyword in Scheme. It's not listed in
the Guile
reference manual index.
string? is a predicate.
substring is a procedure.
There are a bunch of string-*, string->*, and *->string
procedures.
But string by itself seems to not be part of the Scheme language.
Have I
missed something? (I easily could have.)
I think you have. string is a built-in procedure which
forms a string from one or more characters. Try
guile> (string #\a #\b)
It outputs "ab".
It's actually used in the code in question, which was
what prompted me to change it. "string" was being used
with two meanings in the same procedure.
I fully agree with your point in general, but we need
to think of a variable name other than "string" for the
string on an instrument. I tried, and failed :(, hence
str.
Dana suggests "course", which I guess speaks well to lute players.
But not
to guitar players.
string seems the best to me.
I prefer str to course and string, but if no other ideas
are forthcoming I'll use string_number.
http://codereview.appspot.com/164063/diff/2001/3008#newcode399
scm/translation-functions.scm:399: (make-vcenter-markup
If length of 'fretLetterExceptions is greater than zero, I think
we
ought to throw a warning if fret is higher than the length of
'fretLetterExceptions so that the user will have an idea of why
things
didn't work the way they wanted it to.
Hhm, I'm not so sure about this. I had envisaged changing
only the c to r, leaving all letters beyond c to default.
As this would be the norm I don't think a warning is desirable,
but I'm willing to be convinced otherwise. Actually, for most
ancient instruments only i or j, not both, is used, so maybe the
length of fretLetterExceptions would be somewhat greater than
3 normally, making a warning more appropriate. Although if i
not j is a general rule, maybe that should be built in to the
default, then we'd be back to needing just the change from c to
r.
Maybe a question on -user is needed on this point.
I had envisioned that a full set of fretLetters would be given (in
fact, I'm
not really a big fan of the term fretLetterExceptions). But now
that I see
your design intent, I'm not sure what the best thing to do is.
Perhaps we just ought to define lists called fretLabels (instead
of
fretLetters). And we could then define lists of any kind of
glyphs to be
used. There could be specific lists for each different style of
tablature,
that would be very easy to switch to. The fretLabels list
wouldn't need to
be characters; they could be markups or stencils, so users could
define
whatever is needed or desired.
I quite like the term fretLabels, with the list being of
anything that evaluated to a Scheme string. I'll have a
play with this idea. I think I shall also drop the idea
of having the default fret labels being the alphabet and
require all labels to be provided, issuing a warning as
you suggested if insufficient are available to indicate
the required pitch. Label sets can then be provided in
the context definitions or by the user.
Trevor
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel