Re: tab

[Han-Wen Nienhuys]

I think you and I have a different idea of `macro'. 

<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.

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. 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.

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.

</rant>

-- 

Han-Wen Nienhuys   |   address@hidden    | http://www.cs.uu.nl/~hanwen/