Browse thread
Question on language design (keywords vs Pervasives)
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | John Prevost <jmp@a...> |
| Subject: | Re: Question on language design (keywords vs Pervasives) |
>>>>> "pw" == Pierre Weis <Pierre.Weis@inria.fr> writes:
pw> On the other hand, ``raise'' does not introduce a syntactic
pw> construct since exception raising is parsed as a regular
pw> application (application of the identifier raise to an
pw> exception value). Hence, strictly speaking, raise has not to
pw> be a keyword. However there are two good reasons to turn raise
pw> into a keyword:
pw> 1) To prevent the redefinition of the predefined raise
pw> primitive.
pw> 2) To parse the exception raising slightly
pw> differently than the regular application: for instance, we
pw> could spare some parentheses in case of a functional exception
pw> constructor, and write raise Invalid_argument "divide" instead
pw> of raise (Invalid_Argument "divide").
pw> This is as reasonable as the current syntactic status of
pw> raise: indeed, this scheme has been used in Caml for a long
pw> time.
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.
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.