Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
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.




  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