I have a couple questions about current and planned Common Lisp
implementation practice.
1) The draft ANSI standard makes clear that a (VECTOR CHARACTER) is
indeed a STRING; and, for example, the default :ELEMENT-TYPE for
MAKE-STRING is CHARACTER. However, many current CL
implementations--including those on conventional processors--support
character bits such as Control, Meta, and even Hyper and Super. Thus,
fully general CHARACTERs in such systems are more than 8 bits wide.
Will such implementations eventually support "fat" STRINGs, or will
they simply drop their character bits?
2) The description of READ-PRESERVING-WHITESPACE in CLtL and CLtL2
notes that reading a list does not require additional delimiting
whitespace, because the close-parenthesis suffices to end the list. A
similar argument applies to a string. One might infer that READ and
READ-PRESERVING-WHITESPACE do not differ in behavior for such inputs.
However, in most CL implementations, READ indeed gobbles a space
character after the close parenthesis or double-quote. (LispWorks,
Allegro, Lucid, and CMU all eat the space; Genera, AKCL, and CLISP
don't.) Is there any particular reason for this?
Lawrence G. Mayka
AT&T Bell Laboratories
···@iexist.att.com
Standard disclaimer.
From: Charles A. Cox
Subject: Unix Allegro CL characters (was Common Lisp standard, implementations: questions)
Date:
Message-ID: <COX.93Feb8002016@crisp.Franz.COM>
In article <················@cbnewsc.ATT.COM> ···@cbnewsc.ATT.COM (lawrence.g.mayka) writes:
> 1) The draft ANSI standard makes clear that a (VECTOR CHARACTER) is
> indeed a STRING; and, for example, the default :ELEMENT-TYPE for
> MAKE-STRING is CHARACTER. However, many current CL
> implementations--including those on conventional processors--support
> character bits such as Control, Meta, and even Hyper and Super. Thus,
> fully general CHARACTERs in such systems are more than 8 bits wide.
> Will such implementations eventually support "fat" STRINGs, or will
> they simply drop their character bits?
This response is specifically about the Unix dpANS-compatible
Allegro CL which implements the dpANS character specification in
Allegro CL 4.1 (the current release) as follows:
--dpANS compatible Allegro CL continues to support font/bit attributes
of characters as an extension to dpANS. For example, the reader and
printer act on such characters in the pre-dpANS CL way (eg,
#\control-a is #\a with the control bit set, #3\meta-b is #\b with
font 3 and the meta bit set). What's more, functions operating on
bits and fonts from pre-dpANS CL (eg, STRING-CHAR-P, CHAR-BITS,
CHAR-FONT, MAKE-CHAR) are available in Allegro CL's CLTL1 package.
--In dpANS compatible Allegro CL, *it is an error* to store attributed
characters in a string. This is consistent with pre-dpANS behavior in
that attributed characters were not string-chars and so couldn't be in
strings. Thus, with respect to storing characters in strings,
pre-dpANS Allegro CL code should be able to run in dpANS Allegro CL
with very little or no source change. [Note: What in fact happens if
you try to store an attributed character into a string is that a
warning is signaled, and the character is stored with the attributes
stripped.]
One problematic area, however, is the places where the CHARACTER
type specifier is explicitly specified in calls to MAKE-ARRAY, or to
sequence functions that create a vector. (Such sequence functions
include COERCE, MAP, CONCATENATE, etc.) In pre-dpANS versions of
Allegro CL, (ARRAY CHARACTER) was equivalent to (ARRAY T). In dpANS
Allegro CL, (ARRAY CHARACTER) is a string. Thus, an (ARRAY CHARACTER)
is different from (ARRAY T) and is subject to the constraints
specified above. Therefore, users porting to dpANS may have to change
such places where the CHARACTER type specifier is explicitly used to
specify the T type specifier.
A hint to help make code that uses the now defunct STRING-CHAR
specifier portable between pre-dpANS and dpANS Common Lisps is to use
a reader macro as follows:
;; CLtL 1 only
(make-array 10 :element-type 'string-char)
can be rewritten portably as
;; dpANS and CLtL 1
(make-array 10 :element-type '#.(array-element-type ""))
Charley
--
---
Charles A. Cox, Franz Inc. 1995 University Avenue, Suite 275
Internet: ···@franz.com Berkeley, CA 94704
uucp: uunet!franz!cox Phone: (510) 548-3600; FAX: (510) 548-8253