catch/throw performance loss

[Kent M Pitman <KMP @ MIT-MC>]

Of course, there could be two routines -- one optimized for EQ when it
works, and one for EQL when needed. Unless THROW sees a number or char,
it can use the fast routine, no? In which case, we're not talking
performance loss -- just implementation overhead. 

In response to SKEF's remark about "Given the whole EQ not working on 
numbers business, I don't think there's more cognitive load on the 
programmer", I say I think he's confused. The point is that the user
(at least, me) is going to expect that implementors are going to take
their own advice and use EQL in places where EQ might be dangerous, and
this is such a place. It it undue burden on the programmer to have to
remember "EQ doesn't work on numbers, but I have to remember that THROW
will try to use it anyway, so I should be careful never to let THROW
try such a thing because a bug will bring my program down in flames".
It's holes in the language like this that drive users crazy.