From ...
Path: archiver1.google.com!news2.google.com!fu-berlin.de!news.eunet.no!news.powertech.no!nntp.newmedia.no!uio.no!nntp.uio.no!not-for-mail
From: Erik Naggum
Newsgroups: comp.lang.lisp
Subject: Re: Name for the set of characters legal in identifiers
Date: 15 Jan 2004 04:00:22 +0000
Organization: Naggum Software, Oslo, Norway
Lines: 42
Message-ID: <3283128022497673KL2065E@naggum.no>
References: <4004c6e2.127807819@news.eircom.net> <3283047574505462KL2065E@naggum.no> <4004f268.138951618@news.eircom.net> <3283057362064279KL2065E@naggum.no> <40052048.2C429E1F@setf.de> <3283091270658632KL2065E@naggum.no> <40058985.FF0A6B21@setf.de> <3283105015922595KL2065E@naggum.no> <4005CB00.6301FFB3@setf.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: readme.uio.no 1074139223 28156 129.240.65.210 (15 Jan 2004 04:00:23 GMT)
X-Complaints-To: abuse@uio.no
NNTP-Posting-Date: Thu, 15 Jan 2004 04:00:23 +0000 (UTC)
Mail-Copies-To: never
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
Xref: archiver1.google.com comp.lang.lisp:10026
* Erik Naggum
> But (read-from-string "a b") will return a symbol, namely A, when
> the constituent trait of the space is /invalid/.
* james anderson
| i had thought that circumstance was specified to signal an error.
Hm. This appears to be unexplored territory. You deserve credit
for pointing to the map and the real world and urging me to take a
closer look at both.
We have the following situation: A character whose syntax type is
/constituent/ is used to set the syntax type of a character whose
previous syntax type was /whitespace/, but this means that the
constituent trait of that character remains /invalid/, which makes
the syntax type /invalid/. According to the specification, such a
character can never occur in the input except under the control of a
single escape character, so (read-from-string "a b") should indeed
signal an error, as per 2.1.4.3. (In case anyone else wonders, the
multiple escape mechanism already forces all characters to have the
alphabetic trait.)
I thought I caught an obvious oversight in your test, but it would
have been strong enough to test the hypothesis, were it not for the
sorry fact that none of the Common Lisp environments I have access
to signal an error when encountering invalid characters in the input
stream.
| it was always 3.
OK, then this is definitely surprising and in clear violation of the
standard. You're right that SET-SYNTAX-FROM-CHAR should not clobber
the constituent trait for any character, not just the package marker.
Where is that annoying conformance test guy who stresses the useless
corners and boundary conditions of the standard when you need him?
--
Erik Naggum | Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.