Which is daft, because implementation-defined languages have some important advantages. To whit,
Portability: I'm serious. Every single time I read about a nontrivial piece of Scheme or Common Lisp software, it comes with a long list of caveats: "tested on Bigloo Scheme and MIT scheme, but won't work on CMU Scheme", "Works on Clisp but not SBCL; very slow on Franz Lisp due to their broken hash table implementation" or whatever. No matter how comprehensive a spec tries to be, there will always be edge cases that differ from implementation to implementation; there will always be bugs in the implementation that vary from one implementation to another; there will always be places where the implementors have helpfully added some useful functionality that's just too good to resist. This becomes a major headache. If a language is implementation-defined, however, the path of least resistance is to port or hack on the reference implementation rather than writing a new one from scratch. Consider the list of platforms to which perl has been ported. By the way, I'll follow Perl community practice herein and use "perl" consistently for the interpreter and "Perl" for the language: if you wish to do otherwise please read my footnote about scones.
There are of course variations between different ports of a program, but they're inevitably going to be less than the variations between programs that were developed entirely independently. This makes it easier for you, the language user, to write portable code: you don't need to worry about the variations between language implementations, and can concentrate on the vagaries of the different platforms you want your code to run on.
[This assumes that the implementation can be ported: sometimes you have no choice, which explains Jython et al.]
Lack of legalism: Suppose you have a question about the meaning of some code in your favourite spec-defined language. Obviously, you need to look it up in the spec. If you're lucky, you'll know your way around the spec, and will be able to find the right place(s). If you're very lucky, it will be a well-thought-out spec, and will address this issue. If you're very very lucky, it will be a well-written spec, and you'll be able to understand the answer. If you're very very very lucky, your favourite implementation will implement this part of the spec correctly, and if you're very very very very lucky, so will all the other implementations on which you want your code to run.
[The alert reader will have deduced that I've worked with some less-than-brilliant specs in my time.]
In an implementation-defined language, the question simply doesn't arise. Type it into the interpreter/compiler and see what happens. Whatever happens is, by definition, correct behaviour.
Lack of undefined behaviour: on a similar note, there is no undefined behaviour. Whatever the implementation does is what it does.
[Edit: not quite. See
yrlnry's comment below.]By the way, I'm not saying that all specifications are bad (a good one is an excellent thing to have) or that specification-defined languages have no advantages - I'm assuming that the advantages of specification-defined languages are so well-rehearsed that I don't need to repeat them. Anyone needing further enlightenment is encouraged to go to comp.lang.scheme and say "I think spec-defined languages suck!" :-)
Now for the second part of my rant: Haskell, as we know it today, is an implementation-defined language, defined by the latest CVS snapshot of GHC. "But what about the Haskell Report, and the Revised Report, and Haskell prime, and Hugs, and, er, those other implementations?" I hear you cry. Well, what about them? Every time I asked some question, it seemed, the answer would begin with "first download the latest version of GHC, then turn on these extensions..." A spec for a language that people don't actually use is - well, not useless, if it's sufficiently close to a language that they do use, but it ain't a specification as I understand the term. Everyone in the Haskell community seems to track the latest version of GHC for its new features. This is not spec-like behaviour. Now, as I said above, I don't think that implementation-defined languages are bad: quite the reverse. I just think it would save everyone a lot of bother and false superiority if the community could admit this to itself and to outsiders.
1 The O is short: "scone" rhymes with "gone", not "groan". Unless you're talking about the town in Scotland, when it rhymes with "boon". People who insist on mispronouncing this word around me will have their scones taken away from them and donated to the Pozorvlak Pedant-Feeding Drive.