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.