Bryan Creer hath writ:
| >I can see that we're going to end up having to write "smart" software
| >which can figure out the right answer from anything which looks like abc.
|
| Or, alternatively, we can all work to the same standard and save ourselves a
| lot of trouble.
Fat chance. Even if we try that, experience so far has shown that
there are serious incompatibilities possible between two programs
that follow the "standard". This is inevitable in any standard that's
written in English, which is hopelessly ambiguous. Lawyers have been
trying for centuries to develop a clear, unambiguous English subset,
and their general failure is shown by the huge number of cases in
which the courts have to decide what a law means.
In the case of ABC, there are a number of major ambiguities. Thus,
some time back someone brought up the question of whether it was
legal in ABC to divide a bar between two staffs, and use the
conventional indication of this by not having a bar line at the end
of the first staff. When I read this, my answer was "Of course this
is legal" because I'd already done it, and the main tool that I was
using (abc2ps) handled it correctly without even a warning. But then
it became apparent that a lot of other ABC programs choked on this,
and "knew" that it wasn't legal. What does Chris's "standard" say? It
doesn't mention the subject.
At the other end of the staff, I've received several messages from
people complaining about some of my files that put a bar line at the
start of the staff. They insist that this is illegal. It isn't, of
course, and is in fact common practice in some musical circles
(mostly those who also write partial measures at the end of a staff).
Again, the ABC standard doesn't mention the subject; it merely says
how bar lines are represented. This is a common way for a standard to
behave; just describe the notation and leave implementation details
to the programmers. The incompatibility comes from programmers who
have a narrow idea of what is "standard" music notation and aren't
aware of some of the notation used by musicians who play other sorts
of music.
Similarly, when I and others have brought up the subject of endings
other that |[1 and :|[2, it has been pointed out that the original
docs don't say that other endings are illegal. Chris merely wrote
that multiple endings are possible, and gave the above two examples.
The reasonable inference should have been at least that [3, [4 etc.
are all legal, too, and [1,3 and [1-3 are also both obvious things
that you'd expect to be able to use. But most programmers seem to
have written code that only accepts [1 and [2, and decrees all other
endings illegal. There is nothing in the 1.6 "standard" that decides
this issue; there is only the one example.
Other such ambiguities abound. A fair amount of the incompatibilities
in ABC are simply due to different programmers' different readings of
the ABC "standard". Combined with their different and often very
limited ideas as to what is legal staff notation, it's very easy to
get incompatibilities even when everyone thinks they are implementing
the same standard.
The new, more formal standard will presumably fix a lot of this sort
of problem, presumably by making it clear that the more general form
of such constructs are all legal and should be implemented. But this
will only solve some of the incompatibilities. We will still have to
deal with code written by programmers to don't allow something (such
as missing bar lines at the end of a staff) because they have never
seen such notation and never thought such a thing was possible,
This problem of programmers implementing a restricted language is not
at all new. It has happened repeatedly with programming languages.
One cute example that I ran across years ago: There were several
cases in the original Bell Labs Unix of expressions like:
"0123456789ABCDEF"[i]
When people started writing new C compiler that were not just ports
of Dennis Ritchie's compiler, quite a lot of them choked on this.
Many programmers reacted with disbelief when they first saw this. But
it is not just legal C; it is required to be legal by the standards.
One explanation I've seen is: If you don't believe this is (or should
be) legal C, you have a fundamental misunderstanding of C's syntax.
You are going to do a major rewrite of your parser, because you
didn't write a C parser at all; you wrote a parser for a very
different language. Don't complain; just RTFS (Read The F---ing
Standard), and try to get it right next time. And, BTW, we don't care
how much this syntax offends you. You'd damn well better implement
it, or your compiler won't pass the official test suites. Some of us
understand it, and we use it.
(One passage in the original C manual points out that, at least in C,
the binary operation called "subscripting" is commutative. This gets
an interesting response from a lot of people who stumble across it.
But it's a fact, and if you reject or don't understand it, you don't
understand how C's array mechanism works. So what are you doing
writing a C compiler? ;-)
Ultimately, if we are to get a consistent ABC syntax, we will find
ourselves taking a similar attitude. Programmers will implement
subsets for the sort of music that they know. This is only to be
expected, and isn't grounds for serious criticism in a first release.
But there is already ABC around that doesn't conform to narrow ideas
based on one style of music. As more people use ABC, this will become
even more true. We'll have to find ways of educating implementers
about the things that can be said with ABC that might not be familiar
to them. Either we find a way to persuade programmers to implement
the parts that they don't need for their own music, or we live with
incompatibilities like these.
But I'm getting longwinded again ...
---
Modern GUIs are very well designed, for people with three hands. The
real problem has been how slow customers have been to make necessary
hardware upgrades to meet the requirements of the software.
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
