> On the other hand, allowing raise to be redefined has the advantage
> that raise could be replaced with a new function of the same type that
> does some extra work and then calls raise normally.  I can't think of
> a really good example at the moment, though.

You're right, there is no really good example that uses redefinition
of raise. That's why the advantage to be able to redefine it may
overcome the inconvenience of not being always sure of its meaning.

> My personal feeling is that it's good for the design of a language to
> make as few things keywords as possible.  For an example of too many
> keywords, see SQL, where the definition of the language not only
> reserves many many words, but also provides a list of possible future
> keywords (and mentions that this list is not exhaustive.)  SQL does,
> however, provide a way to escape identifiers which would otherwise
> conflict with reserved words.
> 
> John.

You're right, we don't want to have zillions of keywords. On the other
hand, you also need to have some level of confidence into the words
you use in the language, otherwise you can write horrors as the famous

if else then else else then

when then and else are not reserved.

Pierre Weis

INRIA, Projet Cristal, Pierre.Weis@inria.fr, http://cristal.inria.fr/~weis/