From: John Prevost <jmp@arsdigita.com>
To: Pierre Weis <Pierre.Weis@inria.fr>
Cc: reig@dcs.gla.ac.uk, caml-list@inria.fr
Subject: Re: Question on language design (keywords vs Pervasives)
Date: 20 Aug 2000 15:55:22 -0400 [thread overview]
Message-ID: <87wvhb907p.fsf@localhost.localdomain.> (raw)
In-Reply-To: Pierre Weis's message of "Sun, 20 Aug 2000 21:01:03 +0200 (MET DST)"
>>>>> "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.
next prev parent reply other threads:[~2000-08-21 9:11 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-08-18 2:07 Fermin Reig
2000-08-19 16:57 ` Frank Atanassow
2000-08-20 19:01 ` Pierre Weis
2000-08-20 19:55 ` John Prevost [this message]
2000-08-21 8:58 ` Pierre Weis
2000-08-21 19:47 ` John Prevost
2000-08-21 21:41 ` Pierre Weis
2000-08-21 16:44 ` John Max Skaller
2000-08-21 21:24 ` Pierre Weis
2000-08-22 0:38 ` Kwangkeun Yi
2000-08-22 2:25 ` John Max Skaller
2000-08-22 9:08 ` Pierre Weis
2000-08-22 8:31 ` Pierre Weis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wvhb907p.fsf@localhost.localdomain. \
--to=jmp@arsdigita.com \
--cc=Pierre.Weis@inria.fr \
--cc=caml-list@inria.fr \
--cc=reig@dcs.gla.ac.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox