From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id LAA23614 for caml-red; Mon, 21 Aug 2000 11:11:50 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id VAA18984 for ; Sun, 20 Aug 2000 21:55:54 +0200 (MET DST) Received: from isil.localdomain (exodus-rtr-2.arsdigita.com [216.34.106.252]) by nez-perce.inria.fr (8.10.0/8.10.0) with ESMTP id e7KJtrP19222; Sun, 20 Aug 2000 21:55:53 +0200 (MET DST) Received: by isil.localdomain (Postfix, from userid 1000) id 76CAB369DB; Sun, 20 Aug 2000 15:55:23 -0400 (EDT) To: Pierre Weis Cc: reig@dcs.gla.ac.uk, caml-list@inria.fr Subject: Re: Question on language design (keywords vs Pervasives) References: <200008201901.VAA17272@pauillac.inria.fr> From: John Prevost Date: 20 Aug 2000 15:55:22 -0400 In-Reply-To: Pierre Weis's message of "Sun, 20 Aug 2000 21:01:03 +0200 (MET DST)" Message-ID: <87wvhb907p.fsf@localhost.localdomain.> User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: weis@pauillac.inria.fr >>>>> "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. John.