Re: tab

[David Raleigh Arnold]

On Mon, 09 Sep 2002 13:33:41 Han-Wen Nienhuys wrote:
> 
> I think you and I have a different idea of `macro'.

You must admit that it's a fairly inclusive word.
I think I should have said `identifier'.

All I mean is:

novobracket = {\property Staff.VoltaBracket = \turnOff}

If I have more than two staves, I'll do that *every
time*.  I will make an identifier for anything that
has #' in it.  That isn't building a new language, it it? 
> 
> <rant>
> 
> The problem with TeX, m4, YODL and metafont is that they are syntax
> oriented and not function oriented. I'm too busy to formalise exactly
> what I mean, but maybe this example explains what I mean
> 
>       \def\foo{20}
>       \def\bar{20}
>       \def\bla{pt}
>       \hrule width\foo\bar\bla
> 
> TeX will do a string substitution, and instead of signaling an error
> (wrong number of arguments in \HRULE), it will gladly replace \foo\bar
> with 2020 and make a rule of 2020 points wide. The substitution
> process has no notion of the meaning of tokens. There is no type
> checking, scoping, there are no modules. In short, this will give you
> a programming interface (yes, TeX also has loops, and if-then-else)
> that is extremely sensitive to irrelevant naming and formatting
> formatting details.  It makes for hard to read and hard to debug code.

\stemLength{4.5} or \\stemLength{4.5} is not going to kill
you, really, as long as it's in the .ly file.

\lilycommand{stemLength}{foofooraw #'foo = ##1}
\lilycommand{haha}[2]{foofooraw #'foo = ##1 foofoofooraw #'foo = ##2}

I've got to admit it looks nasty, but most of us would
do it in a heartbeat.  The second is more trouble than
it's worth.

We just want to be able to pass a value to things already
identifiable.  Of course lily would choke on a stem length
two inches long.  So what?  You are assuming that we are
total gluttons for punishment.  'Taint so.

Of course using the editing approach, the .ly file contains
all the long stuff and that is all lilypond sees, so debugging
is actually easier because it's easier to find the offending
line.  That is the sly-ptfilter.sed approach.  The disadvantage
to the user is that he has to put the value passing stuff
in ptfilter.sed.
 
> Most people will argue that they would parametrised definitions only
> simple substitutions, and not get into these hairy programming
> issues. I remain very skeptical: the moment there are parameters,
> people will insist on having if-then.

If they need it, they will have it.  Why not try to see to it
that they don't need it instead of worrying about what they
are going to want next?  And anyone with any sense at all
is going to have any if-then *write* lilypond syntax as
a product.  That means having it in lilypond is
not an option.

> When there is if-then people
> will want loops "to save repetitive entry". When we have loops and
> if-then we have a turing complete language, but to make that usable,
> people will demand lists and arrays.  And so on, and all that time
> that I spend reinventing the wheels of programming language design can
> not be spent on improving the music formatter itself.

This is not going to happen.  I already pointed out to another
user, I thought that's who I was addressing anyway, how one
might make a tab2notation2tab program.  It would make no sense
to do that with lilypond because it involves the writing of an
.ly part.  It is insane to have files writing themselves.

It made no sense to have lilypond render chords either.  If
it weren't so simple it would be a debugging nightmare, because
you don't have the .ly file with the written out chords in it
when you use it do you?  A
separate program which took standard chord names, (which have
absolutely nothing to do with Harald Banter) and wrote guitar,
bass, midi, and lyrics parts (just pass the chord names through) for
inclusion in a .ly file would be a fun
toy, and one would not have to mess with Tex, LaTeX, C++, or
scheme to do it if he didn't want to, it could be
done with any language which could filter a textfile.

So IMHO you have already gone too far down the road of having
.ly files write themselves.

I don't set stem lengths because I *want* to, I do it because
I *must* to get acceptable output.  It will be a long time
before lilypond can handle 3 parts on one staff without having
to massage the stems by hand.  You force people to either have
a new identifier for each value or find other means, and other
means exist.
 
> The notion of a macro language throws away 20 odd-years of research
> that went into design of programming languages.  I think it is a
> tasteless idea, and I will not have it.  There will not be a
> macro-language in LilyPond as long as it has my name on it.  If you
> still want that, then you can fork LilyPond, or write a preprocessors
> by yourself.
> 
> The whole idea of making code easier to type is based on the flawed
> assumption that saving keystrokes will improve your efficiency. The
> sad fact is that code is read much more often than it is written, and
> therefore explicitness is good: it eases reading, and speeds up
> debugging. Therefore, when in doubt, you should opt for the verbose
> solution.

And when the code changes, it's just a simple search and replace.
Fun.

In fact, I like to have it both ways, and I do.  :-)

DaveA