Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Question on language design (keywords vs Pervasives)
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2000-08-21 (09:11)
From: John Prevost <jmp@a...>
Subject: Re: Question on language design (keywords vs Pervasives)
>>>>> "pw" == Pierre Weis <> 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.