perm filename COMMON.MSG[COM,LSP]51 blob sn#875214 filedate 1989-07-10 generic text, type C, neo UTF8
COMMENT ⊗   VALID 00035 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00006 00002	
C00007 00003	∂13-Dec-88  1443	Common-Lisp-mailer 	foreign function    
C00009 00004	∂13-Dec-88  1707	Common-Lisp-mailer 	file loading query  
C00014 00005	∂13-Dec-88  2107	Common-Lisp-mailer 	Common Lisp for SUNS
C00016 00006	∂14-Dec-88  0813	Common-Lisp-mailer 	RE: load defaults   
C00020 00007	∂14-Dec-88  0959	Common-Lisp-mailer 	RE: load defaults   
C00022 00008	∂14-Dec-88  1619	Common-Lisp-mailer 	Re: load defaults   
C00025 00009	∂15-Dec-88  1720	Common-Lisp-mailer 	WG16 document N31, "Working documents on CALLING MECHANISMS..."  
C00026 00010	∂15-Dec-88  1853	CL-Compiler-mailer 	dumping weird objects to compiled files 
C00030 00011	∂16-Dec-88  0123	Common-Lisp-mailer 	file loading query  
C00032 00012	∂16-Dec-88  0733	CL-Compiler-mailer 	Re: dumping weird objects to compiled files  
C00035 00013	∂16-Dec-88  0843	Common-Lisp-mailer 	Re:  dumping weird objects to compiled files 
C00038 00014	∂16-Dec-88  1821	Common-Lisp-mailer 	file loading query  
C00042 00015	∂22-Dec-88  1219	Common-Lisp-mailer 	commonlisp types    
C00049 00016	∂27-Dec-88  0819	Common-Lisp-mailer 	Experiences porting applications from Symbolics   
C00052 00017	∂02-Jan-89  1238	Common-Lisp-mailer 	commonlisp types    
C00056 00018	∂03-Jan-89  0340	Common-Lisp-mailer 	commonlisp types    
C00060 00019	∂03-Jan-89  1714	Common-Lisp-mailer 	PROG1 as a function 
C00063 00020	∂04-Jan-89  0102	Common-Lisp-mailer 	commonlisp types    
C00066 00021	∂04-Jan-89  0537	Common-Lisp-mailer 	re: commonlisp types
C00068 00022	∂04-Jan-89  0921	Common-Lisp-mailer 	PROG1 as a function meta-rules of CLtL 
C00075 00023	∂04-Jan-89  1054	Common-Lisp-mailer 	PROG1 as a function 
C00078 00024	∂04-Jan-89  1111	Common-Lisp-mailer 	PROG1 as a function 
C00082 00025	∂04-Jan-89  1131	Common-Lisp-mailer 	PROG1 as a function 
C00085 00026	∂04-Jan-89  1252	Common-Lisp-mailer 	PROG1 as a function meta-rules of CLtL 
C00092 00027	∂04-Jan-89  1328	Common-Lisp-mailer 	PROG1 as a function 
C00096 00028	∂04-Jan-89  1333	Common-Lisp-mailer 	PROG1 as a function 
C00100 00029	∂04-Jan-89  1337	Common-Lisp-mailer 	PROG1 as a function 
C00103 00030	∂04-Jan-89  1354	Common-Lisp-mailer 	Re: PROG1 as a function meta-rules of CLtL  
C00108 00031	∂04-Jan-89  1414	Common-Lisp-mailer 	PROG1 as a function 
C00112 00032	∂06-Jan-89  1346	Common-Lisp-mailer 	commonlisp types    
C00116 00033	∂06-Jan-89  1346	Common-Lisp-mailer 	commonlisp types    
C00120 00034	∂06-Jan-89  2112	Common-Lisp-mailer 	Re: commonlisp types     
C00123 00035	∂07-Jan-89  0054	Common-Lisp-mailer 	commonlisp types    
C00127 ENDMK
C⊗;
∂13-Dec-88  1443	Common-Lisp-mailer 	foreign function    
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 13 Dec 88  14:42:52 PST
Date: Tue, 13 Dec 88 12:54:23 PST
From: Thom Linden <baggins@ibm.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <881213.125423.baggins@IBM.com>
Subject: foreign function

  Even though the bulk of participants in x3j13 are moving into the
"editorial" phase of the process, I see no reason why a new
subcommittee shouldn't be formed.  It's probably unlikely that
anything would make it into the first release of the std but
it is reasonable for folks to begin work on next release items as with,
for example, some of the iteration committee activity.  Another
example might be vol3 of CLOS.  We shouldn't be pressed prematurely
into incorporating everything into the 1989 draft.

  At the Jan meeting, someone should suggest this subcommittee be
formed and simply begin the discussion with those of similar interest.



∂13-Dec-88  1707	Common-Lisp-mailer 	file loading query  
Received: from DST.BOLTZ.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 13 Dec 88  17:06:48 PST
Received: from DST.BOLTZ.CS.CMU.EDU by DST.BOLTZ.CS.CMU.EDU; 13 Dec 88 20:05:13 EST
To: common-lisp@sail.stanford.edu
Reply-To: Dave.Touretzky@cs.cmu.edu
Subject: file loading query
Date: Tue, 13 Dec 88 20:04:24 EST
Message-ID: <2131.598064664@DST.BOLTZ.CS.CMU.EDU>
From: Dave.Touretzky@B.GP.CS.CMU.EDU

I have a problem with the way Common Lisp says pathname defaults should be
handled during load.  I have a software system structured as a header file
FOO.LISP that loads various component files BAR1, BAR2, BAR3, etc.  Some of
the component files may in turn load other components.

Now, I actually have several versions of this system, each living in its
own directory.  Whenever I make a new version due to an experimental change
to one component, or to test out the code generated by a new compiler, I
put it in its own directory.  The problem is, how do I get the calls to
LOAD that appear in FOO, and in the files loaded by FOO, to look in
whatever directory the header file FOO was loaded from?

The current definition of LOAD looks at *DEFAULT-PATHNAME-DEFAULTS*, so one
solution would be to set this variable manually every time, before loading
FOO.  That's a real nuisance, which I'd like to avoid if possible.  Another
possibility would be to add a line at the beginning of FOO to set
*DEFAULT-PATHNAME-DEFAULTS*, but that also loses because (a) every time I
made a new copy of the software I would have to edit FOO, and (b) when I
want to replace one version of the software with another, as when replacing
the contents of directory old/ with current/ and current/ with new/, I
would have to make sure NOT to copy the header file.  The potential for
problems if the header file is accidentally copied is too great.

In some implementations (either the Symbolics or the TI machine I worked on
about 2 years ago), a call to LOAD embedded in a file appeared to get its
pathname defaults from the pathname of the parent file being loaded, but
this doesn't appear to be part of the Common Lisp standard.  In other
implementations I seem to recall LOAD rebinding *STANDARD-INPUT*, so I
could snarf the actual pathname information from there.  But in CMU Common
Lisp, LOAD does not rebind *STANDARD-INPUT*, and CLtL doesn't seem to
require this.  So...

1. Anybody know a *portable* trick I can use to get embedded calls to LOAD
to use the parent file's pathname as a default?

2. How terrible would it be for LOAD to rebind *DEFAULT-PATHNAME-DEFAULTS* ?

3. Alternatively, what would people think of adding a :PARENT-PATH keyword
to LOAD.  With a value of T this keyword would mean "if this is an embedded
load, get default pathname information from the pathname of the parent
file" ?

-- Dave

∂13-Dec-88  2107	Common-Lisp-mailer 	Common Lisp for SUNS
Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 13 Dec 88  21:07:27 PST
Received: from decwrl.dec.com by labrea.stanford.edu with TCP; Tue, 13 Dec 88 21:06:07 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
	for labrea!sail.stanford.edu!common-lisp; id AA07389; Tue, 13 Dec 88 21:06:33 PST
Received: by pyramid.pyramid.com (5.51/OSx4.4-880707)
	id AA14035; Tue, 13 Dec 88 18:58:33 PST
Received: by neat.ai.toronto.edu with UUCP id 38064; Tue, 13 Dec 88 16:21:52 EST
Received: by nexus.yorku.ca with UUCP id 28713; Tue, 13 Dec 88 13:14:31 EST
Received: from istsai.yorku.ca by ists.yorku.ca (3.2/smail2.5/15-05-88)
	id AA09454; Tue, 13 Dec 88 02:45:21 EST
Date: 	Tue, 13 Dec 88 02:46:37 EST
From: mike@ists.yorku.ca
Message-Id: <8812130746.AA03313@istsai.yorku.ca>
To: bill@red.ipsa.dnd.ca
Cc: common-lisp@sail.stanford.edu
In-Reply-To: IN%"bill@red.ipsa.dnd.ca"'s message of 29 NOV 88 11:47 EST
Subject: Common Lisp for SUNS


I have some experiences.
Give me a call at 416-736-5611 if you wnat to talk.

Mike.

∂14-Dec-88  0813	Common-Lisp-mailer 	RE: load defaults   
Received: from crash.cs.umass.edu ([128.119.40.235]) by SAIL.Stanford.EDU with TCP; 14 Dec 88  08:13:15 PST
Received: from vax2.cs.umass.edu by crash.cs.umass.edu (5.59/Ultrix2.0-B)
	id AA02232; Wed, 14 Dec 88 11:14:26 est
Message-Id: <8812141614.AA02232@crash.cs.umass.edu>
Date: Wed, 14 Dec 88 11:11 EST
From: MURRAY@cs.umass.EDU
Subject: RE: load defaults
To: common-lisp@sail.stanford.EDU
X-Vms-To: IN%"common-lisp@sail.stanford.EDU"


> From: Dave.Touretzky@B.GP.CS.CMU.EDU
>I have a problem with the way Common Lisp says pathname defaults should be
> handled during load...

My initial reaction is that you should be using some sort of defsystem,
which gives you much more control over sets of files.
But maybe you're trying to run bare-bones.  

>1. Anybody know a *portable* trick I can use to get embedded calls to LOAD
>to use the parent file's pathname as a default?

There is no portable way to find out what pathname is currently being
loaded.  The portable way to get your desired behavior is simply to define your own
load function that will bind *DEFAULT-PATHNAME-DEFAULTS* to the file it
is loading before it calls the real load.
   (defun default-load (input &rest args)
     (let ((*default-pathname-defaults* (merge-pathnames input)))
       (apply 'load *default-pathname-defaults* args)))

>2. How terrible would it be for LOAD to rebind *DEFAULT-PATHNAME-DEFAULTS* ?

Probably not too terrible, but it does create another instance of
a problem that some people have complained about.  By having LOAD bind
a special variable, it make it impossible to have the contents of a
file side-effect that variable after the load.  This is a current problem
with *package*.

>3. Alternatively, what would people think of adding a :PARENT-PATH keyword
>to LOAD.  With a value of T this keyword would mean "if this is an embedded
>load, get default pathname information from the pathname of the parent
>file" ?

Surely you jest!


Kelly Murray

∂14-Dec-88  0959	Common-Lisp-mailer 	RE: load defaults   
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 14 Dec 88  09:59:23 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
	id AA28669; Wed, 14 Dec 88 09:59:57 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
	id AA27264; Wed, 14 Dec 88 09:56:35 PST
Received: by clam.sun.com (3.2/SMI-3.2)
	id AA14360; Wed, 14 Dec 88 09:57:31 PST
Date: Wed, 14 Dec 88 09:57:31 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8812141757.AA14360@clam.sun.com>
To: Dave.Touretzky@B.GP.CS.CMU.EDU, MURRAY@cs.umass.EDU,
        common-lisp@sail.stanford.EDU
Subject: RE: load defaults

Some implementations of Common Lisp include a special variable
with a name like *source-pathname*, which is bound appropriately
by LOAD.  This supports what is commonly known as "source code
recording" and if added to Common Lisp would meet needs such
as Touretzky's.  We have found need for this at Sun and would
be happy to see such a thing in the language at some time.

				-Cris

∂14-Dec-88  1619	Common-Lisp-mailer 	Re: load defaults   
Received: from DST.BOLTZ.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 14 Dec 88  16:19:18 PST
Received: from DST.BOLTZ.CS.CMU.EDU by DST.BOLTZ.CS.CMU.EDU; 14 Dec 88 19:17:08 EST
To: common-lisp@sail.stanford.EDU
Reply-To: Dave.Touretzky@cs.cmu.edu
Subject: Re: load defaults 
In-reply-to: Your message of Wed, 14 Dec 88 11:11:00 -0500.
	     <8812141614.AA02232@crash.cs.umass.edu> 
Date: Wed, 14 Dec 88 19:16:51 EST
Message-ID: <3154.598148211@DST.BOLTZ.CS.CMU.EDU>
From: Dave.Touretzky@B.GP.CS.CMU.EDU

> Date: Wed, 14 Dec 88 11:11 EST 
> From: MURRAY@cs.umass.EDU
>
>  There is no portable way to find out what pathname is currently being
>  loaded.  The portable way to get your desired behavior is simply to
>  define your own load function that will bind *DEFAULT-PATHNAME-DEFAULTS*
>  to the file it is loading before it calls the real load.
>     (defun default-load (input &rest args)
>       (let ((*default-pathname-defaults* (merge-pathnames input)))
>         (apply 'load *default-pathname-defaults* args)))

This is a nice idea, but it doesn't solve my problem.  The user would have
to type in the whole definition before he could use it to load the header
file I referred to.  I want to avoid inconveniencing the user; he should be
able to just start up a fresh Lisp, LOAD a single header file, and have
everything else happen automatically.

I like KMP's proposals.  I like the second one best: have separate
variables for files being loaded and files being compiled, and use them to
maintain a stack so we can see the nesting of loads within files.

-- Dave

∂15-Dec-88  1720	Common-Lisp-mailer 	WG16 document N31, "Working documents on CALLING MECHANISMS..."  
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 15 Dec 88  17:20:23 PST
Date: Thu, 15 Dec 88 09:55:14 PST
From: Thom Linden <baggins@ibm.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <881215.095514.baggins@IBM.com>
Subject: WG16 document N31, "Working documents on CALLING MECHANISMS..."

I have a copy of the document Jeff mentioned and will bring it to
the Jan. meeting.

Thom

∂15-Dec-88  1853	CL-Compiler-mailer 	dumping weird objects to compiled files 
Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 15 Dec 88  18:53:10 PST
Posted-Date: Thu, 15 Dec 88 18:52:28 PST
Message-Id: <8812160252.AA06530@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.59/5.51)
	id AA06530; Thu, 15 Dec 88 18:52:31 PST
To: common-lisp@sail.stanford.edu, cl-compiler@sail.stanford.edu
Cc: lwolf%franz.uucp@berkeley.edu
Subject: dumping weird objects to compiled files
Date: Thu, 15 Dec 88 18:52:28 PST
From: Don Cohen <donc@vaxa.isi.edu>

The commonlisp spec is quite vague on what exactly the compiler
should do and provides no control over how or whether strange
objects can be dumped at all.  However, in the case of structures
it does provide for a print function.  Suppose I have a function
F that uses a macro M which expands into some structure of type S.

1. If I give S a print function, can I expect that when I compile F
to a file, that print function will be used to write something to
the compiled file that will be read to return the "corresponding"
object when the file is loaded?  (I'm interested in justifications
for either answer.)  The other possibility is that the compiler 
would ignore the print function and dump something that would, 
when loaded, create a structure of type S and fill its slots with 
objects that were recursively dumped.  If I could count on my print 
function being used, I could arrange for it to print something that 
would "do the right thing".
2. If you don't think that my expectation is justified, do you
think the commonlisp spec ought to say that it is (thereby making
it so).

This "trick" would allow us to write a macro that allows macros
to generate the analog of #, which I think is a feature sorely
missed in commonlisp.  This in turn would go a long way toward
solving what I regard as a problem with the spec - that EQUAL
values may be identified.  This is a solution just because it
returns control over what things are EQ to the user, who knows
which things he wants to be EQ, which things he does NOT want EQ
and which don't matter.

∂16-Dec-88  0123	Common-Lisp-mailer 	file loading query  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 16 Dec 88  01:22:59 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00971g; Fri, 16 Dec 88 01:20:08 PST
Received: by bhopal id AA20998g; Fri, 16 Dec 88 01:22:08 PST
Date: Fri, 16 Dec 88 01:22:08 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8812160922.AA20998@bhopal>
To: Dave.Touretzky@cs.cmu.edu
Cc: common-lisp@sail.stanford.edu
In-Reply-To: Dave.Touretzky@B.GP.CS.CMU.EDU's message of Tue, 13 Dec 88 20:04:24 EST <2131.598064664@DST.BOLTZ.CS.CMU.EDU>
Subject: file loading query

re: 1. Anybody know a *portable* trick I can use to get embedded calls to LOAD
    to use the parent file's pathname as a default?

I doubt that there's a portable trick.  Lucid Common Lisp supports an
extension as follows:
    (defvar *load-pathname* nil
      "During a load, this is bound to the pathname of the file being loaded.")
and ocasionally it is used to find out what directory the currently
loading file is on, so that a related file can be loaded from the same
directory.


-- JonL --

∂16-Dec-88  0733	CL-Compiler-mailer 	Re: dumping weird objects to compiled files  
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 16 Dec 88  07:32:56 PST
Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs)
	id AA06704; Fri, 16 Dec 88 08:31:57 MST
Received: by defun.utah.edu (5.59/utah-2.0-leaf)
	id AA05675; Fri, 16 Dec 88 08:31:53 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8812161531.AA05675@defun.utah.edu>
Date: Fri, 16 Dec 88 08:31:51 MST
Subject: Re: dumping weird objects to compiled files
To: Don Cohen <donc@vaxa.isi.edu>
Cc: common-lisp@sail.stanford.edu, cl-compiler@sail.stanford.edu,
        lwolf%franz.uucp@berkeley.edu
In-Reply-To: Don Cohen <donc@vaxa.isi.edu>, Thu, 15 Dec 88 18:52:28 PST

The cl-compiler subcommittee is in the midst of preparing a set of
elaborate proposals to submit to X3J13 to detail exactly what kinds of
constant objects may be compiled.  We do think it is important for the
ANSI standard to say more than CLtL does about this.

At the moment we appear to be heading towards the conclusion that the
dump/load transformation on structures created with DEFSTRUCT ought to
always create a structure isomorphic to the original, regardless of
whether or not that structure type has a user-supplied :PRINT-FUNCTION.
However, we have also talked about something similar to the dump/load
protocol you describe in the context of arbitrary CLOS objects.

-Sandra
-------

∂16-Dec-88  0843	Common-Lisp-mailer 	Re:  dumping weird objects to compiled files 
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 16 Dec 88  08:43:29 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
	id AA27569; Fri, 16 Dec 88 08:45:46 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
	id AA02972; Fri, 16 Dec 88 08:42:27 PST
Received: by clam.sun.com (3.2/SMI-3.2)
	id AA17011; Fri, 16 Dec 88 08:43:24 PST
Date: Fri, 16 Dec 88 08:43:24 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8812161643.AA17011@clam.sun.com>
To: cl-compiler@sail.stanford.edu, donc@vaxa.isi.edu
Subject: Re:  dumping weird objects to compiled files
Cc: common-lisp@sail.stanford.edu, lwolf%franz.uucp@berkeley.edu

Hi Don!

I'm working on a proposal on this exact issue, i.e. what Common
Lisp is supposed to do about (quoted) constants in compiled files.
There are big holes in the definition of Common Lisp today
concerning compilation, and this is one of them.

To answer one of your questions, no you definitely cannot
expect your constants to be PRINTed into compiled files.  Most
implementations use some binary representation of data.

There is interest in supporting user-defined types (structures
and classes) with user-definable dumpers, but it's just too much
work for me to personally try to address that.  Hopefully some
good facility will get defined.

There is also interest in something comparable to #, that is not
a readmacro, so you can sensibly generate them in programs and
at least one proposal for that.

You can mail to me for more information.

				-Cris

∂16-Dec-88  1821	Common-Lisp-mailer 	file loading query  
Received: from trwrb.dsd.trw.com (TRWRB.TRW.COM) by SAIL.Stanford.EDU with TCP; 16 Dec 88  18:21:13 PST
Received: by trwrb.dsd.trw.com (5.51/1.36)
	id AA14762; Fri, 16 Dec 88 18:18:22 PST
From: smpvax1!daemon@trwrb.dsd.trw.com
Received: by smpvax1.inference.com (3.2/SMI-3.2 SBB's version)
	id AA07290; Fri, 16 Dec 88 17:30:56 PST
Date: Fri, 16 Dec 88 17:30:56 PST
Message-Id: <8812170130.AA07290@smpvax1.inference.com>
To: Dave.Touretzky\@cs.cmu.edu@trwrb.dsd.trw.com,
        ucbvax!lucid.com!jonl@trwrb.dsd.trw.com
Cc: common-lisp\@sail.stanford.edu@trwrb.dsd.trw.com
In-Reply-To: Jon L White's message of Fri, 16 Dec 88 01:22:08 PST <8812160922.AA20998@bhopal>
Subject: file loading query


re: 1. Anybody know a *portable* trick I can use to get embedded calls to LOAD
    to use the parent file's pathname as a default?

You needn't be a privileged implementor to use Lucid's idea.

This should be portable:


(defvar *my-load-pathname* nil)

(defun my-load (partial-path)
  (let ((*my-load-pathname* (merge-pathnames partial-path *my-load-pathname*)))
    (load *my-load-pathname*)))

and replace all calls to load in files with calls to my-load, e.g.,

(my-load "What-a-moaning")

A more general thing involving twiddling the prefix of a directory tree
from which embedded loads will occur in various subdirectories might be

(defun load-from-subtree (partial-path path-function)
  (let ((*my-load-pathname* (funcall path-function partial-path *my-load-pathname*)))
    (load *my-load-pathname*)))

and replace embedded load calls with load-from-subtree.  Typically the
path-function will concatenate the directories of *my-load-pathname* and
partial-path, or something.  At least on Lucid 3.0, merge-pathnames serves
as such a function, as in (merge-pathnames "arith/bignum" "~/broken/mork.bin").

Jeff Greif
Inference Corp.


∂22-Dec-88  1219	Common-Lisp-mailer 	commonlisp types    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Dec 88  12:18:57 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 511560; Thu 22-Dec-88 15:17:50 EST
Date: Thu, 22 Dec 88 15:17 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: commonlisp types
To: gls@Think.COM
cc: jwz@spice.cs.cmu.edu, common-lisp@sail.stanford.edu
In-Reply-To: <8812021633.AA05964@verdi.think.com>
Message-ID: <881222151736.1.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Fri, 2 Dec 88 11:33:22 EST
    From: Guy Steele <gls@Think.COM>

       Date: Fri, 2 Dec 1988 00:40-EST 
       From: Jamie.Zawinski <jwz@spice.cs.cmu.edu>
       ...
       Can someone explain the rationale behind forcing SATISFIES to 
       accept only function-names and not lambda expressions?
       I can see that the compiler could have special knowledge about
       such forms as (SATISFIES PLUSP), but CLtL says lambdas are excluded
       "to avoid scoping problems."

    Consider

    (defun bazola (linguini pop-tarts)
      (declare (type (satisfies (lambda (x) (< x linguini))) pop-tarts))
      ...)

    I'm trying to say that pop-tarts is always smaller in value than linguini.
    The lambda expression appears lexically within the binding of linguini,
    so one might expect that the free reference to linguini is legitimate.
    But it can't work.

    Similarly this cannot work:

    (defun bazola (linguini pop-tarts)
      (assert (typep pop-tarts '(satisfies (lambda (x) (< x linguini)))))
      ...)

    [Of course, this can be rendered instead as

    (defun bazola (linguini pop-tarts)
      (assert (< pop-tarts linguini))
      ...)

    but that is beside the point.]

    One might conceivably argue that SATISFIES should allow an actual
    function and not just a name; then one might try

    (defun bazola (linguini pop-tarts)
      (assert (typep pop-tarts `(satisfies ,(lambda (x) (< x linguini)))))
      ...)

    but this approach doesn't help the declaration case.  It's a basic problem
    of compile-time versus run-time execution.

    --Guy

Fyi, it turns out this rationale doesn't hold as much water as you'd think.
Consider:

 (defun bar (x) (symbolp x))

 (defun foo (x)
   (flet ((bar (y) (integerp y)))
     (typep x '(satisfies bar))))

 (foo 'x)

The correct answer is T, but I bet a lot of implementations return NIL
in compiled code.

Anyway, my main point is that the reason for prohibiting lambda expressions
isn't that they're not meaningful, only that they're hard to reason about.
But since an analogous argument can be made for symbols, the rationale breaks
down.

Since (SATISFIES BAR) means that (FUNCALL (SYMBOL-FUNCTION 'BAR) ...) is
true, not that (FUNCALL #'BAR ...) is true, then it follows that
(SATISFIES (LAMBDA (X) (AND (BAR X) (BAZ X)))) means
(FUNCALL (EVAL '#'(LAMBDA (X) (AND (BAR X) (BAZ X)))) ...) is true, not
that
(FUNCALL #'(LAMBDA (X) (AND (BAR X) (BAZ X))) ...) is true.

The real truth is that we thought the scoping problems were limited to
LAMBDA expressions because we weren't used to reasoning about FLET, which
was a new construct at the time we designed CL. If we had it to do over,
I'd certainly be lobbying strongly for permitting lambda expressions.

The Common-Lisp mailing list doesn't have the authority to change the 
language, so I'll save any proposals to change things for other forums.
But I did want to publicly debunk the myth behind this design decision.

Btw, if LAMBDA expressions -were- permitted, the BAZOLA example you suggest
could, in addition to the more obvious way you cite, be written as:

    (defun bazola (linguini pop-tarts)
      (declare (special linguini))
      (assert (typep pop-tarts '(satisfies (lambda (x)
					     (declare (special linguini))
					     (< x linguini)))))
      ...)

This works even if you open code it in the obvious way, though it has
the disadvantage that figuring out that the SPECIAL declaration was needed
only for the sake of the transition into the SATISFIES and not for some
function called within the opened LAMBDA may be tricky. So the open-coded
form may do a needless special bind in complex cases involving calls to
user-defined predicates.

∂27-Dec-88  0819	Common-Lisp-mailer 	Experiences porting applications from Symbolics   
Received: from gateway.mitre.org by SAIL.Stanford.EDU with TCP; 27 Dec 88  08:19:42 PST
Received: by gateway.mitre.org (5.54/SMI-2.2)
	id AA10060; Tue, 27 Dec 88 11:15:04 EST
Return-Path: <howell%community-chest.mitre.org@gateway.mitre.org>
Received: by chance.mitre.org (3.2/SMI-2.2)
	id AA21082; Tue, 27 Dec 88 11:12:23 EST
From: howell%community-chest.mitre.org@gateway.mitre.org
Message-Id: <8812271612.AA21082@chance.mitre.org>
To: ailist@ai.ai.mit.edu, common-lisp@sail.stanford.edu,
        slug@warbucks.ai.sri.com
Cc: howell@mitre.ARPA
Subject: Experiences porting applications from Symbolics
Date: Tue, 27 Dec 88 11:12:21 -0500

I'm trying to make a quick and dirty estimate of the level of effort
required to port a local application from the Symbolics to other hosts
(probably a microvax II or an HP 9000).  Any experiences with such a port
(to any other hosts, not just the HP or microVax) would be very helpful.
For example, did you encounter problems with variant semantics in different
Common Lisp compilers?  What kind of support did the new host provide for
mouse-sensitive bit-mapped graphics, and for access to them?  Did you find
that your application depended on Symbolics-provided function libraries or
"OS services", or was your application relatively host-independent?
Any big "gotchas" that you didn't expect?

Thanks in advance for any replies.

Chuck Howell, MITRE
howell@mitre.mitre.org
(703) 883-6080

∂02-Jan-89  1238	Common-Lisp-mailer 	commonlisp types    
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Jan 89  12:37:56 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 514019; Mon 2-Jan-89 15:35:56 EST
Date: Mon, 2 Jan 89 15:35 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: commonlisp types
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
cc: gls@Think.COM, jwz@spice.cs.cmu.edu, common-lisp@sail.stanford.edu
In-Reply-To: <881222151736.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Message-ID: <19890102203526.6.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Thu, 22 Dec 88 15:17 EST
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

	Date: Fri, 2 Dec 88 11:33:22 EST
	From: Guy Steele <gls@Think.COM>

	   Date: Fri, 2 Dec 1988 00:40-EST 
	   From: Jamie.Zawinski <jwz@spice.cs.cmu.edu>
	   ...
	   Can someone explain the rationale behind forcing SATISFIES to 
	   accept only function-names and not lambda expressions?
        ....
    Fyi, it turns out this rationale doesn't hold as much water as you'd think.
    Consider:

     (defun bar (x) (symbolp x))

     (defun foo (x)
       (flet ((bar (y) (integerp y)))
	 (typep x '(satisfies bar))))

     (foo 'x)

    The correct answer is T, but I bet a lot of implementations return NIL
    in compiled code.

    ....
    The real truth is that we thought the scoping problems were limited to
    LAMBDA expressions because we weren't used to reasoning about FLET, which
    was a new construct at the time we designed CL. If we had it to do over,
    I'd certainly be lobbying strongly for permitting lambda expressions.

You're right.  I think what really happened is not that we weren't used
to FLET, but that FLET and LABELS were added to the language after
type-specifiers had been designed, and the full ramifications of FLET on
the rest of the language were not explored at the time it was added.

∂03-Jan-89  0340	Common-Lisp-mailer 	commonlisp types    
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 3 Jan 89  03:39:54 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.Dialnet.Symbolics.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 305296; 3 Jan 89 06:37:40 EST
Date: Tue, 3 Jan 89 05:35 EST
From: Robert W. Kerns <RWK@F.ILA.Dialnet.Symbolics.COM>
Subject: commonlisp types
To: jonl%lucid.com@RIVERSIDE.SCRC.SYMBOLICS.COM, common-lisp%sail.stanford.edu@RIVERSIDE.SCRC.SYMBOLICS.COM
In-Reply-To: <8812070546.AA11501@bhopal>
Supersedes: <19890103090720.6.RWK@F.ILA.Dialnet.Symbolics.COM>
Comments: Retransmission of failed mail.
Message-ID: <19890103103558.4.RWK@F.ILA.Dialnet.Symbolics.COM>

    Date: Tue, 6 Dec 88 21:46:27 PST
    From: Jon L White <jonl@lucid.com>

    re: There seems to be nothing in CLtL that answers the question:
	    "is x a legal type specifier?"

    At the meeting that founded the X3J13 committee (on 6-Dec-85), Guy Steele 
    circulated a list of "non-controversial issues" and "Clarifications"
    which included the following addition [typos faithfully reproduced]:

      "(*) 51 Add a newefunction TYPE-SPECIFIER-P that is true of valid type
       specifiers and fals of all other Lisp objects.  Note that the use of
       DEFSTRUCT and DEFTYPE can change the behavior of TYPE-SPECIFIER-P over
       time."

    Sad to say, this and many other "non-controversial" items included in
    Guy's list of "Clarifications", has never been brought up in the X3J13
    "Cleanup" subcommittee.  However, Lucid's 3.0 release includes such 
    a function.

How do you define "valid type specifier"?

(deftype foo (x)
   (car x))

(typep 'yow '(foo a))

==> Error taking CAR of the symbol A.

(type-specifier-p '(foo a))

==> ?

I would guess probably T, but then, how do you word the definition?
If not, how do you define it?

∂03-Jan-89  1714	Common-Lisp-mailer 	PROG1 as a function 
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 3 Jan 89  17:14:00 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Tue, 3 Jan 89 19:44:12 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 3 Jan 89 20:10:55 EST
Date: Tue, 3 Jan 89 20:10 EST
From: Barry Margolin <barmar@Think.COM>
Subject: PROG1 as a function
To: common-lisp@sail.stanford.edu
Message-Id: <19890104011056.6.BARMAR@OCCAM.THINK.COM>

One of our users noticed today that Symbolics defines PROG1 as a
function, rather than as a macro as CLtL specifies.  The definition is
essentially

	(defun prog1 (first-form &rest rest-forms)
	  (declare (ignore rest-forms))
	  first-form)

This works because CL requires left-to-right evaluation of function
arguments; it just does a bit more consing than a macro implementation
would need to do.  The compiler open-codes PROG1 invocations, so this is
only used in the interpreter.

Does this seem valid?  The only implementation leeway CLtL mentions is
that macros may be implemented as special forms, so long as an
equivalent macro definition is also made available; it doesn't
specifically mention implementing macros as functions (probably because
the developers thought that none of them COULD be implemented as
functions).

I don't see how this could cause any code to fail.

                                                barmar

∂04-Jan-89  0102	Common-Lisp-mailer 	commonlisp types    
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Jan 89  01:01:59 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04028g; Wed, 4 Jan 89 00:56:44 PST
Received: by bhopal id AA01403g; Wed, 4 Jan 89 00:58:57 PST
Date: Wed, 4 Jan 89 00:58:57 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901040858.AA01403@bhopal>
To: RWK@F.ILA.Dialnet.Symbolics.COM
Cc: common-lisp@sail.stanford.edu
In-Reply-To: Robert W. Kerns's message of Tue, 3 Jan 89 05:35 EST <19890103103558.4.RWK@F.ILA.Dialnet.Symbolics.COM>
Subject: commonlisp types

re: How do you define "valid type specifier"?

Very syntactically.  I think its perfectly acceptable to have a set
of combination rules for making "words" in the type-specifier syntax,
even though some such "words" would be gibberish.

The important thing is that base-level types -- those defined in 
CLtL -- along with DEFSTRUCT extensions be recognizable.  They don't
have the problems that SATISFIES generates, or that a broken user
definition generates (such as your DEFTYPE FOO example).


By the bye, on another note, I haven't seen any implementation that
has the bug Kent wondered about earlier:
     (defun bar (x) (symbolp x))
     (defun foo (x)
       (flet ((bar (y) (integerp y)))
	 (typep x '(satisfies bar))))
     (foo 'x)
    The correct answer is T, but I bet a lot of implementations return NIL
    in compiled code.
Anyone know of an implementation for which this fails?


-- JonL --

∂04-Jan-89  0537	Common-Lisp-mailer 	re: commonlisp types
Received: from crash.cs.umass.edu ([128.119.40.235]) by SAIL.Stanford.EDU with TCP; 4 Jan 89  05:37:09 PST
Received: from vax5.cs.umass.edu by crash.cs.umass.edu (5.59/Ultrix2.0-B)
	id AA05758; Wed, 4 Jan 89 08:38:09 est
Message-Id: <8901041338.AA05758@crash.cs.umass.edu>
Date: Wed, 4 Jan 89 08:37 EST
From: David Forster <FORSTER@cs.umass.EDU>
Subject: re: commonlisp types
To: common-lisp@sail.stanford.EDU
X-Vms-To: IN%"common-lisp@sail.stanford.edu"

The TI Explorer (4.2) is one of your problem cases -- it applies the flet'd
function in the `satisfies' clause, instead of the defun'd one.

∂04-Jan-89  0921	Common-Lisp-mailer 	PROG1 as a function; meta-rules of CLtL 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Jan 89  09:21:03 PST
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA04233g; Wed, 4 Jan 89 09:17:15 PST
Received: by blacksox id AA00451g; Wed, 4 Jan 89 09:19:35 pst
Date: Wed, 4 Jan 89 09:19:35 pst
From: Eric Benson <eb@lucid.com>
Message-Id: <8901041719.AA00451@blacksox>
To: barmar@Think.COM
Cc: common-lisp@sail.stanford.edu
In-Reply-To: Barry Margolin's message of Tue, 3 Jan 89 20:10 EST <19890104011056.6.BARMAR@OCCAM.THINK.COM>
Subject: PROG1 as a function; meta-rules of CLtL

   Date: Tue, 3 Jan 89 20:10 EST
   From: Barry Margolin <barmar@Think.COM>

   One of our users noticed today that Symbolics defines PROG1 as a
   function, rather than as a macro as CLtL specifies.  The definition is
   essentially

	   (defun prog1 (first-form &rest rest-forms)
	     (declare (ignore rest-forms))
	     first-form)

   This works because CL requires left-to-right evaluation of function
   arguments; it just does a bit more consing than a macro implementation
   would need to do.  

Actually, it doesn't do any more consing than the macro definition,
because &REST arguments are stack-allocated on Symbolics machines (in
generally-agreed-on violation of CLtL).  Even in Lucid's implementation
this definition would not cons, because the ignored rest argument is
never created in the first place.

		      The compiler open-codes PROG1 invocations, so this is
   only used in the interpreter.

   Does this seem valid?  The only implementation leeway CLtL mentions is
   that macros may be implemented as special forms, so long as an
   equivalent macro definition is also made available; it doesn't
   specifically mention implementing macros as functions (probably because
   the developers thought that none of them COULD be implemented as
   functions).

   I don't see how this could cause any code to fail.

						   barmar



Someone writing a cross-compiler or other codewalking tool that did
macroexpansion might be surprised that PROG1 was not expanded.  This
might not be a problem if the result were going to run in the same
environment, but it could cause trouble if it were going to be used in
an environment where PROG1 is a macro.

CLtL is silent on this topic (like many others).  It is not
explicitly prohibited, nor is it explicitly permitted.  This raises a
meta-question:  If something is not mentioned, does that mean it is
permitted, or does that mean it is prohibited?  I think it must be the
former, since CLtL defines a "core" language, which may be extended by
the implementor.  The cleanup committee has tried to fill many of
these holes, but it is impossible to deal with all of them.  It is
safe to say that ambiguities will be discovered as long as there are
prople using Common Lisp.  Here are some choice ones, in increasing
order of bizarreness:

Is it OK to define Common Lisp functions with extra optional or
keyword parameters, with system dependent meanings?  E.g. Lucid's
COMPILE-FILE has several keyword arguments not mentioned in CLtL.

Is it OK to return extra values from Common Lisp functions?

Is it OK to define the behavior of functions on datatypes not
explicitly permitted in CLtL?  For example, suppose I defined + on
vectors to do componentwise addition on the elements?  Arguments to +
"must" be numbers, meaning that it "is an error" to supply anything
other than numbers, meaning that anything can happen when you supply
arguments other than numbers.

Suppose an implementation printed
>>Attention: Taking CAR of (1 2 3)!
every time CAR was called.  I don't suppose many people would use
it, but would it be a legal Common Lisp implementation?

∂04-Jan-89  1054	Common-Lisp-mailer 	PROG1 as a function 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 4 Jan 89  10:54:47 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 515182; Wed 4-Jan-89 13:50:23 EST
Date: Wed, 4 Jan 89 13:49 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: PROG1 as a function
To: Barry Margolin <barmar@Think.COM>
cc: common-lisp@sail.stanford.edu
In-Reply-To: <19890104011056.6.BARMAR@OCCAM.THINK.COM>
Message-ID: <19890104184948.9.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Tue, 3 Jan 89 20:10 EST
    From: Barry Margolin <barmar@Think.COM>

    One of our users noticed today that Symbolics defines PROG1 as a
    function, rather than as a macro as CLtL specifies.  The definition is
    essentially

	    (defun prog1 (first-form &rest rest-forms)
	      (declare (ignore rest-forms))
	      first-form)

    This works because CL requires left-to-right evaluation of function
    arguments

CLtL is vague about the order of evaluation of function arguments.  In
chapters 5 and 7 it neither says that the order is left-to-right nor
that the order is undefined, and I suspect that the person who made
PROG1 a macro thought the order was undefined; I can't see any other
reason that it would need to be a macro.  The place in CLtL that says
that all function arguments are evaluated left-to-right is page 194,
buried in the middle of a discussion on numeric contagion.

∂04-Jan-89  1111	Common-Lisp-mailer 	PROG1 as a function 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 4 Jan 89  11:11:19 PST
Received: from NOEL-COWARD.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 515201; 4 Jan 89 14:09:38 EST
Date: Wed, 4 Jan 89 14:17 EST
From: Michael Greenwald <Greenwald@STONY-BROOK.SCRC.Symbolics.COM>
Subject: PROG1 as a function
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, barmar@Think.COM
cc: common-lisp@sail.stanford.edu
In-Reply-To: <19890104184948.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890104191710.7.GREENWALD@NOEL-COWARD.SCRC.Symbolics.COM>

    Date: Wed, 4 Jan 89 13:49 EST
    From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

	Date: Tue, 3 Jan 89 20:10 EST
	From: Barry Margolin <barmar@Think.COM>

	One of our users noticed today that Symbolics defines PROG1 as a
	function, rather than as a macro as CLtL specifies.  The definition is
	essentially

		(defun prog1 (first-form &rest rest-forms)
		  (declare (ignore rest-forms))
		  first-form)

	This works because CL requires left-to-right evaluation of function
	arguments

    CLtL is vague about the order of evaluation of function arguments.  In
    chapters 5 and 7 it neither says that the order is left-to-right nor
    that the order is undefined, and I suspect that the person who made
    PROG1 a macro thought the order was undefined; I can't see any other
    reason that it would need to be a macro.  The place in CLtL that says
    that all function arguments are evaluated left-to-right is page 194,
    buried in the middle of a discussion on numeric contagion.

Actually, CLtL pg 61 says that the arguments and parameters are
processed in order, from left to right.  I don't know if "processed"
implies "evaluated", but I always assumed (perhaps incorrectly) it did.

∂04-Jan-89  1131	Common-Lisp-mailer 	PROG1 as a function 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 4 Jan 89  11:31:24 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 515226; Wed 4-Jan-89 14:29:52 EST
Date: Wed, 4 Jan 89 14:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: PROG1 as a function
To: Michael Greenwald <Greenwald@STONY-BROOK.SCRC.Symbolics.COM>
cc: barmar@Think.COM, common-lisp@sail.stanford.edu
In-Reply-To: <19890104191710.7.GREENWALD@NOEL-COWARD.SCRC.Symbolics.COM>
Message-ID: <19890104192915.3.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Wed, 4 Jan 89 14:17 EST
    From: Michael Greenwald <Greenwald@STONY-BROOK.SCRC.Symbolics.COM>

	Date: Wed, 4 Jan 89 13:49 EST
	From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

	CLtL is vague about the order of evaluation of function arguments.

    Actually, CLtL pg 61 says that the arguments and parameters are
    processed in order, from left to right.  I don't know if "processed"
    implies "evaluated", but I always assumed (perhaps incorrectly) it did.

"Arguments" are the output from evaluation, not the input to evaluation.
Think about the case where the function was called by APPLY.

∂04-Jan-89  1252	Common-Lisp-mailer 	PROG1 as a function; meta-rules of CLtL 
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 4 Jan 89  12:51:58 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Wed, 4 Jan 89 15:06:58 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Wed, 4 Jan 89 15:48:06 EST
Date: Wed, 4 Jan 89 15:47 EST
From: Barry Margolin <barmar@Think.COM>
Subject: PROG1 as a function; meta-rules of CLtL
To: Eric Benson <eb@lucid.com>
Cc: common-lisp@sail.stanford.edu
In-Reply-To: <8901041719.AA00451@blacksox>
Message-Id: <19890104204747.1.BARMAR@OCCAM.THINK.COM>

    Date: Wed, 4 Jan 89 09:19:35 pst
    From: Eric Benson <eb@lucid.com>

       Date: Tue, 3 Jan 89 20:10 EST
       From: Barry Margolin <barmar@Think.COM>

       One of our users noticed today that Symbolics defines PROG1 as a
       function, rather than as a macro as CLtL specifies.  The definition is
       essentially

	       (defun prog1 (first-form &rest rest-forms)
		 (declare (ignore rest-forms))
		 first-form)

       This works because CL requires left-to-right evaluation of function
       arguments; it just does a bit more consing than a macro implementation
       would need to do.  

    Actually, it doesn't do any more consing than the macro definition,
    because &REST arguments are stack-allocated on Symbolics machines (in
    generally-agreed-on violation of CLtL).  Even in Lucid's implementation
    this definition would not cons, because the ignored rest argument is
    never created in the first place.

True.  I didn't realize that EVAL consed the arguments on the stack (I
thought only compiled code did it). 

    Is it OK to define Common Lisp functions with extra optional or
    keyword parameters, with system dependent meanings?  E.g. Lucid's
    COMPILE-FILE has several keyword arguments not mentioned in CLtL.

    Is it OK to return extra values from Common Lisp functions?

    Is it OK to define the behavior of functions on datatypes not
    explicitly permitted in CLtL?  For example, suppose I defined + on
    vectors to do componentwise addition on the elements?  Arguments to +
    "must" be numbers, meaning that it "is an error" to supply anything
    other than numbers, meaning that anything can happen when you supply
    arguments other than numbers.

Those of us in X3J13 have been thinking about this general problem for
several years, but there still isn't a clear concensus.  I believe that
it was the original intent of the CL designers that implementations be
permitted to do many of these things.  Anything that "is an error" is a
potential place for extension.  Symbolics has done all of the above.

Adding optional parameters or returning extra values is usually safe.
Programs can get in trouble, though, if they use multiple-value-list or
multiple-value-call with functions that have been extended in such ways.
For instance, (multiple-value-call #'cons (floor x y)) looks portable,
but it will try to pass the wrong number of arguments to CONS if FLOOR
returns an extra value.

    Suppose an implementation printed
    >>Attention: Taking CAR of (1 2 3)!
    every time CAR was called.  I don't suppose many people would use
    it, but would it be a legal Common Lisp implementation?

This is something I remember Kent Pitman bringing up a long time ago,
under the general topic of automatic output.  The above is obviously an
extreme case, but there are realistic analogues, such as GC
notifications, autoload heralds, and progress messages from COMPILE-FILE
or LOAD.  Since we weren't sure how to tackle these, we've generally
dismissed them as "environment" features, which CL generally doesn't
address.

                                                barmar

∂04-Jan-89  1328	Common-Lisp-mailer 	PROG1 as a function 
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 4 Jan 89  13:28:19 PST
Received: from fafnir.think.com by Think.COM; Wed, 4 Jan 89 15:44:14 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 4 Jan 89 16:25:37 EST
Received: by verdi.think.com; Wed, 4 Jan 89 16:23:48 EST
Date: Wed, 4 Jan 89 16:23:48 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8901042123.AA10344@verdi.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: barmar@Think.COM, common-lisp@sail.stanford.edu
In-Reply-To: David A. Moon's message of Wed, 4 Jan 89 13:49 EST <19890104184948.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: PROG1 as a function

   Date: Wed, 4 Jan 89 13:49 EST
   From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>

       Date: Tue, 3 Jan 89 20:10 EST
       From: Barry Margolin <barmar@Think.COM>

       One of our users noticed today that Symbolics defines PROG1 as a
       function, rather than as a macro as CLtL specifies.  The definition is
       essentially

	       (defun prog1 (first-form &rest rest-forms)
		 (declare (ignore rest-forms))
		 first-form)

       This works because CL requires left-to-right evaluation of function
       arguments

   CLtL is vague about the order of evaluation of function arguments.  In
   chapters 5 and 7 it neither says that the order is left-to-right nor
   that the order is undefined, and I suspect that the person who made
   PROG1 a macro thought the order was undefined; I can't see any other
   reason that it would need to be a macro.  The place in CLtL that says
   that all function arguments are evaluated left-to-right is page 194,
   buried in the middle of a discussion on numeric contagion.

Sigh.  Unfortunately, I must beg to differ.  I read the passage on page 194
as requiring only that the fully evaluated arguments be processed
left-to-right for contagion purposes.  This is not the same as requiring
that argument forms in a call be evaluated left-to-right.

-- Guy

∂04-Jan-89  1333	Common-Lisp-mailer 	PROG1 as a function 
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 4 Jan 89  13:29:47 PST
Received: from fafnir.think.com by Think.COM; Wed, 4 Jan 89 15:46:00 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 4 Jan 89 16:27:29 EST
Received: by verdi.think.com; Wed, 4 Jan 89 16:25:43 EST
Date: Wed, 4 Jan 89 16:25:43 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8901042125.AA10347@verdi.think.com>
To: Greenwald@stony-brook.scrc.symbolics.com
Cc: Moon@stony-brook.scrc.symbolics.com, barmar@Think.COM,
        common-lisp@sail.stanford.edu
In-Reply-To: Michael Greenwald's message of Wed, 4 Jan 89 14:17 EST <19890104191710.7.GREENWALD@NOEL-COWARD.SCRC.Symbolics.COM>
Subject: PROG1 as a function

   Date: Wed, 4 Jan 89 14:17 EST
   From: Michael Greenwald <Greenwald@stony-brook.scrc.symbolics.com>

       Date: Wed, 4 Jan 89 13:49 EST
       From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>

	   Date: Tue, 3 Jan 89 20:10 EST
	   From: Barry Margolin <barmar@Think.COM>

	   One of our users noticed today that Symbolics defines PROG1 as a
	   function, rather than as a macro as CLtL specifies.  The definition is
	   essentially

		   (defun prog1 (first-form &rest rest-forms)
		     (declare (ignore rest-forms))
		     first-form)

	   This works because CL requires left-to-right evaluation of function
	   arguments

       CLtL is vague about the order of evaluation of function arguments.  In
       chapters 5 and 7 it neither says that the order is left-to-right nor
       that the order is undefined, and I suspect that the person who made
       PROG1 a macro thought the order was undefined; I can't see any other
       reason that it would need to be a macro.  The place in CLtL that says
       that all function arguments are evaluated left-to-right is page 194,
       buried in the middle of a discussion on numeric contagion.

   Actually, CLtL pg 61 says that the arguments and parameters are
   processed in order, from left to right.  I don't know if "processed"
   implies "evaluated", but I always assumed (perhaps incorrectly) it did.

I interpret this as referring to how the (fully evaluated) arguments
are processed during lambda-binding, not to the order in which argument
forms in a function call are evaluated.  After all, the arguments referred
to on page 61 might have come from a list given to APPLY, rather then
from EVAL on a function call.

--Guy

∂04-Jan-89  1337	Common-Lisp-mailer 	PROG1 as a function 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Jan 89  13:37:19 PST
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA04590g; Wed, 4 Jan 89 13:32:41 PST
Received: by blacksox id AA00501g; Wed, 4 Jan 89 13:34:57 pst
Date: Wed, 4 Jan 89 13:34:57 pst
From: Eric Benson <eb@lucid.com>
Message-Id: <8901042134.AA00501@blacksox>
To: gls@Think.COM
Cc: Moon@stony-brook.scrc.symbolics.com, barmar@Think.COM,
        common-lisp@sail.stanford.edu
In-Reply-To: Guy Steele's message of Wed, 4 Jan 89 16:23:48 EST <8901042123.AA10344@verdi.think.com>
Subject: PROG1 as a function

   Date: Wed, 4 Jan 89 16:23:48 EST
   From: Guy Steele <gls@Think.COM>

   Sigh.  Unfortunately, I must beg to differ.  I read the passage on page 194
   as requiring only that the fully evaluated arguments be processed
   left-to-right for contagion purposes.  This is not the same as requiring
   that argument forms in a call be evaluated left-to-right.

   -- Guy


Maybe you're looking at the wrong passage.  This looks pretty
unambiguous to me.  It's also the only place in CLtL that says
argument evaluation is always left-to-right:

"For functions that are mathematically associative (and possibly
commutative), a Common Lisp implementation may process the arguments
in any manner consistent with associative (and possibly commutative)
rearrangement.  This does not affect the order in which the argument
forms are evaluated, of course; that order is always left-to-right, as
in all Common Lisp function calls.  What is left loose is the order in
which the argument values are processed."

∂04-Jan-89  1354	Common-Lisp-mailer 	Re: PROG1 as a function; meta-rules of CLtL  
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 4 Jan 89  13:54:26 PST
Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef)
	id AA07451; Wed, 4 Jan 89 16:53:07 EST
Received: from localhost by mist. (4.0/SMI-4.0)
	id AA14516; Wed, 4 Jan 89 16:53:06 EST
Message-Id: <8901042153.AA14516@mist.>
To: Barry Margolin <barmar@Think.COM>
Cc: Eric Benson <eb@lucid.com>, common-lisp@sail.stanford.edu
Subject: Re: PROG1 as a function; meta-rules of CLtL 
In-Reply-To: Your message of Wed, 04 Jan 89 15:47:00 -0500.
             <19890104204747.1.BARMAR@OCCAM.THINK.COM> 
Date: Wed, 04 Jan 89 16:53:00 EST
From: Dan L. Pierson <pierson@mist.encore.com>

    Date: Wed, 4 Jan 89 15:47 EST
    From: Barry Margolin <barmar@Think.COM>
    
        Date: Wed, 4 Jan 89 09:19:35 pst
        From: Eric Benson <eb@lucid.com>
    
        Is it OK to define Common Lisp functions with extra optional or
        keyword parameters, with system dependent meanings?  E.g. Lucid's
        COMPILE-FILE has several keyword arguments not mentioned in CLtL.
    
        Is it OK to return extra values from Common Lisp functions?
    
        Is it OK to define the behavior of functions on datatypes not
        explicitly permitted in CLtL?  For example, suppose I defined + on
        vectors to do componentwise addition on the elements?  Arguments to +
        "must" be numbers, meaning that it "is an error" to supply anything
        other than numbers, meaning that anything can happen when you supply
        arguments other than numbers.
    
    Those of us in X3J13 have been thinking about this general problem for
    several years, but there still isn't a clear concensus.  I believe that
    it was the original intent of the CL designers that implementations be
    permitted to do many of these things.  Anything that "is an error" is a
    potential place for extension.  Symbolics has done all of the above.
    
    Adding optional parameters or returning extra values is usually safe.

I have to disagree.  Adding new keyword parameters is fairly safe,
since a new version of the Common Lisp standard would have to use that
exact keyword name in an incompatible way to cause a problem.  However
adding a new optional parameter guarantees that any new standard which
adds a new optional or required parameter to the form will cause
trouble (unless, of course, the change in the standard was to adopt
the implementation extension in question).  Since the Common Lisp
standard is (and will be, I hope) created by consensus as much as
possible, the most likely effect of such an implementation extension
is to restrict the options of any new standard.  I would personally
encourage implementations to make any additions to Common Lisp forms
via new keyword arguments rather than optional arguments; I hope that
the final X3J13 standard will specify this.

Returning extra values is a harder problem.  It causes the same
problems as new optional arguments, but there is more likely to be no
reasonable alternative.

∂04-Jan-89  1414	Common-Lisp-mailer 	PROG1 as a function 
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 4 Jan 89  14:13:58 PST
Received: from fafnir.think.com by Think.COM; Wed, 4 Jan 89 16:16:10 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Wed, 4 Jan 89 16:57:36 EST
Received: by verdi.think.com; Wed, 4 Jan 89 16:55:50 EST
Date: Wed, 4 Jan 89 16:55:50 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8901042155.AA10486@verdi.think.com>
To: eb@lucid.com
Cc: gls@Think.COM, Moon@stony-brook.scrc.symbolics.com, barmar@Think.COM,
        common-lisp@sail.stanford.edu
In-Reply-To: Eric Benson's message of Wed, 4 Jan 89 13:34:57 pst <8901042134.AA00501@blacksox>
Subject: PROG1 as a function

   Date: Wed, 4 Jan 89 13:34:57 pst
   From: Eric Benson <eb@lucid.com>

      Date: Wed, 4 Jan 89 16:23:48 EST
      From: Guy Steele <gls@Think.COM>

      Sigh.  Unfortunately, I must beg to differ.  I read the passage on page 194
      as requiring only that the fully evaluated arguments be processed
      left-to-right for contagion purposes.  This is not the same as requiring
      that argument forms in a call be evaluated left-to-right.

      -- Guy


   Maybe you're looking at the wrong passage.  This looks pretty
   unambiguous to me.  It's also the only place in CLtL that says
   argument evaluation is always left-to-right:

   "For functions that are mathematically associative (and possibly
   commutative), a Common Lisp implementation may process the arguments
   in any manner consistent with associative (and possibly commutative)
   rearrangement.  This does not affect the order in which the argument
   forms are evaluated, of course; that order is always left-to-right, as
   in all Common Lisp function calls.  What is left loose is the order in
   which the argument values are processed."

Ooops.  Sorry.  I was wedged and looking in the wrong place.

"Never mind."

--Guy

∂06-Jan-89  1346	Common-Lisp-mailer 	commonlisp types    
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 6 Jan 89  13:46:18 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.Dialnet.Symbolics.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 306345; 6 Jan 89 15:57:47 EST
Received: from CALVARY.ILA.Dialnet.Symbolics.COM by F.ILA.Dialnet.Symbolics.COM via CHAOS with CHAOS-MAIL id 7603; Fri 6-Jan-89 15:33:07 EST
Date: Fri, 6 Jan 89 15:33 EST
From: Robert W. Kerns <RWK@FUJI.ILA.Dialnet.Symbolics.COM>
Subject: commonlisp types
To: gls%Think.COM@Riverside.Symbolics.COM, jwz%spice.cs.cmu.edu@Riverside.SCRC.Symbolics.COM,
    common-lisp%sail.stanford.edu@Riverside.SCRC.Symbolics.COM
In-Reply-To: <881222151736.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Supersedes: <19890103102924.8.RWK@F.ILA.Dialnet.Symbolics.COM>
Comments: Retransmission of failed mail.
Message-ID: <19890106203322.2.RWK@CALVARY.ILA.Dialnet.Symbolics.COM>

    Date: Thu, 22 Dec 88 15:17 EST
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
    Fyi, it turns out this rationale doesn't hold as much water as you'd think.
    Consider:

     (defun bar (x) (symbolp x))

     (defun foo (x)
       (flet ((bar (y) (integerp y)))
	 (typep x '(satisfies bar))))

     (foo 'x)

    The correct answer is T, but I bet a lot of implementations return NIL
    in compiled code.

Like the Symbolics system, Boo, Hiss!

In terms of source transformations, this would have to compile the TYPEP
as follows:

(defun foo (x)
  (flet ((bar (y) (integerp y)))
    (let ((#:G0002 x))
      (macrolet ((bar (a) `(funcall (symbol-function 'bar) ,a)))
        (bar #:G0002)))))

Which is obviously going to require either a codewalker or a typewalker
to identify either locally defined functions or functions used in the
type expansion to shadow with MACROLET.

So I'm curious.  Does any compiler actually get this right?  Really,
this is a general problem with any form of source-code rewrites.  The
Symbolics compiler does get this right with inlined functions, but I'll
bet it doesn't with some other internal in-lined things that work as
source transformations.

∂06-Jan-89  1346	Common-Lisp-mailer 	commonlisp types    
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 6 Jan 89  13:46:18 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.Dialnet.Symbolics.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 306344; 6 Jan 89 15:56:48 EST
Received: from CALVARY.ILA.Dialnet.Symbolics.COM by F.ILA.Dialnet.Symbolics.COM via CHAOS with CHAOS-MAIL id 7601; Fri 6-Jan-89 15:15:53 EST
Date: Fri, 6 Jan 89 15:16 EST
From: Robert W. Kerns <RWK@FUJI.ILA.Dialnet.Symbolics.COM>
Subject: commonlisp types
To: Jon L White <jonl%lucid.com@Riverside.SCRC.Symbolics.Com>
cc: common-lisp%sail.stanford.edu@Riverside.SCRC.Symbolics.Com
In-Reply-To: <8901040858.AA01403@bhopal>
Message-ID: <19890106201603.1.RWK@CALVARY.ILA.Dialnet.Symbolics.COM>

    Date: Wed, 4 Jan 89 00:58:57 PST
    From: Jon L White <jonl@lucid.com>

    re: How do you define "valid type specifier"?

    Very syntactically.  I think its perfectly acceptable to have a set
    of combination rules for making "words" in the type-specifier syntax,
    even though some such "words" would be gibberish.

    The important thing is that base-level types -- those defined in 
    CLtL -- along with DEFSTRUCT extensions be recognizable.  They don't
    have the problems that SATISFIES generates, or that a broken user
    definition generates (such as your DEFTYPE FOO example).

I'm not saying there's a fundamental problem here, just that there's a choice
to be made, and that writing precise and understandable definitions is
non-trivial.  I'd like to encourage you to make YOUR definition explicit for
us, as a starting point.

    By the bye, on another note, I haven't seen any implementation that
    has the bug Kent wondered about earlier:
	 (defun bar (x) (symbolp x))
	 (defun foo (x)
	   (flet ((bar (y) (integerp y)))
	     (typep x '(satisfies bar))))
	 (foo 'x)
	The correct answer is T, but I bet a lot of implementations return NIL
	in compiled code.
    Anyone know of an implementation for which this fails?

Yes, Symbolics.  You must have missed my query about any implementations
for which it succeeds!  Any implementation which does source-rewriting
to optimize TYPEP has to concern itself with this issue.  (The issue is the
same as for doing INLINEing, but Symbolics fails to use the same mechanism for
optimizations as it does for inlining.)

∂06-Jan-89  2112	Common-Lisp-mailer 	Re: commonlisp types     
Received: from cayuga.cs.rochester.edu (CS.ROCHESTER.EDU) by SAIL.Stanford.EDU with TCP; 6 Jan 89  21:11:52 PST
Received: from lesath.cs.rochester.edu by cayuga.cs.rochester.edu (5.59/k) id AA09897; Fri, 6 Jan 89 20:12:20 EST
Received: from loopback by lesath.cs.rochester.edu (3.2/k) id AA09737; Fri, 6 Jan 89 20:12:14 EST
Message-Id: <8901070112.AA09737@lesath.cs.rochester.edu>
To: common-lisp@sail.stanford.edu
Subject: Re: commonlisp types 
In-Reply-To: Your message of Fri, 06 Jan 89 15:33:00 -0500.
             <19890106203322.2.RWK@CALVARY.ILA.Dialnet.Symbolics.COM> 
Date: Fri, 06 Jan 89 20:12:09 -0500
From: quiroz@cs.rochester.edu


: So I'm curious.  Does any compiler actually get this right?

KCL.  See script at the end of this message.

BTW, our mailer didn't like the address
    Robert W. Kerns <RWK@FUJI.ILA.Dialnet.Symbolics.COM>
on the excuse that FUJI.ILA.Dialnet.Symbolics.COM is an unknown host.

Cesar

KCl (Kyoto Common Lisp)  June 3, 1987
--- UofR version of September 9, 1988
Loading /u/quiroz/.kclrc
Loading /u/quiroz/work/kcl/defsys/defsys.o
Finished loading /u/quiroz/work/kcl/defsys/defsys.o
Finished loading /u/quiroz/.kclrc

>     (defun bar (x) (symbolp x))
bar

>     (defun foo (x)
       (flet ((bar (y) (integerp y)))
	 (typep x '(satisfies bar))))
foo

>     (foo 'x)
t

>(compile 'bar)
End of Pass 1.  
End of Pass 2.  
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
bar

>(compile 'foo)
End of Pass 1.  
End of Pass 2.  
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
foo

>(foo 'x)
t

>

∂07-Jan-89  0054	Common-Lisp-mailer 	commonlisp types    
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 7 Jan 89  00:54:42 PST
Received: from LUCID.COM by Riverside.SCRC.Symbolics.COM via INTERNET with SMTP id 306559; 7 Jan 89 03:53:00 EST
Received: from bhopal ([192.9.200.13]) by heavens-gate id AA08351g; Sat, 7 Jan 89 00:50:24 PST
Received: by bhopal id AA02943g; Sat, 7 Jan 89 00:52:38 PST
Date: Sat, 7 Jan 89 00:52:38 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901070852.AA02943@bhopal>
To: RWK@FUJI.ILA.Dialnet.Symbolics.COM
Cc: jonl%lucid.com@Riverside.SCRC.Symbolics.Com,
        common-lisp%sail.stanford.edu@Riverside.SCRC.Symbolics.Com
In-Reply-To: Robert W. Kerns's message of Fri, 6 Jan 89 15:16 EST <19890106201603.1.RWK@CALVARY.ILA.Dialnet.Symbolics.COM>
Subject: commonlisp types

re: [TYPE-SPECIFIER-P] I'd like to encourage you to make YOUR definition 
    explicit for us, as a starting point.

Well, what I can tell you in reasonable terms won't be that helpful. We
simpy hook in to the part of SUBTYPEP that has to resolve these questions,
and "catch" any signals about unrecognized types.  For symbols, the
question of a recognized type is fairly easy -- there's a list in CLtL
of some basic types, and then there's more basic types coming from
DEFSTRUCT, and finally there's "recursion" via DEFTYPE.  Can you think
of an easier answer for this?


re:     Anyone know of an implementation for which this fails?
    Yes, Symbolics.  You must have missed my query about any implementations
    for which it succeeds!  Any implementation which does source-rewriting
    to optimize TYPEP has to concern itself with this issue.  (The issue is the
    same as for doing INLINEing, but Symbolics fails to use the same mechanism
    for optimizations as it does for inlining.)

Lucid succeeds (and one or two others that I tried).  Oddly enough, Lucid
also "fails" to use the same mechanism for compiler optimizers as it does
for INLINEing -- and it gets the optimizations right, but certain cases
of lexical inlining screws wrong.


-- JonL --

∂10-Jan-89  0756	Common-Lisp-mailer 	Character proposal  
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 10 Jan 89  07:56:38 PST
Date: Mon, 09 Jan 89 19:50:46 PST
From: Thom Linden <baggins@ibm.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <890109.195046.baggins@IBM.com>
Subject: Character proposal

The revised proposal should be transmitted fairly soon.  Due to this
delay, I won't be asking for a vote unless J13 agrees it is ready.
The content of the scheduled time for characters will be to
review the substantial changes.

I will bring copies to the meeting as well as send over the network.

Regards,
  Thom

∂10-Jan-89  0930	Common-Lisp-mailer 	Re: commonlisp types     
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 10 Jan 89  09:30:06 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.Dialnet.Symbolics.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 307284; 10 Jan 89 12:28:11 EST
Date: Mon, 9 Jan 89 21:42 EST
From: Robert W. Kerns <RWK@F.ILA.Dialnet.Symbolics.COM>
Subject: Re: commonlisp types 
To: quiroz%cs.rochester.edu@RIVERSIDE.SCRC.SYMBOLICS.COM, common-lisp%sail.stanford.edu@RIVERSIDE.SCRC.SYMBOLICS.COM
In-Reply-To: <8901070112.AA09737@lesath.cs.rochester.edu>
Message-ID: <19890110024213.3.RWK@F.ILA.Dialnet.Symbolics.COM>

    Date: Fri, 06 Jan 89 20:12:09 -0500
    From: quiroz@cs.rochester.edu


    : So I'm curious.  Does any compiler actually get this right?

    KCL.  See script at the end of this message.

OK, next question:  Does it open-code or otherwise optimize TYPEP, or
just call TYPEP on the list?

If you don't know, I'll check it next time I use KCL (which will be
*after* X3J13).

    BTW, our mailer didn't like the address
	Robert W. Kerns <RWK@FUJI.ILA.Dialnet.Symbolics.COM>
    on the excuse that FUJI.ILA.Dialnet.Symbolics.COM is an unknown host.

"It's not my PLANET, Monkey Boy!"
  -- John Wharten (villan from Buckaroo Bonzai)

As a workaround, you can use

RWK%FUJI.ILA.Dialnet.Symbolics.Com@Riverside.SCRC.Symbolics.Com

which is essentially what I have to do to send to you.

Or you can use RWK@AI.AI.MIT.Edu, which forwards to the same place.

∂12-Jan-89  0427	Common-Lisp-mailer 	Re: commonlisp types     
Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 12 Jan 89  04:27:20 PST
Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.Dialnet.Symbolics.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 307893; 12 Jan 89 06:41:54 EST
Date: Thu, 12 Jan 89 06:09 EST
From: Robert W. Kerns <RWK@F.ILA.Dialnet.Symbolics.COM>
Subject: Re: commonlisp types 
To: Robert W. Kerns <RWK@F.ILA.Dialnet.Symbolics.COM>, quiroz%cs.rochester.edu@RIVERSIDE.SCRC.SYMBOLICS.COM,
    common-lisp%sail.stanford.edu@RIVERSIDE.SCRC.SYMBOLICS.COM
In-Reply-To: <19890110024213.3.RWK@F.ILA.Dialnet.Symbolics.COM>
Message-ID: <19890112110920.0.RWK@F.ILA.Dialnet.Symbolics.COM>

    Date: Mon, 9 Jan 89 21:42 EST
    From: Robert W. Kerns <RWK@F.ILA.Dialnet.Symbolics.COM>
	BTW, our mailer didn't like the address
	    Robert W. Kerns <RWK@FUJI.ILA.Dialnet.Symbolics.COM>
	on the excuse that FUJI.ILA.Dialnet.Symbolics.COM is an unknown host.

    "It's not my PLANET, Monkey Boy!"
      -- John Wharten (villan from Buckaroo Bonzai)

Sumimasen, ga... I think that's supposed to be "Wharfin" or something.

∂12-Jan-89  0949	Common-Lisp-mailer 	Order of "processing" of arguments 
Received: from ATHENA.CS.YALE.EDU by SAIL.Stanford.EDU with TCP; 12 Jan 89  09:49:45 PST
Received: by ATHENA.CS.YALE.EDU; Thu, 12 Jan 89 12:49:19 EST
Date: Thu, 12 Jan 89 12:49:19 EST
From: Bruce Krulwich <krulwich-bruce@YALE.ARPA>
Full-Name: Bruce Krulwich
Message-Id: <8901121749.AA18587@ATHENA.CS.YALE.EDU>
Received: by yale-hp-crown (szechuan) 
          via WIMP-MAIL (Version 1.3/1.5) ; Thu Jan 12 12:51:16
To: Common-Lisp@SAIL.Stanford.EDU
Subject: Order of "processing" of arguments
Newsgroups: arpa.common-lisp
In-Reply-To: <46940@yale-celray.yale.UUCP>
Organization: Computer Science, Yale University, New Haven, CT 06520-2158

Michael Greenwald said:
>Actually, CLtL pg 61 says that the arguments and parameters are
>processed in order, from left to right.  I don't know if "processed"
>implies "evaluated", but I always assumed (perhaps incorrectly) it did.

Guy Steele replied:
>I interpret this as referring to how the (fully evaluated) arguments
>are processed during lambda-binding, not to the order in which argument
>forms in a function call are evaluated.  After all, the arguments referred
>to on page 61 might have come from a list given to APPLY, rather then
>from EVAL on a function call.

This seems vacuous to me.  Does this mean that an implementation in which a
procedure entry point knows how many arguments its receiving (through a link
table, for instance, or simply by counting its arguments) and constructs a
REST-arg list before doing the binding of the required args is in violation of
CLtL because it processes the rightmost argument before the leftmost one??  I
hope not.

It seems to me that as long as actuals and formals are matched up correctly
there is no reason for the language specification to specify the order of the
"processing" of the arguments during lambda-binding.


Bruce Krulwich
krulwich@cs.yale.edu


∂12-Jan-89  1245	Common-Lisp-mailer 	Logical Operations on Numbers 
Received: from crash.cs.umass.edu ([128.119.40.235]) by SAIL.Stanford.EDU with TCP; 12 Jan 89  12:45:18 PST
Received: from vax3.cs.umass.edu by crash.cs.umass.edu (5.59/Ultrix2.0-B)
	id AA00579; Thu, 12 Jan 89 15:46:00 est
Message-Id: <8901122046.AA00579@crash.cs.umass.edu>
Date: Thu, 12 Jan 89 15:31 EST
From: ELIOT@cs.umass.EDU
Subject: Logical Operations on Numbers
To: common-lisp@sail.stanford.EDU
X-Vms-To: IN%"common-lisp@sail.stanford.EDU"

Section 12.7 (pp 220-225) describes CL operations for manipulating
finite sets using integers.  Unfortunately there does not seem to
be any predicate to determine if one set is a subset of another
using this representation.  'logtest' serves as an intersection test,
'logbitp' serves as a member test but to determine subset relations
seems to require computing the set difference (with logandc2) and
comparing the result with zero.  If the sets are moderately large
(say several hundred elements) this involves expensive bignum operations
that I would like to avoid.

I have also thought of using bitvectors, but the operations on bitvectors
(p 294) only operate on bitvectors of the same length.  Furthermore,
the bitvector functions only include bitwise operations, but no subset
test here either.

Isn't SUBSET considered an important set manipulation primitive?

Chris Eliot
University of Massashusetts at Amherst

∂12-Jan-89  1325	Common-Lisp-mailer 	argument processing 
Received: from crash.cs.umass.edu ([128.119.40.235]) by SAIL.Stanford.EDU with TCP; 12 Jan 89  13:25:08 PST
Received: from vax3.cs.umass.edu by crash.cs.umass.edu (5.59/Ultrix2.0-B)
	id AA00629; Thu, 12 Jan 89 16:25:58 est
Message-Id: <8901122125.AA00629@crash.cs.umass.edu>
Date: Thu, 12 Jan 89 16:19 EST
From: MURRAY@cs.umass.EDU
Subject: argument processing
To: common-lisp@sail.stanford.EDU
X-Vms-To: IN%"common-lisp@sail.stanford.EDU"

Subj:	Order of "processing" of arguments
To: Common-Lisp@SAIL.Stanford.EDU

> From: Bruce Krulwich <krulwich-bruce@YALE.ARPA>
> ...
> It seems to me that as long as actuals and formals are matched up correctly
> there is no reason for the language specification to specify the order of the
> "processing" of the arguments during lambda-binding.

The order of processing of lambda-binding is important, because
&optional or &key parameters can have code that is executed if their arguments
are not supplied in a call.  By specifying the left-right order of processing,
it defines that any arguments bound "on the left" are accessable to code
executed "on the right".

Kelly Murray


∂12-Jan-89  1331	Common-Lisp-mailer 	Logical Operations on Numbers 
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Jan 89  13:31:37 PST
Received: from GROUSE.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 520433; Thu 12-Jan-89 16:29:56 EST
Date: Thu, 12 Jan 89 16:29 EST
From: Robert A. Cassels <Cassels@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Logical Operations on Numbers
To: ELIOT@cs.umass.EDU, common-lisp@sail.stanford.EDU
In-Reply-To: <8901122046.AA00579@crash.cs.umass.edu>
Message-ID: <19890112212955.5.CASSELS@GROUSE.SCRC.Symbolics.COM>

    Date: Thu, 12 Jan 89 15:31 EST
    From: ELIOT@cs.umass.EDU

    Section 12.7 (pp 220-225) describes CL operations for manipulating
    finite sets using integers.  Unfortunately there does not seem to
    be any predicate to determine if one set is a subset of another
    using this representation.  'logtest' serves as an intersection test,
    'logbitp' serves as a member test but to determine subset relations
    seems to require computing the set difference (with logandc2) and
    comparing the result with zero.  If the sets are moderately large
    (say several hundred elements) this involves expensive bignum operations
    that I would like to avoid.

One can imagine a compiler noticing the pattern (LOGTEST .. (LOGNOT ..))
and compiling a call to a special routine which didn't do the explicit
LOGNOT computation.  I don't know of any compiler which does this,
though.

    I have also thought of using bitvectors, but the operations on bitvectors
    (p 294) only operate on bitvectors of the same length.

For vectors, it's not too hard to imagine that the shorter one should be
treated as if it were extended with zeros (presumably at the higher
index end).  It's a little harder to decide what to do in the
multidimensional case.

							    Furthermore,
    the bitvector functions only include bitwise operations, but no subset
    test here either.

    Isn't SUBSET considered an important set manipulation primitive?

    Chris Eliot
    University of Massashusetts at Amherst

Symbolics Common Lisp defines:

  SCL:BIT-VECTOR-SUBSET-P - Function (BIT-VECTOR-1 BIT-VECTOR-2 &key (:START1 0) :END1 (:START2 0) :END2)
   ;; BIT-VECTOR-1 is a subset of BIT-VECTOR-2
  SCL:BIT-VECTOR-POSITION - Function (BIT BIT-VECTOR &key (:START 0) :END)
   ;; equivalent to (POSITION BIT BIT-VECTOR :START START :END END)
  SCL:BIT-VECTOR-ZERO-P - Function (BIT-VECTOR &key (:START 0) :END)
  SCL:BIT-VECTOR-EQUAL - Function (BIT-VECTOR-1 BIT-VECTOR-2 &key (:START1 0) :END1 (:START2 0) :END2)
   ;; equivalent to (EQUAL (SUBSEQ BIT-VECTOR-1 :START START1 :END END1)
   ;;                      (SUBSEQ BIT-VECTOR-2 :START START2 :END END2))
  SCL:BIT-VECTOR-DISJOINT-P - Function (BIT-VECTOR-1 BIT-VECTOR-2 &key (:START1 0) :END1 (:START2 0) :END2)
  SCL:BIT-VECTOR-CARDINALITY - Function (BIT-VECTOR &key (:START 0) :END)
   ;; counts the "1" bits

At the present time, -SUBSET-P, -EQUAL, and -DISJOINT-P all return NIL
if the vectors have different lengths.

A more CL-consistent way of doing cardinality is probably by analogy
with the COUNT function:
  BIT-VECTOR-COUNT - Function (BIT BIT-VECTOR &key (:START 0) :END)
   ;; equivalent to (COUNT BIT BIT-VECTOR :START START :END END)

∂12-Jan-89  1956	Common-Lisp-mailer 	cs proposal part 1  
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89  19:54:57 PST
Date: Thu, 12 Jan 89 13:33:25 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <890112.133325.baggins@almvma>
Subject: cs proposal part 1

\documentstyle{report}     % Specifies the document style.

\pagestyle{headings}

\title{\bf
Extensions to Common LISP to Support International
Character Sets}
\author{
Michael Beckerle\thanks{Gold Hill Computers} \and
Paul Beiser\thanks{Hewlett-Packard} \and
Robert Kerns\thanks{Independent consultant} \and
Kevin Layer\thanks{Franz, Inc.} \and
Thom Linden\thanks{IBM Research, Subcommittee Chair} \and
Larry Masinter\thanks{Xerox Research} \and
David Unietis\thanks{Lucid, Inc.}
}
\date{January 1, 1989}   % Deleting this command produces today's date.

\begin{document}

\maketitle                 % Produces the title.

\setcounter{secnumdepth}{4}

\setcounter{tocdepth}{4}
\tableofcontents


%----------------------------------------------------------------------
%----------------------------------------------------------------------
\newfont{\cltxt}{cmr10}
\newfont{\clkwd}{cmtt10}

\newcommand{\apostrophe}{\clkwd '}
\newcommand{\bq}{\clkwd\symbol{'22}}


%----------------------------------------------------------------------
%----------------------------------------------------------------------
\chapter{Introduction}

This is a proposal to the X3 J13 committee
for both extending and modifying the Common LISP
language definition to provide a standard basis for Common LISP
support of the variety of characters used to represent the
native languages of the international community.

This proposal was created by the Character Subcommittee of X3 J13.
We would like to acknowledge discussions with T. Yuasa and other
members of the JIS Technical Working Group,
comments from members of X3 J13,
and the proposals \cite{ida87},
\cite{linden87}, \cite{kerns87}, and \cite{kurokawa88} for
providing the motivation and direction for these extensions.
As all these documents and discussions were created
expressly for LISP standardization usage,
we have borrowed freely from their ideas as well as the texts
themselves.

This document is separated into three parts. The first part explains the
major language changes and their motivations. While intended as
commentary to a general audience, and not explicitly as
part of the standard document, the X3 J13 editor may
include sections at her/his discretion.  The second part,
Appendix A, provides
the page by page set of editorial changes to \cite{steele84}.
The final part, Appendix B, contains language elements deleted
from \cite{steele84} which we view as important from a compatibility
viewpoint but consider deprecated Common LISP features.
\section{Objectives}

The major objectives of this proposal are:
\begin{itemize}
\item To provide a consistent, well-defined scheme allowing support
of both very large character sets and multiple character sets.
\footnote{The distinction between the terms {\em character repertoire}
and {\em coded character set} is made later.  The usage
of the term {\em character set},
avoided after this introduction, encompasses both terms.}

Many software applications are intended for international use, or
have requirements for incorporation of language elements of multiple
native languages within a single application.
Also, many applications require specialized languages including,
for example, scientific and typesetting symbols.
In order
to ensure some portability of these applications, data expressed in
a mixture of these
languages must be treated uniformly by the
software language.

All character and string manipulations should operate uniformly,
regardless of the character set(s) of the character objects.
This applies to array indexing, readtable definitions, read
symbol construction and I/O operations.


\item To ensure efficient performance of string and character
operations.

Many native
languages, such as Japanese and Chinese, use character
sets which contain more characters than the Latin alphabet.
Supporting larger sized character sets frequently means employing
larger data fields to uniquely encode each character.
Common LISP implementations using
larger sized character sets can
incur performance penalties in terms
of space, time, or both.

The use of large and/or multiple character sets by an
implementation
implies the need for a more complex character type representation.
Given a more complex character representation, the efficiency
of language operations on characters (e.g. string operations)
could be affected.

\item To assure forward compatibility of the proposed model
and definition with existing Common LISP implementations.

Developers should not be required to re-write large amounts of either
LISP code or data representations in order to apply the proposed
changes to existing implementations.
The proposed changes should provide an easy
portability path for existing code to many possible implementations.
\end{itemize}

There are a number of issues, some under the general rubric of
internationalization, which this proposal does {\em not} cover.
Among these issues are:
\begin{itemize}
\item Time and date formats
\item Monetary formats
\item Numeric punctuation
\item Fonts
\item Lexicographic orderings
\item Right-to-left and bidirectional languages
\end{itemize}

%----------------------------------------------------------------------
%----------------------------------------------------------------------
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\chapter{Overview}

We use several terms within this document which
are new in the context of Common LISP.
Definitions for the following prominent
terms are provided for the reader's convenience.

A {\em character repertoire} defines a collection of characters
independent of their specific rendered image or font.  This
corresponds to the mathematical notion of a {\em set}
\footnote{We avoid the term {\em character set} as it has been
(over)used in the context of character repertoire as well
as in the context of coded character set.}.
Character
repertoires are specified independent of coding and their characters
are only identified with a unique label, a graphic symbol, and
a character description.
A {\em coded character set} is a character repertoire plus
an {\em encoding} providing a unique mapping between each character
and a number which serves as the character representation.
There are numerous internationally standardized coded character
sets; for example, \cite{iso8859/1} and \cite{iso646}.

A character may be included in one or more character repertoires.
Similarly, a character may be included in one or more
coded character sets.  For example, the Latin letter "A" is contained
in the coded character set standards: ISO 8859/1, ISO 8859/2,
ISO 6937/2, and others.

Common LISP
characters are partitioned into a unique collection of
repertoires called {\em
Character Registries}.  That is, each character is included
in one and only one Character Registry.  The label identifying
each character within a Character Registry is a unique numerical value
referred to as the {\em character index}.

In Common LISP a {\em character} data object is identified by its
{\em character code}, a unique numerical code.
Each character code is composed from
a Character Registry
shared by all characters of a particular Registry,
and a character index, a numerical value which
is unique within the Character Registry.

Character data objects which are classified as {\em graphic},
or displayable, are each associated with a {\em glyph}.  The
glyph is the visual representation of the character.

The primary purpose of introducing these terms is to provide a
consistent naming to Common LISP concepts which are related
to those found in ISO standardization of coded
character sets.
\footnote{The bibliography includes several relevant ISO
coded character set standards.}
They also serve as a demarkation between these
standardization activities.  For example, while Common LISP is free to
define unique repertoires and facilities to manipulate them, it should
not define coded character sets.

A secondary purpose is to detach the language specification from
underlying hardware representation.  From a language
specification viewpoint it is inconsequential whether
characters occupy one or more (8-bit) bytes or whether
a Common LISP implementation's
internal representation for characters is distinct from or identical
to any given external representation (for example, a text interchange
representation \cite{iso6937/2}).
We specifically do not propose any standard coded character sets.

%----------------------------------------------------------------------
\section{Character Identity}



Characters are uniquely distinguished by their codes,
which are drawn from the set of
non-negative integers.  That is, within Common LISP
a unique numerical code
is assigned to each semantically different character.
Character codes are composed from a Character Registry and a
character index.  The convention by which a character index and
Character Registry compose a character code is implementation
dependent.

It is important to separate the notion of glyph from the notion of
character data object when defining a scheme under which issues of
identity can be rigorously decided by a computer language.  Glyphs are
the visual aspects of characters, writable on surfaces, and sometimes
called 'graphics'.  A language specification valid for more than a
narrow range of systems can only make assumptions about the existence
of {\em abstract} glyphs (for example, the Latin letter A) and not about
glyph variants (for example, the italicized Latin letter {\em A})
or characteristics of display devices.  Thus, a key element of this
proposal is the removal of the {\em font} and {\em bits}
attributes from the language specification.

One ramification is that the distinction between {\clkwd string-char}
and {\clkwd character} is eliminated.  {\bf All} characters can be
inserted into (type compatible) strings.
In addition, all functions
dealing with the {\em bits} and {\em font} attributes are either
removed or modified by this proposal.

A second ramification is the introduction of new functions to
compose and decompose character objects.
The {\clkwd characterp} predicate is extended to
support testing
membership of a character in a given Character Registry.
\footnote{
For example,
testing membership in the Japanese Katakana Character Registry.
}
Also, a global variable {\clkwd *all-registry-names*} is added to
support application determination of supported Character Registries.

A third ramification is that I/O functions must be modified to manage
the interaction between the Common LISP treatment of characters and
the external environment.

The definition in \cite{steele84} of semi-standard characters has
been eliminated.  This is replaced by a more uniform approach
with introduction of the Control Character
Registry (see below).


%----------------------------------------------------------------------
\section{Character Repertoires and Registries}


A Common LISP program must be able to compose and decompose
characters in a portable uniform manner, independent of any
underlying representation.  One possible composition is by
the pair $<$ coded character set standard, decimal representation $>$
\footnote{This syntax is for illustration only and is not being
proposed.}.
Thus, for example, one might compose the Latin 'A' with the pair
$<$ "ISO8859/2-1987ccs", 65 $>$,
$<$ "ISO8859/6-1987ccs", 65 $>$, or
$<$ "ISO646-1983ccs", 65 $>$, etc..  The difficulty here is two-fold.
First, there are several ways to compose the same character and
second, there may be multiple answers to
the question: {\em To what coded character set
does character object x belong?}.\footnote{Even
worse, the answer might change yearly.}
The identical problems occur if the pair
$<$ character repertoire standard, decimal representation $>$ is used.
\footnote{Existing repertoires seem to be defined exclusively
in the context of coded character sets and not as standards
in their own right.}

The concept of Character Registry is introduced by this proposal
to resolve the problem of character composition and decomposition.
Each character is universally defined by the
pair $<$ Character Registry name, character index $>$. For this
to be a portable definition, it must have a standard meaning.
Thus this
proposal relies on a {\em Character Registry Standard}.
There is no existing Character Registry Standard.
Until such an ANSI or ISO standard exists, Common LISP
defines the {\em Common LISP Character Registry Standard}.
\footnote{It is the intention of X3 J13 to promote and adopt
an eventual ANSI or ISO Character Registry Standard.  In particular, we
acknowledge that X3 J13 is {\em not} the appropriate forum to
define the standard.  We believe
it is a required component of all programming languages
providing support for international characters.}


Common LISP defines the following Character Registries:
\footnote{In the interest of brevity, this document will
define only a partial list of
the Character Registry names.  A subsequent
document will define the complete Common LISP Character Registry
Standard including the effect of the character predicates
{\em alpha-char-p},
{\em lower-case-p}, etc..}
\footnote{
Character Registry names are strings formed from the Common LISP
{\clkwd standard-p} characters. Within registry names, alphabetic
case is ignored.}
\begin{itemize}
\item Arabic
\item Armenian
\item Bo-po-mo-fo
\item Control
\item Cyrillic
\item Georgian
\item Greek
\item Hangul
\item Hebrew
\item Hiragana
\item Japanese-Punctuation
\item Kanji-JIS-Level-1
\item Kanji-JIS-Level-2
\item Kanji-Gaiji
\item Katakana
\item Latin
\item Latin-Punctuation
\item Mathematical
\item Pattern
\item Phonetic
\item Technical
\end{itemize}
The Common LISP Character Registry Standard is fixed;
an implementation
may not extend the set of characters within any Common LISP
Character Registry.

An implementation may provide support for all or part of any Common LISP
Character Registry
and may provide new character registries which include characters
having unique semantics (i.e. not defined in any other
implementation-defined character registry or Common LISP Character
Registry).  Implementation registries must be uniquely
named using only {\clkwd standard-p} characters.  In addition,
the repertoire names {\em base} and {\em standard} have
reserved Common LISP usage.



An implementation must document the registries it supports.
For each registry supported,
an implementation must define individual characters supported
including at least the following:
\begin{itemize}
\item Character Labels,
Glyphs, and Descriptions.
\item $<$ Common LISP
Character Registry name, character index $>$ pair if one exists
otherwise $<$ implementation-defined
character registry name, character index $>$ pair.
\item Reader Canonicalization.
\item Position in total ordering.
The partial ordering of the Standard alphanumeric
characters must be preserved.
\item Effect of character predicates.
In particular,
\begin{itemize}
\item {\clkwd alpha-char-p}
\item {\clkwd lower-case-p}
\item {\clkwd upper-case-p}
\item {\clkwd both-case-p}
\item {\clkwd graphic-char-p}
\item {\clkwd standard-char-p}
\item {\clkwd alphanumericp}
\end{itemize}
\item Interaction with File I/O.  In particular, the
coded character set standards
\footnote{For example, "ISO8859/1-1987ccs".} and
external encoding schemes
\footnote{For example, {\em "Xerox System Integration Character
Code Standard"}\cite{xerox87}.}
which are supported must be specified.
\end{itemize}

The
intent of the provision for multiple character registries
is that native language glyphs (with associated digits and
punctuation)
\footnote{For example, the glyphs on the keycaps of a particular
terminal, or any other glyph sets with a common use in graphics or
symbolic communication.
}
should each be mapped by the I/O interface
into registries inside
Common LISP, all the members of which
share a common registry name.
Which glyph sets are supported by the overall computing system, the
details of the mapping of
glyphs to character codes, and any implementation unique character
registry names used, are left unspecified by Common LISP.

The diversity of glyph sets and coded character
set conventions in use worldwide and the desirability
of allowing Common LISP to manipulate symbolic elements from many
languages, perhaps simultaneously, mandate such a flexible approach.

%----------------------------------------------------------------------
\section{Hierarchy of Types}

Providing support for extensive character repertoires may
impact Common LISP implementation performance in terms
of space, time, or both.
\footnote{This does not apply to all implementations.
Unique hardware support and user community requirements must
be taken into consideration.}
In particular, many existing
implementations support variants of the ISO 8859/1 standard.
Supporting large
repertoires argues for a multi-byte internal representation
for each character, even if an application primarily (or exclusively)
uses the ISO 8859/1 characters.

This proposal extends the definition of the character and string
type hierarchy to include specialized subtypes
of character and string.  An implementation is free to associate
compact internal representation tailored to each subtype.
The {\clkwd string} type specifier, when used as a
declaration (for example, in {\clkwd make-sequence})
is defined to mean the most general string subtype supported
by the implementation.  This definition emphasizes portability
of existing Common LISP applications to international
character environments over performance.  Applications emphasizing
efficiency of text processing in non-international environments
will require some modification to utilize subtypes with
compact internal representations.

It has been suggested that either a single type is
sufficient to support international characters,
or that a hierarchy of types could be used, in a manner
transparent to the user.  A desire to provide flexibility which
encourages implementations to support international
characters without compromising application efficiency
led us to accept the need for more than one type.
We believe that these choices reflect a minimal
modification of this aspect of the type system, and that
exposing the types for string and character construction while
requiring uniform treatment for characters otherwise
is the most reasonable approach.

\subsection{Character Type}

The following type specifier is added as a subtype
of {\clkwd character}.
\begin{itemize}
\item {\clkwd base-character}
\end{itemize}

An implementation may support additional subtypes of {\clkwd character}
which may or may not be supertypes of {\clkwd base-character}.
In addition, an implementation may define {\clkwd base-character}
as equivalent to {\clkwd character}.

Characters of type {\clkwd base-character} are referred to as
{\em base characters}.  Characters of type {\clkwd
(and character (not base-character))}
are referred to as {\em extended characters}.
The base characters are
distinguished in the following respects:
\begin{itemize}
\item
The standard characters are a subrepertoire of the base characters.
\item
Only members of the base character repertoire
can be elements of a base string.
\item
The base characters are, in general, the default characters for I/O
operations.
\end{itemize}
No upper bound is specified for the number of glyphs in the base
character repertoire--that
is implementation dependent.  The lower bound is 96, the
number of standard characters defined for Common LISP.
\footnote{Or, in contrast, the base repertoire may include all
the Common LISP Character Registries.}


The distinction of base characters is largely a pragmatic
choice.  It permits efficient handling of common situations, is
in some sense privileged for host system I/O, and can serve as an
intermediate basis for portability, less general than the standard
characters, but possibly more useful across a narrower range of
implementations.

Many computers have some "base" character representation which
is a function of hardware instructions for dealing with characters,
as well as the organization of the file system.  The base character
representation is likely to be the smallest transaction unit permitted
for text file and terminal I/O operations.  On a system with a record
based I/O paradigm, the base character representation is likely to
be the smallest record quantum.  On many computer systems,
this representation is a byte.

However, there are often multiple
coded character sets supportable on a
computer, through the use of special display and entry hardware, which
are varying interpretations of the basic system character
representation.  For example, ISO 8859/1 and ISO 6937/2 are two
different interpretations of the same 1-byte code representations.
Many countries have their own glyph-to-code mappings for 1-byte
character codes addressing the special requirements of national
languages.  Differentiating between these, without reference to
display hardware, is a matter of convention, since they all use the
same set of code representations.  When a single byte is not enough,
two or more bytes are sometimes used for character encoding.  This
makes character handling even more difficult on machines where the
natural representation size is a byte, since not only is the semantic
value of a character code a matter of convention, which may vary
within the same computing system, but so is the identification of a
set of bits as a complete character code.

It is the intention of this proposal that the base characters of
Common LISP
be the natural characters of the host system: its composition
should be
determined by the code capacity of the natural file system and I/O
transaction representations, and its assumed display glyphs should be
those of the terminals most commonly employed.
There are several advantages to this scheme.  Internal representation
of strings of just base characters can be more compact than
strings including extended characters.
Source programs are likely to consist predominantly of base characters
since the standard characters are a subset of the base character
repertoire. Parsing of pure base character text
can be more efficient than parsing of text including
extended characters.
I/O can be performed more simply
with base characters.

The standard characters are the 96 characters used in the Common LISP
definition {\bf or their equivalents}.

This was the Common LISP \cite{steele84} definition, but
{\em equivalents} is a vague term.

The standard characters are not defined by their glyphs, but by their
roles within the language.  There are two aspects to the roles of the
standard characters: one is their role in reader and format control
string syntax; the second is their role as components of the names of
all Common LISP
functions, macros, constants, and global variables.  As
long as an implementation chooses 96 glyphs
and treats those 96 in a manner consistent with
the language's specification for the standard characters (e.g.
the naming of functions), it doesn't matter what glyphs the I/O
hardware uses to represent those characters: they are the standard
characters.  Any program or
data text written wholly in those characters
is portable through simple code conversion.
\footnote{For example, the currency glyph, \$ , might be replaced
uniformly by the currency glyph available on a particular display.}

Additional
mechanisms, such as in \cite{linden87}, which support establishment of
equivalency between otherwise distinct characters are not excluded by
this proposal.
\footnote{We believe this is an important issue but it requires
additional implementation experience.  We also encourage
new proposals from JIS and ISO LISP Working Groups on this issue.}

\subsection{String Type}

The {\clkwd string} type
is defined as
a vector of characters.  More precisely, a string
is a specialized vector whose elements are of type
{\clkwd character} or a subtype of character.  The following string
subtypes are
distinguished with standardized names: {\clkwd base-string},
{\clkwd general-string}, {\clkwd simple-base-string}, and
{\clkwd simple-general-string}.
All strings which are not base strings
are referred to as {\em extended strings}.

A base string can only contain base characters.  A
{\clkwd general-string}
can contain any implementation supported base or extended characters,
in any mixture.
\footnote{This type might be more appropriately named
{\clkwd most-general-string}.  {\clkwd general-string} was
subjectively judged to be less offensive.}

All Common LISP functions defined to operate on strings treat
base and extended strings uniformly with the following
caveat: for any function which inserts a character into a string, it
is an error to insert an extended character
into a base string.
\footnote{An implementation may, optionally, provide automatic
coersion to an extended string.}

An implementation may support string subtypes more general
than {\clkwd base-string} but more specialized than
{\clkwd general-string}.
For example, a hypothetical
implementation supporting Arabic and Cyrillic Character Registries
might provide:
\begin{itemize}
\item {\clkwd general-string} -- may contain Arabic, Cyrillic or
base characters in any mixture.
\item {\clkwd region-specialized-string} -- may contain installation
selected repertoire (Arabic/Cyrillic) or base characters in any
mixture.
\item {\clkwd base-string} -- may contain base characters
\end{itemize}
Though, clearly, portability of applications using
{\clkwd region-specialized-string} is limited, a performance
advantage might argue for its use.
\footnote{{\clkwd region-specialized-string} is used here for
illustration only; it is not being proposed as a standardized
string subtype.}

Alternatively,
an implementation
supporting a large base character repertoire
including, say, Japanese Character Registries may define
{\clkwd base-character}
as equivalent to {\clkwd character}.

We expect that applications sensitive to the performance
of character handling in some host environments will
utilize the string subtypes to provide performance
improvement.  Applications with emphasis on international
portability will likely utilize only {\clkwd general-string}s.

The {\clkwd coerce} function is extended to
allow for explicit coercion between base strings and extended strings.

During reader
construction of symbols, if all the characters
in the symbol's name are of type {\clkwd base-character},
then the name of the symbol may be stored as a base string.
Otherwise it will be stored as an extended string.

The base string type allows for more compact representation of strings
of base characters, which are likely to predominate in any system.
Note that in any particular implementation the base characters
need not be the
most compactly representable, since others might have
a smaller repertoire.
However, in most implementations base strings are
likely to be more space efficient than extended strings.


%----------------------------------------------------------------------
\section{Streams and System I/O}

A lot of the work of ensuring that a
Common LISP implementation operates correctly in a
multiple coded character set environment must be performed by
the I/O interface.
The system I/O interface, abstracted in
Common LISP as streams, is responsible
for ensuring that text input from outside LISP is properly mapped
into character objects internally, and that the inverse mapping
is performed on output.  It is beyond the scope of a language
definition to specify the details of this operation, but options
are specified which allow runtime indication from the user as to
what coded character sets a stream uses, and how the mappings
should be done.  It is expected that implementations will provide
reasonable defaults and invocation options to accommodate desired use
at an installation.

One keyword argument is proposed as an addition to {\clkwd open}:
\begin{itemize}
\item {\clkwd :external-code-format}
whose value would be:
\begin{itemize}
\item
A name or list indicating an implementation recognized scheme for
representing 1 or more coded character sets.
\footnote{
For example, the so/si convention used by IBM on 370
machines could be selected by a list including
the name {\em "ibm-shift-delimited"}.
The run-encoding convention defined by XEROX could be
selected by {\em "xerox-run-encoded"}.
The convention based on
ASCII which uses leading bit patterns to distinguish two-byte codes
from one-byte codes could be selected by
{\em "ascii-high-byte-delimited"}.
}
As many coded character set names must be provided as the
implementation requires for that external coding convention.
\footnote{
For example, if {\em "ibm-shift-delimited"} were the
{\clkwd :external-code-format} argument, two
coded character set specifiers would have to be provided.
}
\end{itemize}
\end{itemize}

These arguments are provided for input, output, and
bidirectional streams.
It is an error to try to write a character other than a
member of the specified coded character sets
to a stream.  (This excludes the
\#$\backslash${\clkwd Newline} character.
Implementations must provide appropriate line division behavior
for all character streams.)

An implementation supporting multiple coded character sets
must allow for the external
representation of characters to be separately (and perhaps
multiply) specified to {\clkwd open},
since there can be circumstances under
which more than one external representation for characters
is in use, or more than one coded character set
is mixed together in an
external representation convention.

In addition to supporting conversion at the system interface, the
language must allow user programs to determine how much space data
objects will require when output in whichever external representations
are available.

The new function {\clkwd external-width}
takes a character
or string object as its required argument.  It also takes an optional
{\em output-stream}.
It returns the number of host system character
representation quantum units
\footnote{
Same as the storage width of a base character, usually a byte.
}
required to externally store that object, using the
representation convention associated with the stream.
If the object cannot be represented in
that convention, the function returns {\clkwd nil}.
This function is necessary
to determine if strings can be written to fixed length
fields in databases or terminal screen templates.  Note that this
function does not
address the problem of calculating
screen width of strings printed in proportional fonts.
\footnote{
The X3 J13 proposal STREAM-INFO: ONE-DIMENSIONAL-FUNCTIONS
modified to include these semantics is an
acceptable alternative to the {\clkwd external-width} function
proposed here.}

%----------------------------------------------------------------------
%----------------------------------------------------------------------

∂12-Jan-89  1959	Common-Lisp-mailer 	cs proposal    
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89  19:59:21 PST
Date: Thu, 12 Jan 89 13:36:53 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <890112.133653.baggins@almvma>
Subject: cs proposal

I've just sent out two messages containing the latest character
proposal (no DRAFT this time).  We will only vote on this at
Hawaii if the full J13 agrees otherwise (which I expect)
a network ballot will be sent right after Hawaii.

Aloha,
  Thom

∂12-Jan-89  2000	Common-Lisp-mailer 	cs proposal    
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89  19:59:33 PST
Date: Thu, 12 Jan 89 16:53:24 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <890112.165324.baggins@almvma>
Subject: cs proposal

  Hopefully the character proposal covers all the varied comments
we received previously.  Thanks again to everyone for the constructive
criticism.  In particular, I wish to express our thanks to
Yuasa-san, Kurokawa-san and the JIS Lisp committee.

Regards,
  Thom

∂12-Jan-89  2341	Common-Lisp-mailer 	cs proposal part 2 of 3  
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89  23:40:00 PST
Date: Thu, 12 Jan 89 22:16:40 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <890112.221640.baggins@almvma>
Subject: cs proposal part 2 of 3

%----------------------------------------------------------------------
% split into three parts this time as mailer had problems
%----------------------------------------------------------------------
%----------------------------------------------------------------------

\newcommand{\edithead}{\begin{tabular}{l p{3.95in}}
  \multicolumn{2}{l} }

\newcommand{\csdag}{\bf$\Rightarrow$\ddag}

\newcommand{\editstart}{}

\newcommand{\editend}{\\ & \end{tabular}}

%----------------------------------------------------------------------
%----------------------------------------------------------------------
\appendix
\chapter{Editorial Modifications to CLtL}

The following sections specify the editorial changes needed in
CLtL to support the proposal.  Section/subsection numbers and titles
match those found in \cite{steele84}.  The notation
{\csdag x (pn, function)} denotes a reference to paragraph x within the
subsection (we count each individual example or metastatement
as 1 paragraph of text).  Also, {\bf (pn, function)}, or simply
{\bf (pn)} is included as an additional
aid to the reader indicating the page number and function modified.
When an entire paragraph is deleted,
the first few words of the paragraph is noted.

If a section or paragraph of CLtL is {\em not} referenced,
no editorial changes are required to support this proposal.
\footnote{This may be an over optimistic statement since the changes
are fairly pervasive.  The editor should take the sense of
Chapter 1 into account in resolving any discrepancies.}

%----------------------------------------------------------------------
\setcounter{section}{1}
\section{Data Types}                        % 2
%----------------------------------------------------------------------


\edithead {\csdag 8 (p12)}
\editstart
\\ \bf replace &
\cltxt
   provides for a
   rich character set, including ways to represent characters of various
   type styles.
\\ \bf with &
\cltxt
   provides support for international language characters as well
   as characters used in specialized arenas, eg. mathematics.
\editend

\setcounter{subsection}{1}
\subsection{Characters}                     % 2.2.

\edithead {\csdag 1 (p20)}
\editstart
\\ \bf replace &
\cltxt
  Characters are represented as data objects of type {\clkwd character}.
  There are two subtypes of interest, called
  {\clkwd standard-char} and {\clkwd string-char}.
\\ \bf with &
\cltxt
  Characters are represented as data objects of type
  {\clkwd character}.
\editend
\\
\edithead {\csdag 2 (p20)}
\editstart
\\ \bf replace &
\cltxt
  This works well enough for printing characters. Non-printing
  characters
\\ \bf with &
\cltxt
  This works well enough for graphic characters.  Non-graphic
  characters
\editend

\subsubsection{Standard Characters}         % 2.2.1.

\edithead {\csdag 0 section heading (p20)}
\editstart
\\ \bf replace &
\cltxt
  Standard Characters
\\ \bf with &
\cltxt
  Base Characters
\editend
\\
\edithead {\csdag 1 before (p20)}
\editstart
\\ \bf insert &
\cltxt
  A {\em character repertoire} defines a collection of characters
  independent of their specific rendered image or font.
  Character
  repertoires are specified independent of coding and their characters
  are only identified with a unique label, a graphic symbol, and
  a character description.
  A {\em coded character set} is a character repertoire plus
  an {\em encoding} providing a unique mapping between each character
  and a number which serves as the character representation.
\\ &
  Many computers have some "base" coded character set
  (often a variant of ISO646-1983)
  which is a function
  of hardware instructions for dealing with characters, as well as
  the organization of
  the file system.  This base character representation is likely
  to be the smallest
  transaction unit permitted for text stream I/O operations.
\\ &
  The {\em base character repertoire} is used to refer to
  the collection of characters represented by
  the base coded character set.  Common LISP does
  not define the base
  character encoding
  but does require all implementations to support a "standard"
  {\em subrepertoire} of the base character
  repertoire.
\editend
\\
\edithead {\csdag 1 before (p20)}
\editstart
\\ \bf insert &
\cltxt
  The {\clkwd base-character} type is defined as a subtype of
  {\clkwd character}.  A {\clkwd base-character}
  object can contain any member of the base character repertoire.
  Objects of type
  {\clkwd (and character (not base-character))} are referred to
  as {\em extended characters}.
\editend
\\
\edithead {\csdag 1 (p20)}
\editstart
\\ \bf delete &
\cltxt
  Common LISP defines a "standard character set" ...
\editend
\\
\edithead {\csdag 1 (P20)}
\editstart
\\ \bf new &
\cltxt
  As a subset of the base character repertoire,
  Common LISP defines a standard character
  subrepertoire for two purposes.
  Common LISP programs that are written in the
  standard character subrepertoire
  can be read by any Common LISP implementation; and Common LISP
  programs
  that use only standard characters as data objects are most likely
  to be portable.
  The standard characters are not defined by their glyphs, but by their
  roles within
  the language.  There are two aspects to the roles of the
  standard characters:
  one is their role in reader and format control
  string syntax; the second is their role as
  components of the names of all Common LISP
  functions, macros, constants, and global
  variables.  As long as an implementation chooses 96 glyphs
  and treats those 96 in a manner
  consistent with the language's specification for the standard characters
  (for example,
  the naming of functions),
  it doesn't matter what glyphs the I/O
  hardware uses to
  represent those characters: they are
  the standard characters.  Any program or
  data text written wholly
  in those characters
  is portable through simple code conversion.
  The Common LISP
  standard character subrepertoire consists of
  a newline \#$\backslash${\clkwd Newline}, the
  graphic space character \#$\backslash${\clkwd Space},
  and the following additional
  ninety-four graphic characters or their equivalents:
\editend
\\
\edithead {\csdag 2 (p21)}
\editstart
\\ \bf delete &
\cltxt
  ! " \# ...
\editend
\\
\edithead {\csdag 2 new (p21)}
\editstart
\\ &
  {\bf Common LISP Standard Character Subrepertoire}
\editend
\footnote{\cltxt \#$\backslash${\clkwd Space}
and \#$\backslash${\clkwd Newline} are omitted.
graphic labels and descriptions are from ISO 6937/2.
The first letter of the graphic label categorizes the
character as follows: L - Latin, N - Numeric, S - Special
.}
\\
{\small \begin{tabular}{||l|c|l||l|c|l||}    \hline
  ID     &    Glyph    &  Name or description
& ID     &    Glyph    &  Name or description
\\ \hline
  LA01  &  a  &  small a
& ND01  &  1  &  digit 1
\\ \hline
  LA02  &  A  &  capital A
& ND02  &  2  &  digit 2
\\ \hline
  LB01  &  b  &  small b
& ND03  &  3  &  digit 3
\\ \hline
  LB02  &  B  &  capital B
& ND04  &  4  &  digit 4
\\ \hline
  LC01  &  c  &  small c
& ND05  &  5  &  digit 5
\\ \hline
  LC02  &  C  &  capital C
& ND06  &  6  &  digit 6
\\ \hline
  LD01  &  d  &  small d
& ND07  &  7  &  digit 7
\\ \hline
  LD02  &  D  &  capital D
& ND08  &  8  &  digit 8
\\ \hline
  LE01  &  e  &  small e
& ND09  &  9  &  digit 9
\\ \hline
  LE02  &  E  &  capital E
& ND10  &  0  &  digit 0
\\ \hline
  LF01  &  f  &  small f
& SC03  &  \$    &  dollar sign
\\ \hline
  LF02  &  F  &  capital F
& SP02  &  !     &  exclamation mark
\\ \hline
  LG01  &  g  &  small g
& SP04  &  "     &  quotation mark
\\ \hline
  LG02  &  G  &  capital G
& SP05  &  \apostrophe     &  apostrophe
\\ \hline
  LH01  &  h  &  small h
& SP06  &  (     &  left parenthesis
\\ \hline
  LH02  &  H  &  capital H
& SP07  &  )     &  right parenthesis
\\ \hline
  LI01  &  i  &  small i
& SP08  &  ,     &  comma
\\ \hline
  LI02  &  I  &  capital I
& SP09  &  \_    &  low line
\\ \hline
  LJ01  &  j  &  small j
& SP10  &  -     &  hyphen or minus sign
\\ \hline
  LJ02  &  J  &  capital J
& SP11  &  .     &  full stop, period
\\ \hline
  LK01  &  k  &  small k
& SP12  &  /     &  solidus
\\ \hline
  LK02  &  K  &  capital K
& SP13  &  :     &  colon
\\ \hline
  LL01  &  l  &  small l
& SP14  &  ;     &  semicolon
\\ \hline
  LL02  &  L  &  capital L
& SP15  &  ?     &  question mark
\\ \hline
  LM01  &  m  &  small m
& SA01  &  +     &  plus sign
\\ \hline
  LM02  &  M  &  capital M
& SA03  &  $<$   &  less-than sign
\\ \hline
  LN01  &  n  &  small n
& SA04  &  =   &  equals sign
\\ \hline
  LN02  &  N  &  capital N
& SA05  &  $>$   &  greater-than sign
\\ \hline
  LO01  &  o  &  small o
& SM01  &  \#    &  number sign
\\ \hline
  LO02  &  O  &  capital O
& SM02  &  \%    &  percent sign
\\ \hline
  LP01  &  p  &  small p
& SM03  &  \&    &  ampersand
\\ \hline
  LP02  &  P  &  capital P
& SM04  &  *     &  asterisk
\\ \hline
  LQ01  &  q  &  small q
& SM05  &  @     &  commercial at
\\ \hline
  LQ02  &  Q  &  capital Q
& SM06  &  [     &  left square bracket
\\ \hline
  LR01  &  r  &  small r
& SM07  &  $\backslash$   &  reverse solidus
\\ \hline
  LR02  &  R  &  capital R
& SM08  &  ]     &  right square bracket
\\ \hline
  LS01  &  s  &  small s
& SM11  &  \{    &  left curly bracket
\\ \hline
  LS02  &  S  &  capital S
& SM13  &  $|$     &  vertical bar
\\ \hline
  LT01  &  t  &  small t
& SM14  &  \}    &  right curly bracket
\\ \hline
  LT02  &  T  &  capital T
& SD13  &  \bq   &  grave accent
\\ \hline
  LU01  &  u  &  small u
& SD15  &  $\hat{ }$  &  circumflex accent
\\ \hline
  LU02  &  U  &  capital U
& SD19  &  $\tilde{ }$ &  tilde
\\ \hline
  LV01  &  v  &  small v
& & &
\\ \hline
  LV02  &  V  &  capital V
& & &
\\ \hline
  LW01  &  w  &  small w
& & &
\\ \hline
  LW02  &  W  &  capital W
& & &
\\ \hline
  LX01  &  x  &  small x
& & &
\\ \hline
  LX02  &  X  &  capital X
& & &
\\ \hline
  LY01  &  y  &  small y
& & &
\\ \hline
  LY02  &  Y  &  capital Y
& & &
\\ \hline
  LZ01  &  z  &  small z
& & &
\\ \hline
  LZ02  &  Z  &  capital Z
& & &
\\
\hline
\end{tabular} }
\\
\edithead {\csdag 3 (p21)}
\editstart
\\ \bf delete &
\cltxt
  @ A B C...
\editend
\\
\edithead {\csdag 4 (p21)}
\editstart
\\ \bf delete &
\cltxt
  \bq a b c...
\editend
\\
\edithead {\csdag 5 (p21)}
\editstart
\\ \bf delete &
\cltxt
  The Common LISP Standard character set is apparently ...
\editend
\\
\edithead {\csdag 6 (p21)}
\editstart
\\ \bf replace &
\cltxt
  Of the ninety-four non-blank printing characters
\\ \bf with &
\cltxt
  Of the ninety-five graphic characters
\editend
\\
\edithead {\csdag 9 (p21)}
\editstart
\\ \bf delete &
\cltxt
  The following characters are called ...
\editend
\\
\edithead {\csdag 10 (p21)}
\editstart
\\ \bf delete &
\cltxt
  {\clkwd \#$\backslash$Backspace \#$\backslash$Tab } ...
\editend
\\
\edithead {\csdag 11 (p21)}
\editstart
\\ \bf delete &
\cltxt
  Not all implementations of Common ...
\editend

\subsubsection{Line Divisions}              % 2.2.2.

\edithead {\csdag 6 (p22)}
\editstart
\\ \bf replace &
\cltxt
  a two-character sequence, such as
  {\clkwd \#$\backslash$Return } and then
  {\clkwd \#$\backslash$Newline },
  is not acceptable,
\\ \bf with &
\cltxt
  a two-character sequence is not acceptable,
\editend
\\
\edithead {\csdag 8 (p22)}
\editstart
\\ \bf delete &
\cltxt
  Implementation note: If an implementation uses ...
\editend

\subsubsection{Non-standard Characters}     % 2.2.3.

\edithead {\csdag delete entire section (p23)}
\editstart
\editend

\subsubsection{Character Attributes}        % 2.2.4.

\edithead {\csdag 0 section heading (p23)}
\editstart
\\ \bf replace &
\cltxt
  Character Attributes
\\ \bf with &
\cltxt
  Character Identity
\editend
\\
\edithead {\csdag 1 through 8 (p23)}
\editstart
\\ \bf delete all paragraphs&
\cltxt
  Every object of type {\clkwd character} ...
\editend
\\
\edithead {\csdag 1 (p23)}
\editstart
\\ \bf new &
\cltxt
Common LISP
characters are partitioned into a unique collection of
repertoires called {\em
Character Registries}.  That is, each character is included
in one and only one Character Registry.  The label identifying
each character within a Character Registry is a unique numerical value
referred to as the {\em character index}.
\\ &
Characters are uniquely distinguished by their codes,
which are drawn from the set of
non-negative integers.  That is, within Common LISP
a unique numerical code
is assigned to each semantically different character.
Character codes are composed from a Character Registry and a
character index.  The convention by which a character index and
Character Registry compose a character code is implementation
dependent.
\editend

\subsubsection{String Characters}           % 2.2.5.

\edithead {\csdag delete entire section (p23)}
\editstart
\editend

\setcounter{subsection}{4}
\subsubsection{Character Registries}           % 2.2.5.

\edithead {\csdag new section (p23)}
\editstart
\\ \bf new &
\cltxt
Character registries provide portable specifications of
character objects.  Every character object is uniquely
identified by a registry name and index.
Character Registry names are strings formed from the Common LISP
{\clkwd standard-p} characters. Within registry names, alphabetic
case is ignored.
\\ &
Common LISP defines the following Character Registries:
\footnote{This document
defines a partial list of
the Character Registry names.  A subsequent
document will define the complete Common LISP Character Registry
Standard including the effect of the character predicates
{\em alpha-char-p},
{\em lower-case-p}, etc..}
\begin{itemize}
\item Arabic
\item Armenian
\item Bo-po-mo-fo
\item Control
\item Cyrillic
\item Georgian
\item Greek
\item Hangul
\item Hebrew
\item Hiragana
\item Japanese-Punctuation
\item Kanji-JIS-Level-1
\item Kanji-JIS-Level-2
\item Kanji-Gaiji
\item Katakana
\item Latin
\item Latin-Punctuation
\item Mathematical
\item Pattern
\item Phonetic
\item Technical
\end{itemize}
\editend
\\
\edithead {\csdag new section (p23)}
\editstart
\\ \bf new &
\cltxt
The Common LISP Character Registry Standard is fixed;
an implementation
may not extend the set of characters within any Common LISP
Character Registry.
\\ &
An implementation may provide support for all or part of any Common LISP
Character Registry
and may provide new character registries which include characters
having unique semantics (i.e. not defined in any other
implementation-defined character registry or Common LISP Character
Registry).  Implementation registries must be uniquely
named using only {\clkwd standard-p} characters.  In addition,
the repertoire names {\em base} and {\em standard} have
reserved Common LISP usage.
\\ &
An implementation must document the registries it supports.
For each registry supported,
an implementation must define individual characters supported
including at least the following:
\begin{itemize}
\item Character Labels,
Glyphs, and Descriptions.
\item $<$ Common LISP
Character Registry name, character index $>$ pair if one exists
otherwise $<$ implementation-defined
character registry name, character index $>$ pair.
\item Reader Canonicalization.
\item Position in total ordering.
The partial ordering of the Standard alphanumeric
characters must be preserved.
\item Effect of character predicates.
In particular,
\begin{itemize}
\item {\clkwd alpha-char-p}
\item {\clkwd lower-case-p}
\item {\clkwd upper-case-p}
\item {\clkwd both-case-p}
\item {\clkwd graphic-char-p}
\item {\clkwd standard-char-p}
\item {\clkwd alphanumericp}
\end{itemize}
\item Interaction with File I/O.  In particular, the
coded character set standards
\footnote{For example, "ISO8859/1-1987ccs".} and
external encoding schemes
\footnote{For example, {\em "Xerox System Integration Character
Code Standard"}\cite{xerox87}.}
which are supported must be specified.
\end{itemize}
\editend

\subsection{Symbols}                        % 2.3.

\edithead {\csdag 12 (p25)}
\editstart
\\ \bf replace &
\cltxt
  A symbol may have uppercase letters, lowercase letters, or both
  in its print name.
\\ \bf with &
\cltxt
  A symbol may have characters from any supported character registry
  in its print name.
  It may have uppercase letters, lowercase letters, or both.
\editend

\setcounter{subsection}{4}
\subsection{Arrays}
\subsubsection{Vectors}

\edithead {\csdag 6 (p29)}
\editstart
\\ \bf replace &
\cltxt
  All implementations provide specialized arrays for the cases when
  the components are characters (or rather, a special subset of the
  characters);
\\ \bf with &
\cltxt
  All implementations provide specialized arrays for the cases when
  the components are characters (or optionally, special subsets of
  the characters);
\editend

\subsubsection{Strings}

\edithead {\csdag 1 (p30)}
\editstart
\\ \bf replace &
\cltxt
  A string is simply a vector of characters.  More precisely, a string
  is a specialized vector whose elements are of type
  {\clkwd string-char}.
\\ \bf with &
\cltxt
  A string is simply a vector of characters.  More precisely, a string
  is a specialized vector whose elements are of type
  {\clkwd character} or a subtype
  of character.
\editend

\setcounter{subsection}{14}
\subsection{Overlap, Inclusion, and Disjointness of Types} % 2.15.

\edithead {\csdag 14 (p34)}
\editstart
\\ \bf replace &
\cltxt
  The type {\clkwd standard-char} is a subtype of {\clkwd string-char};
  {\clkwd string-char} is a subtype of {\clkwd character}.
\\ \bf with &
\cltxt
  The type {\clkwd base-character} is a subtype of
  {\clkwd character}.
\editend
\\
\edithead {\csdag 15 (p34)}
\editstart
\\ \bf replace &
\cltxt
  The type {\clkwd string} is a subtype of {\clkwd vector},
  for {\clkwd string} means {\clkwd (vector string-char)}.
\\ \bf with &
\cltxt
  The type {\clkwd string} is a subtype of {\clkwd vector},
  {\clkwd string} consists of vectors specialized by subtypes of
  {\clkwd character}.
\editend
\\
\edithead {\csdag 15 after (p34)}
\editstart
\\ \bf insert &
\cltxt
  The type {\clkwd base-string} means
  {\clkwd (vector base-character)}.
\editend
\\
\edithead {\csdag 15 after (p34)}
\editstart
\\ \bf insert &
\cltxt
  The type {\clkwd general-string} means
  {\clkwd (vector character)} and is a subtype of {\clkwd string}.
\editend
\\
\edithead {\csdag 20 (p34)}
\editstart
\\ \bf replace &
\cltxt
  {\clkwd (simple-array string-char (*))};
\\ \bf with &
\cltxt
  {\clkwd (simple-array character (*))};
\editend
\\
\edithead {\csdag 20 after (p34)}
\editstart
\\ \bf insert &
\cltxt
  The type {\clkwd simple-base-string} means
  {\clkwd (simple-array base-character (*))} and
  is the most efficient string which can hold
  the standard characters. {\clkwd simple-base-string}
  is a subtype of {\clkwd base-string}.
\editend
\\
\edithead {\csdag 20 after (p34)}
\editstart
\\ \bf insert &
\cltxt
  The type {\clkwd simple-general-string} means
  {\clkwd (simple-array character (*))}.
  {\clkwd simple-general-string}
  is a subtype of {\clkwd general-string}.
\editend



%----------------------------------------------------------------------
\setcounter{section}{3}
\section{Type Specifiers}                   % 4
%----------------------------------------------------------------------
\setcounter{subsection}{1}
\subsection{Type Specifier Lists} % 4.2.


\edithead {\csdag 8 Table 4-1 (alphabetic list) (p43)}
\editstart
\\ \bf remove &
\\ &
\cltxt
  {\clkwd standard-char}
\\ &
  {\clkwd string-char}
\editend
\\
\edithead {\csdag 8 Table 4-1 (alphabetic list) (p43)}
\editstart
\\ \bf insert &
\\ &
\cltxt
  {\clkwd base-character}
\\ &
  {\clkwd general-string}
\\ &
  {\clkwd simple-base-string}
\\ &
  {\clkwd simple-general-string}
\editend

\setcounter{subsection}{2}
\subsection{Predicating Type Specifiers} % 4.3.

\edithead {\csdag 2 (p43)}
\editstart
\\ \bf delete &
\cltxt
  As an example, the entire ...
\editend
\\
\edithead {\csdag 3 delete example (p43)}
\editstart
\\ \bf delete &
\cltxt
  {\clkwd (deftype string-char () } ...
\editend

\setcounter{subsection}{4}
\subsection{Type Specifiers That Specialize} % 4.5.

\edithead {\csdag 5 after (p46)}
\editstart
\\ \bf insert &
\cltxt
  {\clkwd (character {\em registries})}
\\  &
  This denotes a character type specialized to members
  of the specified registries.  {\em registries} may be a
  single character registry name or a list of
  character registry names.
\editend

\setcounter{subsection}{5}
\subsection{Type Specifiers That Abbreviate} % 4.6.

\edithead {\csdag 20 (p49)}
\editstart
\\ \bf replace &
\cltxt
  Means the same as {\clkwd (array string-char ({\em size}))}: the set of
  strings of
  the indicated size.
\\ \bf with &
\cltxt
  Means the union of the vector types specialized by subtypes of
  character
  and the indicated size.
  For the purpose of declaration, it is equivalent to
  {\clkwd (general-string ({\em size}))}.
\editend
\\
\edithead {\csdag 23 (p49)}
\editstart
\\ \bf replace &
\cltxt
  Means the same as {\clkwd (simple-array string-char ({\em size}))}: the
  set of simple strings of the indicated size.
\\ \bf with &
\cltxt
  Means the union of the simple vector types specialized by subtypes of
  character and the indicated size.
  For the purpose of declaration, it is equivalent to
  {\clkwd (simple-general-string ({\em size}))}.
\editend
\\
\edithead {\csdag 23 after (p49)}
\editstart
\\ \bf insert &
\cltxt
  {\clkwd (base-string {\em size})}
\\ &
  Means the same as {\clkwd (array base-character ({\em size}))}: the
  set of base strings of the indicated size.
\\ &
  {\clkwd (simple-base-string {\em size})}
\\ &
  Means the same as {\clkwd (simple-array base-character ({\em size}))}:
  the set of simple base strings of the indicated size.
\editend
\\
\edithead {\csdag 23 after (p49)}
\editstart
\\ \bf insert &
\cltxt
  {\clkwd (general-string {\em size})}
\\ &
  Means the same as {\clkwd (array base-character ({\em size}))}: the
  set of base strings of the indicated size.
\\ &
  {\clkwd (simple-general-string {\em size})}
\\ &
  Means the same as
  {\clkwd (simple-array general-character ({\em size}))}:
  the set of simple general strings of the indicated size.
\editend

\setcounter{subsection}{7}
\subsection{Type Conversion Function} % 4.8.

\edithead {\csdag 6 (p51)}
\editstart
\\ \bf replace &
\cltxt
  Some strings, symbols, and integers may be converted to
  characters.  If {\em object} is a string of length 1,
  then the sole element of the print name is returned.
  If {\em object} is an integer {\em n}, then {\clkwd (int-char }
  {\em n}{\clkwd )} is returned.  See {\clkwd character}.
\\ \bf with &
\cltxt
  Some strings amd symbols may be converted to
  characters.  If {\em object} is a string of length 1,
  then the sole element of the print name is returned.
  See {\clkwd character}.
\editend
\\
\edithead {\csdag 6 after (p52)}
\editstart
\\ \bf insert &
\begin{itemize}
\cltxt
\item Any string subtype may be converted to any other string
subtype, provided the new string can contain all actual
elements of the old string.  It is an error if it cannot.
\end{itemize}
\editend


%----------------------------------------------------------------------
\setcounter{section}{5}
\section{Predicates}                        % 6
%----------------------------------------------------------------------
\edithead {\csdag 2 (p71)}
\editstart
\\ \bf replace &
\cltxt
  but {\clkwd standard-char} begets {\clkwd standard-char-p}
\\ \bf with &
\cltxt
  but {\clkwd bit-vector} begets {\clkwd bit-vector-p}
\editend

\setcounter{subsection}{1}
\subsection{Data Type Predicates} % 6.2.

\setcounter{subsubsection}{1}
\subsubsection{Specific Data Type Predicates} % 6.2.2.

\edithead {\csdag 36 (p75)}
\editstart
\\ \bf replace &
\cltxt
  {\clkwd characterp} {\em object}
\\ \bf with &
\cltxt
  {\clkwd characterp} {\em object} \&{\clkwd optional}
  {\em repertoire}
\editend
\\
\edithead {\csdag 37 (p75)}
\editstart
\\ \bf replace &
\cltxt
  {\clkwd characterp} is true if its argument is a character,
  and otherwise is false.
\\ \bf with &
\cltxt
  If {\em repertoire} is omitted, {\clkwd characterp}
  is true if its argument is a character object,
  and otherwise is false.
  If a {\em repertoire} argument is specified,
  {\clkwd characterp} is true if its argument
  is a character object and a member of the specified repertoire,
  and
  otherwise is false.
  For example, {\clkwd (characterp  \#$\backslash$A}
  {\clkwd "Latin")}
  is true since \#$\backslash$A is a member of the Common LISP
  Latin Character Registry.  {\em repertoire} may be any supported
  character registry name or the reserved repertoire names
  "base" and "standard". {\clkwd (characterp x "base")} is
  true if its argument is a member of the base character
  repertoire and false
  otherwise.
  {\clkwd (characterp x "standard")} is
  true if its argument is a member of the standard character
  repertoire and false
  otherwise.
\editend
\\
\edithead {\csdag 38 (p75)}
\editstart
\\ \bf replace &
\cltxt
  {\clkwd (characterp x) $\equiv$ (typep x \apostrophe character)}
\\ \bf with &
\cltxt
  {\clkwd (characterp x "standard") $\equiv$ (typep x \apostrophe
  (character "standard")}
\editend
\\
\edithead {\csdag 72 (p76)}
\editstart
\\ \bf replace &
\cltxt
  See also {\clkwd standard-char-p, string-char-p, streamp,}
\\ \bf with &
\cltxt
  See also {\clkwd standard-char-p, streamp,}
\editend

\setcounter{subsubsection}{2}
\subsubsection{Equality Predicates} % 6.2.3.

\edithead {\csdag 75 (p81)}
\editstart
\\ \bf replace &
\cltxt
  which ignores alphabetic case and certain other attributes
  of characters;
\\ \bf with &
\cltxt
  which ignores alphabetic case
  of characters;
\editend

%----------------------------------------------------------------------
\setcounter{section}{6}
\section{Control Structure}                 % 7
%----------------------------------------------------------------------

\setcounter{subsection}{1}
\subsection{Generalized Variables} % 7.2.

\edithead {\csdag 19 modify table (p95)}
\editstart
\\ \bf replace &
\cltxt
  char               string-char
\\ &
  schar              string-char
\\ \bf with &
\cltxt
  char               character
\\ &
  schar              character
\\ &
  sbchar             base-character
\editend
\\
\edithead {\csdag 22 table entry (p96)}
\editstart
\\ \bf delete &
\cltxt
  char-bit           first                  set-char-bit
\editend

%----------------------------------------------------------------------

∂12-Jan-89  2343	Common-Lisp-mailer 	cs proposal part 3 of 3  
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89  23:41:27 PST
Date: Thu, 12 Jan 89 22:17:09 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <890112.221709.baggins@almvma>
Subject: cs proposal part 3 of 3


%----------------------------------------------------------------------
\setcounter{section}{9}
\section{Symbols}                           % 10
%----------------------------------------------------------------------

\edithead {\csdag 3 (p163)}
\editstart
\\ \bf replace &
\cltxt
  It is ordinarily not permitted to alter a symbol's print name.
\\ \bf with &
\cltxt
  It is an error to alter a symbol's print name.
\editend

\setcounter{subsection}{1}
\subsection{The Print Name} % 10.2.

\edithead {\csdag 5 (p168)}
\editstart
\\ \bf replace &
\cltxt
  It is an extremely bad idea
\\ \bf with &
\cltxt
  It is an error and an extremely bad idea
\editend

%----------------------------------------------------------------------
\setcounter{section}{10}
\section{Packages}                           % 11
%----------------------------------------------------------------------

\setcounter{subsection}{6}
\subsection{Package System Functions and Variables} % 11.7.

\edithead {\csdag 31 (p184,intern)}
\editstart
\\ \bf append &
\cltxt
  All strings, base and extended, are acceptable {\em string}
  arguments.
\editend

%----------------------------------------------------------------------
\setcounter{section}{12}
\section{Characters}                        % 13
%----------------------------------------------------------------------

\edithead {\csdag 6 after (p233)}
\editstart
\\ \bf insert &
\cltxt
  {\clkwd char-code-limit}   [{\clkwd Constant}]
\\ &
  The value of {\clkwd char-code-limit} is a non-negative integer
  that is the upper exclusive bound on values produced by the
  function {\clkwd char-code}, which returns the {\em code}
  of a given character; that is, the values returned by
  {\clkwd char-code} are non-negative and strictly less than
  the value of {\clkwd char-code-limit}.
  There may be unassigned codes between 0 and
  {\clkwd char-code-limit} which
  are not legal arguments to {\clkwd code-char}.
\\  &
\cltxt
  {\clkwd char-index-limit {\em registry}}   [{\clkwd Function}]
\\ &
  This function returns a non-negative integer
  that is the upper exclusive bound on values produced by the
  function {\clkwd char-index} for the specified {\em registry}.
  There may be unsupported index values between 0 and
  {\clkwd char-index-limit}, i.e.
  {\clkwd (find-char {\em registry index})} may return {\clkwd nil}.
\\  &
\cltxt
  {\clkwd *all-registry-names*}   [{\clkwd Constant}]
\\ &
  The value of {\clkwd *all-registry-names*} is a list of
  all character registry names supported by the implementation.
  Only Common LISP Character Registry names or implementation
  defined character registries may be included in this list.
  In particular, "base" and "standard" are not character registry
  names and must not be included.
\editend

\setcounter{subsection}{0}
\subsection{Character Attributes} % 13.1.

\edithead {\csdag delete entire section (p233)}
\editstart
\editend

\setcounter{subsection}{1}
\subsection{Predicates on Characters} % 13.2.


\edithead {\csdag 3 (p234)}
\editstart
\\ \bf replace &
\cltxt
  argument is a "standard character" that is, an object of type
  {\clkwd standard-char}.
   Note that any character with a non-zero {\em bits} or {\em font}
   attribute
   is non-standard.
\\ \bf with &
\cltxt
  argument is one of the Common LISP standard character subrepertoire.
\editend
\\
\edithead {\csdag 4 (p234)}
\editstart
\\ \bf delete &
\cltxt
  Note that any character with non-zero ...
\editend
\\
\edithead {\csdag 6 (p235)}
\editstart
\\ \bf replace &
\cltxt
  Of the standard characters all but \#$\backslash${\clkwd Newline}
  are graphic.
  The semi-standard characters \#$\backslash${\clkwd Backspace},
  \#$\backslash${\clkwd Tab},
  \#$\backslash${\clkwd Rubout},
  \#$\backslash${\clkwd Linefeed},
  \#$\backslash${\clkwd Return},
  and \#$\backslash${\clkwd Page} are not graphic.
\\ \bf with &
\cltxt
  Of the standard characters all but \#$\backslash${\clkwd Newline}
  are graphic.
\editend
\\
\edithead {\csdag 7 (p235)}
\editstart
\\ \bf delete &
\cltxt
  Programs may assume that graphic ...
\editend
\\
\edithead {\csdag 8 (p235)}
\editstart
\\ \bf delete &
\cltxt
  Any character with a non-zero bits...
\editend
\\
\edithead {\csdag 9 (p235)}
\editstart
\\ \bf delete &
\cltxt
  {\clkwd string-char-p} ...
\editend
\\
\edithead {\csdag 10 (p235)}
\editstart
\\ \bf delete &
\cltxt
  The argument {\em char} must be ...
\editend
\\
\edithead {\csdag 13 (p235)}
\editstart
\\ \bf replace &
\cltxt
  If a character is alphabetic, then it is perforce graphic.  Therefore
  any character
  with a non-zero bits attribute cannot be alphabetic.  Whether a
  character is
  alphabetic is may depend on its font number.
\\ \bf with &
\cltxt
  If a character is alphabetic, then it is perforce graphic.
\editend
\\
\edithead {\csdag 22 (p236)}
\editstart
\\ \bf replace &
\cltxt
  If a character is either uppercase or lowercase, it is necessarily
  alphabetic (and
  therefore is graphic, and therefore has a zero bits attribute).
  However, it is permissible in theory for an alphabetic character
  to be neither
  uppercase nor lowercase (in a non-Roman font, for example).
\\ \bf with &
\cltxt
  If a character is either uppercase or lowercase, it is necessarily
  alphabetic (and
  therefore is graphic).
\editend
\\
\edithead {\csdag 25 (p236)}
\editstart
\\ \bf replace &
\cltxt
  The argument {\em char} must be a character object, and {\em radix}
  must be a non-negative
  integer. If {\em char} is not a digit of the radix specified
\\ \bf with &
\cltxt
  The argument {\em char} must be in the standard character
  subrepertoire and
  {\em radix} must be a non-negative integer.
  If {\em char} is not a standard character or is not a digit of the
  radix specified
\editend
\\
\edithead {\csdag 51 (p237)}
\editstart
\\ \bf delete &
\cltxt
  If two characters have the same bits ...
\editend
\\
\edithead {\csdag 52 (p237)}
\editstart
\\ \bf replace &
\cltxt
  If two characters differ in any attribute (code, bits, or font), then
  they are different.
\\ \bf with &
\cltxt
  If the codes of two characters differ, then
  they are different.
\editend
\\
\edithead {\csdag 94 (p239)}
\editstart
\\ \bf replace &
\cltxt
  The predicate {\clkwd char-equal} is like {\clkwd char=}, and
  similarly for the others, except
  according to a different ordering such that differences of bits
  attributes and case are ignored, and font information is taken into
  account in an implementation dependent manner.
\\ \bf with &
\cltxt
  The predicate {\clkwd char-equal} is like {\clkwd char=}, and
  similarly for the others, except
  according to a different ordering such that differences of case
  are ignored.
\editend
\\
\edithead {\csdag 97 example (p239)}
\editstart
\\ \bf delete &
\cltxt
  {\clkwd (char-equal \#$\backslash$A \#$\backslash$Control-A) is true}
\editend
\\
\edithead {\csdag 98 (p239)}
\editstart
\\ \bf delete &
\cltxt
  The ordering may depend on the font ...
\editend

\setcounter{subsection}{2}
\subsection{Character Construction and Selection} % 13.3.

\edithead {\csdag 3 (p239)}
\editstart
\\ \bf replace &
\cltxt
  The argument {\em char} must be a character object.
  {\clkwd char-code} returns the {\em code} attribute of the
  character object;
  this will be a non-negative integer less than the (normal) value
\\ \bf with &
\cltxt
  The argument {\em char} must be a character object.
  {\clkwd char-code} returns the {\em code} of the
  character object;
  this will be a non-negative integer less than the value
\editend
\\
\edithead {\csdag 4 (p240)}
\editstart
\\ \bf delete &
\cltxt
  {\clkwd char-bits } ...
\editend
\\
\edithead {\csdag 5 (p240)}
\editstart
\\ \bf delete &
\cltxt
  The argument {\em char} must be ...
\editend
\\
\edithead {\csdag 6 (p240)}
\editstart
\\ \bf delete &
\cltxt
  {\clkwd char-font } ...
\editend
\\
\edithead {\csdag 7 (p240)}
\editstart
\\ \bf delete &
\cltxt
  The argument {\em char} must be ...
\editend
\\
\edithead {\csdag 8 (p240)}
\editstart
\\ \bf replace &
\cltxt
  {\clkwd code-char {\em code} \&optional {\em (bits 0) (font 0)}
  [{\em Function}]}
\\ \bf with &
\cltxt
  {\clkwd code-char {\em code}
  [{\em Function}]}
\editend
\\
\edithead {\csdag 9 (p240)}
\editstart
\\ \bf replace &
\cltxt
  All three arguments must be non-negative integers.  If it is possible
  in the
  implementation to construct a character object whose code attribute
  is {\em code},
  whose
  bits attribute is {\em bits}, and whose font attribute is {\em font},
  then such an object
  is returned;
\\ \bf with &
\cltxt
  The argument must be a non-negative integer.  If it is possible
  in the
  implementation to construct a character object identified by
  {\em code},
  then such an object is returned;
\editend
\\
\edithead {\csdag 10 (p240)}
\editstart
\\ \bf replace &
\cltxt
  For any integers, {\em c, b,} and {\em f}, if {\clkwd (code-char
  {\em c b f})} is
\\ \bf with &
\cltxt
  For any integer, {\em c}, if {\clkwd (code-char
  {\em c})} is
\editend
\\
\edithead {\csdag 12 (p240)}
\editstart
\\ \bf delete &
\cltxt
  {\clkwd (char-bits (code-char } ...
\editend
\\
\edithead {\csdag 13 (p240)}
\editstart
\\ \bf delete &
\cltxt
  {\clkwd (char-font (code-char } ...
\editend
\\
\edithead {\csdag 14 (p240)}
\editstart
\\ \bf delete &
\cltxt
  If the font and bits attributes ...
\editend
\\
\edithead {\csdag 15 (p240)}
\editstart
\\ \bf delete &
\cltxt
  {\clkwd (char= (code-char (char-code ...}
\editend
\\
\edithead {\csdag 16 (p240)}
\editstart
\\ \bf delete &
\cltxt
  is true.
\editend
\\
\edithead {\csdag 17 (p240)}
\editstart
\\ \bf delete &
\cltxt
  {\clkwd make-char} ...
\editend
\\
\edithead {\csdag 18 (p240)}
\editstart
\\ \bf delete &
\cltxt
 The argument {\em char} must be ...
\editend
\\
\edithead {\csdag 19 (p240)}
\editstart
\\ \bf delete &
\cltxt
 If {\em bits} or {\em font} are zero ...
\editend
\\
\edithead {\csdag 19 (p240)}
\editstart
\\ \bf append &
\cltxt
  {\clkwd find-char} {\em index registry}    [{\em Function}]
\\ &
  {\clkwd find-char} returns a character object.
  {\em index} is an integer
  value uniquely identifying a character within the character
  registry name {\em registry}.
  If the implementation does not support the specified
  character, {\clkwd nil} is returned.
\editend

\setcounter{subsection}{3}
\subsection{Character Conversions} % 13.4.

\edithead {\csdag 8 (p241)}
\editstart
\\ \bf replace &
\cltxt
  {\clkwd char-upcase} returns a character object with the same
  font and bits attributes as {\em char}, but with possibly a
  different code attribute.
\\ \bf with &
\cltxt
  {\clkwd char-upcase} returns a character object with possibly
  a different code.
\editend
\\
\edithead {\csdag 10 (p241)}
\editstart
\\ \bf replace &
\cltxt
  Similarly, {\clkwd char-downcase} returns a character object with the
  same font and bits attributes as {\em char}, but with possibly a
  different code attribute.
\\ \bf with &
\cltxt
  Similarly, {\clkwd char-downcase} returns a character object with
  possibly a different code.
\editend
\\
\edithead {\csdag 12 (p241)}
\editstart
\\ \bf delete &
\cltxt
  Note that the action of ...
\editend
\\
\edithead {\csdag 13 (p241)}
\editstart
\\ \bf replace &
\cltxt
  {\clkwd digit-char {\em weight} \&optional ({\em radix} 10)
  ({\em font} 0)      [{\em Function}]}
\\ \bf with &
\cltxt
  {\clkwd digit-char {\em weight} \&optional ({\em radix} 10)
       [{\em Function}]}
\editend
\\
\edithead {\csdag 14 (p241)}
\editstart
\\ \bf replace &
\cltxt
  All arguments must be integers.  {\clkwd digit-char} determines
  whether or not it is
  possible
  to construct a character object whose font attribute is {\em font},
  and whose {\em code}
\\ \bf with &
\cltxt
  All arguments must be integers.  {\clkwd digit-char} determines
  whether or not it is
  possible to construct a character object whose {\em code}
\editend
\\
\edithead {\csdag 15 (p242)}
\editstart
\\ \bf replace &
\cltxt
  {\clkwd digit-char} cannot return {\clkwd nil} if {\em font}
  is zero, {\em radix}
\\ \bf with &
\cltxt
  {\clkwd digit-char} cannot return {\clkwd nil}.
  {\em radix}
\editend
\\
\edithead {\csdag 22 (p242)}
\editstart
\\ \bf delete &
\cltxt
  Note that no argument is provided for ...
\editend
\\
\edithead {\csdag 23 through 30 (p242, char-int, int-char)}
\editstart
\\ \bf delete &
\cltxt
  {\clkwd char-int} {\em char}
\editend
\\
\edithead {\csdag 32 (p242)}
\editstart
\\ \bf replace &
\cltxt
  All characters that have zero font and bits attributes and that are
  non-graphic
\\ \bf with &
\cltxt
  All characters that are
  non-graphic
\editend
\\
\edithead {\csdag 33 (p243)}
\editstart
\\ \bf replace &
\cltxt
  The standard newline and space characters have the respective
  names {\clkwd Newline} and {\clkwd Space}.  The semi-standard
  characters have the names {\clkwd Tab, Page, Rubout, Linefeed,
  Return,} and {\clkwd Backspace}.
\\ \bf with &
\cltxt
  The standard newline and space characters have the respective
  names {\clkwd Newline} and {\clkwd Space}.
\editend
\\
\edithead {\csdag 35 (p243)}
\editstart
\\ \bf delete &
\cltxt
  {\clkwd char-name} will only locate "simple" ...
\editend
\\
\edithead {\csdag 36 (p243)}
\editstart
\\ \bf append &
\cltxt
  {\clkwd name-char} may accept other names for characters
  in addition to those returned by {\clkwd char-name}.
\editend
\\
\edithead {\csdag 36 (p243)}
\editstart
\\ \bf append &
\cltxt
  {\clkwd char-registry} {\em char}    [{\em Function}]
\\ &
  {\clkwd char-registry} returns a string value representing
  the character registry to which {\em char} belongs.
\editend
\\
\edithead {\csdag 36 (p243)}
\editstart
\\ \bf append &
\cltxt
  {\clkwd char-index} {\em char}    [{\em Function}]
\\ &
  {\clkwd char-index} returns an integer value representing
  the character (registry) index of {\em char}.
\editend

\setcounter{subsection}{4}
\subsection{Character Control-Bit Functions} % 13.5.

\edithead {\csdag delete entire section (p243)}
\editstart
\editend

%----------------------------------------------------------------------
\setcounter{section}{13}
\section{Sequences}                         % 14
%----------------------------------------------------------------------
\setcounter{subsection}{0}
\subsection{Simple Sequence Functions}         % 14.1

\edithead {\csdag 21 (p249,make-sequence)}
\editstart
\\ \bf append &
\cltxt
  If type {\clkwd string} is specified, the result is
  equivalent to {\clkwd make-string}.
\editend

%----------------------------------------------------------------------
\setcounter{section}{17}
\section{Strings}                           % 18
%----------------------------------------------------------------------

\edithead {\csdag 1 (p299)}
\editstart
\\ \bf replace &
\cltxt
  Specifically, the type {\clkwd string} is identical to the type
  {\clkwd (vector string-char),}
  which in turn is the same as {\clkwd (array string-char (*))}.
\\ \bf with &
\cltxt
  Specifically, the type {\clkwd string} is a subtype of
  {\clkwd vector}
  and consists of vectors specialized by subtypes of {\clkwd character}.
\editend

\setcounter{subsection}{0}
\subsection{String Access}  % 18.1.

\edithead {\csdag 3 (p300)}
\editstart
\\ \bf insert &
\cltxt
  {\clkwd sbchar} {\em simple-base-string index}    [{\em Function}]
\editend
\\
\edithead {\csdag 4 (p300)}
\editstart
\\ \bf replace &
\cltxt
  character object.  (This character will necessarily satisfy the
  predicate
  {\clkwd string-char-p}).
\\ \bf with &
\cltxt
  character object.
\editend
\\
\edithead {\csdag 9 (p300)}
\editstart
\\ \bf replace &
\cltxt
  {\clkwd setf} may be used with {\clkwd char} to destructively
  replace a character within a string.
\\ \bf with &
\cltxt
  {\clkwd setf} may be used with {\clkwd char} to destructively
  replace a character within a string.
  The new character must be of a type which can be stored in the
  string; it is an error otherwise.
\editend
\\
\edithead {\csdag 10 (p300)}
\editstart
\\ \bf insert &
\cltxt
  For {\clkwd sbchar}, the string must be a simple base string.
  The new character must be of a type which can be stored in the
  string; it is an error otherwise.
\editend

\setcounter{subsection}{2}
\subsection{String Construction and Manipulation}  % 18.3.

\edithead {\csdag 2 (p302)}
\editstart
\\ \bf replace &
\cltxt
  {\clkwd make-string {\em size} \&key :initial-element  [{\em Function}]}
\\ \bf with &
\cltxt
  {\clkwd make-string {\em size} \&key :initial-element  :element-type
  [{\em Function}]}
\editend
\\
\edithead {\csdag 3 (p302,make-string)}
\editstart
\\ \bf replace &
\cltxt
  This returns a string (in fact a simple string) of length {\em size},
  each of whose characters has been initialized to the
  {\clkwd :initial-element} argument.  If an {\clkwd :initial-element}
  argument is not specified, then the string will be initialized
  in an implementation-dependent way.
\\ \bf with &
\cltxt
  This returns a string of length {\em size},
  each of whose characters has been initialized to the
  {\clkwd :initial-element} argument.  If an {\clkwd :initial-element}
  argument is not specified, then the string will be initialized
  in an implementation-dependent way.
  The {\clkwd :element-type} argument names the type of the elements
  of the string; a string is constructed of the most specialized
  type that can accommodate elements of the given type.
  If {\clkwd :element-type} is omitted, the type
  {\clkwd simple-string} is the default.
\editend
\\
\edithead {\csdag 5 (p302,make-string)}
\editstart
\\ \bf replace &
\cltxt
  A string is really just a one-dimensional array of "string
  characters" (that is,
  those characters that are members of type {\clkwd string-char}).
  More complex character arrays may be constructed using the function
  {\clkwd make-array}.
\\ \bf with &
\cltxt
  More complex character arrays may be constructed using the function
  {\clkwd make-array}.
\editend
\\
\edithead {\csdag 29 (p304,make-string)}
\editstart
\\ \bf replace &
\cltxt
  If {\em x} is a string character (a character of type
  {\clkwd string-char}), then
\\ \bf with &
\cltxt
  If {\em x} is a character, then
\editend

%----------------------------------------------------------------------
\setcounter{section}{21}
\section{Input/Output}                      % 22

\setcounter{subsection}{0}
\subsection{Printed Representation of LISP Objects}  % 22.1.

\setcounter{subsubsection}{0}
\subsubsection{What the Read Function Accepts}  % 22.1.1.

\edithead {\csdag Table 22-1: Standard Character Syntax Types (p336)}
\editstart
\\ \bf delete entry &
\cltxt
  {\clkwd <tab>} {\em whitespace}
\\ &
  {\clkwd <page>} {\em whitespace}
\\ &
  {\clkwd <backspace>} {\em constituent}
\\ &
  {\clkwd <return>} {\em whitespace}
\\ &
  {\clkwd <rubout>} {\em constituent}
\\ &
  {\clkwd <linefeed>} {\em whitespace}
\editend

\setcounter{subsubsection}{1}
\subsubsection{Parsing of Numbers and Symbols}  % 22.1.2.

\edithead {\csdag Table 22-3: Standard Constituent Character
Attributes (p340)}
\editstart
\\ \bf delete entry &
\cltxt
  {\clkwd <backspace>} {\em illegal}
\\  &
  {\clkwd <tab>} {\em illegal}
\\  &
  {\clkwd <linefeed>} {\em illegal}
\\  &
  {\clkwd <page>} {\em illegal}
\\  &
  {\clkwd <return>} {\em illegal}
\\  &
  {\clkwd <rubout>} {\em illegal}
\editend

\setcounter{subsubsection}{3}
\subsubsection{Standard Dispatching Macro Character Syntax}  % 22.1.4.

\edithead {\csdag Table 22-4: Standard \# Macro Character Syntax (p352)}
\editstart
\\ \bf delete entry &
\cltxt
  {\clkwd \#<backspace>} {\em signals error}
\\  &
  {\clkwd \#<tab>} {\em signals error}
\\  &
  {\clkwd \#<linefeed>} {\em signals error}
\\  &
  {\clkwd \#<page>} {\em signals error}
\\  &
  {\clkwd \#<return>} {\em signals error}
\\  &
  {\clkwd \#<rubout>} {\em undefined}
\editend
\\
\edithead {\csdag 8 (p353)}
\editstart
\\ \bf replace &
\cltxt
  The following names are standard across all implementations:
\\ \bf with &
\cltxt
  All non-graphic
  characters, including extended characters, are uniquely
  named in an implementation-dependent manner.
  The following names are standard across all implementations:
\editend
\\
\edithead {\csdag 11 through 18 inclusive delete (p353)}
\editstart
\\ \bf delete &
\cltxt
  The following names are semi-standard; ...
\editend
\\
\edithead {\csdag 20 through 26 inclusive delete (p354)}
\editstart
\\ \bf delete &
\cltxt
  The following convention is used in implementations ...
\editend
\\
\edithead {\csdag 108 (p360)}
\editstart
\\ \bf replace &
\cltxt
  {\clkwd \#<space>, \#<tab>, \#<newline>, \#<page>, \#<return>}
\\ \bf with &
\cltxt
  {\clkwd \#<space>, \#<newline>}
\editend

\setcounter{subsubsection}{4}
\subsubsection{The Readtable}  % 22.1.5.

\edithead {\csdag 3 (p360)}
\editstart
\\ \bf replace &
\cltxt
  Even if an implementation supports characters with non-zero
  {\em bits} and {\em font}
  attributes, it need not (but may) allow for such characters to
  have syntax
  descriptions
  in the readtable.  However, every character of type
  {\clkwd string-char}
  must be represented in the readtable.
\\ \bf with &
\cltxt
  All base and extended characters
  are representable in the readtable.
\editend

\setcounter{subsubsection}{5}
\subsubsection{What the Print Function Produces}  % 22.1.6.

\edithead {\csdag 13 (p366)}
\editstart
\\ \bf replace &
\cltxt
  is used.  For example, the printed representation of the character
  \#$\backslash$A
  with control
  and meta bits on would be \#$\backslash${\clkwd CONTROL-META-A},
  and that of
  \#$\backslash$a with control and meta bits on would be
  \#$\backslash${\clkwd CONTROL-META-$\backslash$a}.
\\ \bf with &
\cltxt
  is used (see 22.1.4).
\editend

\setcounter{subsection}{2}
\subsection{Output Functions}  % 22.3.

\setcounter{subsubsection}{0}
\subsubsection{Output to Character Streams}  % 22.3.1.

\edithead {\csdag 26 (p384)}
\editstart
\\ \bf replace &
\cltxt
  ({\em not} the substring delimited by {\clkwd :start} and
  {\clkwd :end}).
\\ \bf with &
  ({\em not} the substring delimited by {\clkwd :start} and
  {\clkwd :end}).
  Only characters which are members of the coded character set(s)
  associated with the output stream or \#$\backslash${\clkwd Newline}
  are valid to be written;
  it is an error otherwise.  All character streams must provide
  appropriate line division behavior for
  \#$\backslash${\clkwd Newline}.
\editend
\\
\edithead {\csdag 27 after (p384)}
\editstart
\\ \bf insert &
\cltxt
  {\clkwd external-width} {\em object} \&{\clkwd optional}
  {\em output-stream}   [{\em Function}]
\\  &
  {\clkwd external-width} returns the number of host system base
  character units required for the object on the output-stream. If
  not applicable to the output stream, the function
  returns {\clkwd nil}.
  This number corresponds to the current state of the stream
  and may change if there has been intervening output.
  If the output stream is not specified {\clkwd *standard-output*}
  is the default.
\editend

\footnote{
The X3 J13 proposal STREAM-INFO: ONE-DIMENSIONAL-FUNCTIONS
modified to include these semantics is an
acceptable alternative to the {\clkwd external-width} function
proposed here.}

\setcounter{subsubsection}{2}
\subsubsection{Formatted Output to Character Streams}  % 22.3.3.

\edithead {\csdag 23 delete example (p387)}
\editstart
\\ \bf delete &
\cltxt
  {\clkwd (format nil "Type} $\tilde{ }$
  {\clkwd :C to $\tilde{ }$ :A."} . . .
\editend
\\
\edithead {\csdag 66 (p389)}
\editstart
\\ \bf replace &
\cltxt
  $\tilde{ }${\clkwd :C} spells out the names of the control bits and
  represents non-printing
  characters by their names: {\clkwd Control-Meta-F, Control-Return,
  Space}.
  This is a "pretty" format for printing characters.
\\ \bf with &
\cltxt
  $\tilde{ }${\clkwd :C}
  represents non-printing
  characters by their names: {\clkwd Newline,
  Space}.  This is a "pretty" format
  for printing characters.
\editend
%----------------------------------------------------------------------

%----------------------------------------------------------------------
\setcounter{section}{22}
\section{File System Interface}             % 23

\setcounter{subsection}{1}
\subsection{Opening and Closing Files}  % 23.2.

\edithead {\csdag 2 (p418)}
\editstart
\\ \bf replace &
\cltxt
  {\clkwd open {\em filename} \&key :direction :element-type}
  {\clkwd :if-exists :if-does-not-exist}
  [{\em Function}]
\\ \bf with &
\cltxt
  {\clkwd open {\em filename} \&key :direction :element-type}
  {\clkwd
  :external-code-format}
  {\clkwd :if-exists :if-does-not-exist}
  [{\em Function}]
\editend
\\
\edithead {\csdag 11 (p419)}
\editstart
\\ \bf replace &
\cltxt
  {\clkwd string-char}
\\  &
  The unit of transaction is a string-character.  The functions
  {\clkwd read-char}
  and/or {\clkwd write-char} may be used on the stream.
\\ \bf with &
\cltxt
  The default value of {\clkwd :element-type} is an
  implementation-defined subtype of character.
\\  &
  {\clkwd base-character}
\\  &
  The unit of transaction is a base character.  The functions
  {\clkwd read-char}
  and/or {\clkwd write-char} may be used on the stream.  This is
  the default.
\editend
\\
\edithead {\csdag 16 (p419)}
\editstart
\\ \bf replace &
\cltxt
  {\clkwd character}
\\  &
  The unit of transaction is any character, not just a string-character.
  The functions {\clkwd read-char} and/or {\clkwd write-char} may
  be used on the stream.
\\ \bf with &
\cltxt
  {\clkwd character}
\\  &
  The unit of transaction is any character.
  The functions {\clkwd read-char} and/or {\clkwd write-char} may
  be used on the stream.
\editend
\\
\edithead {\csdag 19 after (p420)}
\editstart
\\ \bf insert &
\cltxt
  {\clkwd :external-code-format}
\\  &
This argument specifies a string or list of
string(s) indicating an implementation recognized scheme for
representing 1 or more coded character sets with non-homogeneous codes.
\\  &
The default value is "default" and is
implementation defined but must include the
base characters.
\\  &
As many coded character set names must be provided as the
implementation requires for that external coding convention.
\\  &
References to standard ISO coded character set names must
include the full ISO reference number and approval year followed
by "ccs".  The following are valid ISO reference names:
"ISO8859/1-1987ccs", "ISO6937/2-1983ccs", "iso646-1983ccs", etc..
All implementation recognized schemes are formed from
{\clkwd standard-p} characters.  Within scheme names,
alphabetic case is ignored.
\editend
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\chapter{Deprecated Language Features}

The X3 J13 Character subcommittee proposal
will cause certain areas of \cite{steele84} to
become obsolete.  We have included in this appendix, potential
additions to the standard document for areas we feel are important
in the interest of compatibility.  The character subcommittee
recommends that the X3 J13 committee as a whole adopt a
policy regarding obsolescence.  This policy
may be to keep the obsolete function in the interest of
compatibility for existing applications, or
to drop the obsolete function completely.  One compromise
is to document these functions in an appendix to the Common LISP
Standard.  The appendix would be for informational use only
and not a part of the standard definition.


%----------------------------------------------------------------------
\setcounter{section}{1}
\section{Data Types}                        % 2
%----------------------------------------------------------------------

\setcounter{subsection}{14}
\subsection{Overlap, Inclusion, and Disjointness of Types} % 2.15.

\edithead {\csdag 14 (p34)}
\editstart
\\ \bf deprecated &
\cltxt
  The type {\clkwd standard-char} is a subtype of
  {\clkwd base-character};
  The type {\clkwd string-char} is implementation defined as either
  {\clkwd base-character} or {\clkwd character}.
\editend

%----------------------------------------------------------------------
\setcounter{section}{12}
\section{Characters}                        % 13
%----------------------------------------------------------------------

\edithead {\csdag throughout}
\editstart
\\ \bf deprecated &
\cltxt
  Earlier versions of Common LISP incorporated {\em font} and
  {\em bits} as attributes of character objects.
  There are several functions which were removed
  from the language or modified by this proposal.
  The deleted functions and constants include:
\begin{itemize}
\item char-font-limit
\item char-bits-limit
\item int-char
\item char-int
\item char-bits
\item char-font
\item make-char
\item char-control-bit
\item char-meta-bit
\item char-super-bit
\item char-hyper-bit
\item char-bit
\item set-char-bit
\end{itemize}
\editend
\\
\edithead {\csdag (p233)}
\editstart
\\ \bf deprecated &
\cltxt
  If supported by an implementation these attributes may
  effect the action of selected functions.  In particular,
  the following effects noted:
\\ &
\begin{itemize}
\item Attributes, such as those
  dealing with how the character is displayed or its typography,
  are not part of the character code.
  For example, bold-face, color
  or size are not considered part of the character code.
\item If two characters differ in any attributes,
  then they are not {\clkwd char=}.
\item If two characters have identical
  attributes, then their ordering by
  {\clkwd char}$<$ is consistent with the numerical ordering by the
  predicate $<$ on
  their code attributes. (Similarly for {\clkwd char}$>$,
  {\clkwd char}$>=$ and {\clkwd char}$<=$.)
\item The effect, if any, on {\clkwd char-equal} of each
  attribute has to be specified as part of
  the definition of that attribute.
\item The effect of {\clkwd char-upcase} and {\clkwd char-downcase}
  is to preserve attributes.
\item The function {\clkwd char-int} is equivalent to {\clkwd char-code}
  if no attributes are associated with
  the character object.
\item The function {\clkwd int-char} is equivalent to {\clkwd code-char}
  if no attributes are associated with
  the character object.
\item It is implementation dependent whether characters within
  double quotes have attributes removed.
\item  It is implementation dependent whether
  attributes are removed from symbol names by {\clkwd read}.
\item  Even if an implementation supports characters with non-zero
  {\em bits} and {\em font}
  attributes, it need not (but may) allow for such characters to
  have syntax descriptions
  in the readtable.
\end{itemize}
\editend


%----------------------------------------------------------------------
\begin{thebibliography}{wwwwwwww 99}


\bibitem[Ida87]{ida87} M. Ida, et al.,
{\em
JEIDA Common LISP Committee Proposal on Embedding Multi-Byte Characters
},
ANSI X3J13 document 87-022, (1987).

\bibitem[ISO 646]{iso646} ISO,
{\em
Information processing -- ISO 7-bit coded character set
for information interchange
},
ISO (1983).

\bibitem[ISO 4873]{iso4873} ISO,
{\em
Information processing -- ISO 8-bit code for information
interchange -- Structure and rules for implementation
},
ISO (1986).

\bibitem[ISO 6937/1]{iso6937/1} ISO,
{\em
Information processing -- Coded character sets for text
communication -- Part 1: General introduction
},
ISO (1983).

\bibitem[ISO 6937/2]{iso6937/2} ISO,
{\em
Information processing -- Coded character sets for text
communication -- Part 2: Latin alphabetic and non-alphabetic
graphic characters
},
ISO (1983).

\bibitem[ISO 8859/1]{iso8859/1} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 1: Latin alphabet No. 1
},
ISO (1987).

\bibitem[ISO 8859/2]{iso8859/2} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 2: Latin alphabet No. 2
},
ISO (1987).

\bibitem[ISO 8859/6]{iso8859/6} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 6: Latin/Arabic alphabet
},
ISO (1987).

\bibitem[ISO 8859/7]{iso8859/7} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 7: Latin/Greek alphabet
},
ISO (1987).

\bibitem[Kerns87]{kerns87} R. Kerns,
{\em
Extended Characters in Common LISP
},
X3J13 Character Subcommittee document, Symbolics Inc (1987).

\bibitem[Kurokawa88]{kurokawa88} T. Kurokawa, et al.,
{\em
Technical Issues on International Character Set Handling in Lisp
},
ISO/IEC SC22 WG16 document N33, (1988).

\bibitem[Linden87]{linden87} T. Linden,
{\em
Common LISP - Proposed Extensions for International Character Set
Handling
},
Version 01.11.87, IBM Corporation (1987).

\bibitem[Steele84]{steele84} G. Steele Jr.,
{\em
Common LISP: the Language
},
Digital Press (1984).

\bibitem[Xerox87]{xerox87} Xerox,
{\em
Character Code Standard, Xerox System Integration Standard
},
Xerox Corp. (1987).

\end{thebibliography}

\end{document}             % End of document.

∂13-Jan-89  1055	@MCC.COM,@AMMON.ACA.MCC.COM:ai.clive@MCC.COM 	Test message  
Received: from MCC.COM by SAIL.Stanford.EDU with TCP; 13 Jan 89  10:55:36 PST
Received: from AMMON.ACA.MCC.COM by MCC.COM with TCP/SMTP; Fri 13 Jan 89 12:40:11-CST
Date: Fri, 13 Jan 89 12:59 CST
From: Clive B. Dawson <ai.clive@MCC.COM>
Subject: Test message
Message-ID: <19890113185930.2.CLIVE@AMMON.ACA.MCC.COM>
bcc: CLisp-Dis@MCC.COM

This message is just a test of a future common lisp mail distribution point from
MCC.COM.  Please disregard this message.

∂13-Jan-89  1709	Common-Lisp-mailer 	Re: commonlisp types
Received: from fs3.cs.rpi.edu by SAIL.Stanford.EDU with TCP; 13 Jan 89  17:09:41 PST
Received: by fs3.cs.rpi.edu (5.54/1.2-RPI-CS-Dept)
	id AA11907; Fri, 13 Jan 89 20:05:15 EST
Date: Fri, 13 Jan 89 17:30:43 EST
From: harrisr@turing.cs.rpi.edu (Richard Harris)
Received: by turing.cs.rpi.edu (4.0/1.2-RPI-CS-Dept)
	id AA05864; Fri, 13 Jan 89 17:30:43 EST
Message-Id: <8901132230.AA05864@turing.cs.rpi.edu>
To: RWK%FUJI.ILA.Dialnet.Symbolics.Com@riverside.scrc.symbolics.com,
        common-lisp@sail.stanford.edu
Subject: Re: commonlisp types

  Date: Mon, 9 Jan 89 21:42 EST
  From: Robert W. Kerns <RWK@F.ILA.Dialnet.Symbolics.COM>


  OK, next question:  Does it open-code or otherwise optimize TYPEP, or
  just call TYPEP on the list?
KCL just calls TYPEP on the list.

One of the patches that I have made to KCL is a version of TYPEP
that open-codes when the type is a constant, but my patch has the bug.

Richard Harris

∂14-Jan-89  2000	Common-Lisp-mailer 	Logical Operations on Numbers 
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 14 Jan 89  19:59:57 PST
Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA03650g; Sat, 14 Jan 89 19:55:17 PST
Received: by bhopal id AA10940g; Sat, 14 Jan 89 19:57:36 PST
Date: Sat, 14 Jan 89 19:57:36 PST
From: Jon L White <jonl@lucid.com>
Message-Id: <8901150357.AA10940@bhopal>
To: ELIOT@cs.umass.EDU
Cc: common-lisp@sail.stanford.EDU
In-Reply-To: ELIOT@cs.umass.EDU's message of Thu, 12 Jan 89 15:31 EST <8901122046.AA00579@crash.cs.umass.edu>
Subject: Logical Operations on Numbers

For what it's worth, Johan DeKleer at Xerox PARC asked for just such
functionality back in 1984.  I don't remember what the public response
was then -- I seem to remember everyone trying to write clever, short
code sequences that would "do the trick".  But the gaping hole still
stands.  If just one more person seems to thinkg it is a good idea,
then that should carry much force with the X3J13 committee.

-- JonL --

∂16-Jan-89  1650	Common-Lisp-mailer 	Logical Operations on Numbers 
Received: from ALDERAAN.SCRC.Symbolics.COM ([128.81.41.109]) by SAIL.Stanford.EDU with TCP; 16 Jan 89  16:50:50 PST
Received: from GANG-GANG.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 260510; Mon 16-Jan-89 19:48:35 EST
Date: Mon, 16 Jan 89 19:48 EST
From: Glenn S. Burke <gsb@ALDERAAN.SCRC.Symbolics.COM>
Subject: Logical Operations on Numbers
To: jonl@lucid.com, ELIOT@cs.umass.EDU
cc: common-lisp@sail.stanford.EDU
In-Reply-To: <8901150357.AA10940@bhopal>
Message-ID: <19890117004819.7.GSB@ANNISQUAM.SCRC.Symbolics.COM>

    Date: Sat, 14 Jan 89 19:57:36 PST
    From: Jon L White <jonl@lucid.com>

    For what it's worth, Johan DeKleer at Xerox PARC asked for just such
    functionality back in 1984.  I don't remember what the public response
    was then -- I seem to remember everyone trying to write clever, short
    code sequences that would "do the trick".  But the gaping hole still
    stands.  If just one more person seems to thinkg it is a good idea,
    then that should carry much force with the X3J13 committee.

    -- JonL --

Logical subsetp is in the critical path of a peephole optimizer i just
wrote.  For efficiency reasons, though, the code was reorganized so that
in any given instantiation the size was fixed, and some complicated
macrology ends up turning things into manipulation of lists of fixnums.
(here's an application for the fixnum type which can enhance
portability...)

I could see having this kind of predicate for both integers and
bitvectors, and could imagine a sufficiently powerful compiler handling
it (and other bit and logical operations) efficiently.

∂19-Jan-89  0953	Common-Lisp-mailer 	Logical Operations on Numbers 
Received: from crash.cs.umass.edu ([128.119.40.235]) by SAIL.Stanford.EDU with TCP; 19 Jan 89  09:52:58 PST
Received: from vax3.cs.umass.edu by crash.cs.umass.edu (5.59/Ultrix2.0-B)
	id AA06071; Thu, 19 Jan 89 12:53:38 est
Message-Id: <8901191753.AA06071@crash.cs.umass.edu>
Date: Thu, 19 Jan 89 12:53 EST
From: ELIOT@cs.umass.EDU
Subject: Logical Operations on Numbers
To: Common-Lisp@sail.stanford.EDU
X-Vms-To: IN%"Common-Lisp@sail.stanford.edu"

Rather than duplicating the subset operations on both numbers and bitvectors
why not make the generic arithmetic routines accept bitvectors as non-negative
integers?  The generic arithmetic routines already handle so many types
that one more can't make a big difference.  Many numeric routines make
sense and extend the functionality if they could be applied to bitvector
For example, ZEROP (null set), =, /=, logXXX, boole,lognot, logtest,
logcount, integer-length.

However, bitvectors have never been very useful to me because of the
restriction that the bit-XXX operations can only work on arrays
of the same DIMENSIONS.  If this were relaxed and the smaller array was
treated as being extended with zeros I think they would be much more useful.

Chris Eliot

∂20-Jan-89  0834	Common-Lisp-mailer 	LOGICAL OPERATIONS ON NUMBERS 
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 20 Jan 89  08:34:43 PST
Received: from relay2.cs.net by RELAY.CS.NET id aj08866; 20 Jan 89 8:51 EST
Received: from draper.com by RELAY.CS.NET id aa25245; 20 Jan 89 8:46 EST
Return-path: seb1525@mvs.draper.com
Received: from MVS.DRAPER.COM by DRAPER.COM via TCP; Fri Jan 20 08:16 EST
Received: by MVS.DRAPER.COM with NETMAIL; FRI, 20 JAN 89 08:16 EST
Date: FRI, 20 JAN 89 08:13 EST
From: SEB1525@mvs.draper.com
Subject: LOGICAL OPERATIONS ON NUMBERS
To: common-lisp@SAIL.STANFORD.EDU
Reply-to: seb1525@draper.com
X-MVS-to:  common-lisp@sail.stanford.edu
Message-Id: <NETMAILR09012008133SEB1525@MVS.DRAPER.COM>


Isn't SUBSETP of A and B, where A and B are integers, implementable by
 (eql B (logior A B))
?

∂20-Jan-89  1234	Common-Lisp-mailer 	New Mail Address    
Received: from decwrl.dec.com by SAIL.Stanford.EDU with TCP; 20 Jan 89  12:34:07 PST
Received: from decvax.dec.com by decwrl.dec.com (5.54.5/4.7.34)
	for common-lisp@sail.stanford.edu; id AA14762; Fri, 20 Jan 89 12:31:42 PST
Received: from thor.prime.com by cvbnet.prime.com (3.2/SMI-3.2)
	id AA04473; Fri, 20 Jan 89 15:28:47 EST
Received: from giants.uucp by thor.prime.com (3.2/3.14)
	id AA08730; Fri, 20 Jan 89 15:22:47 EST
Return-Path: <tbardasz@giants>
Received: by giants.uucp (3.2/SMI-3.0DEV3)
	id AA04231; Fri, 20 Jan 89 15:23:00 EST
Date: Fri, 20 Jan 89 15:23:00 EST
From: decvax!cvbnet!giants.prime.com!tbardasz@decwrl.dec.com (Ted Bardasz)
Message-Id: <8901202023.AA04231@giants.uucp>
To: cvbnet!decvax!decwrl!SAIL.STANFORD.EDU!common-lisp@decwrl.dec.com
Subject: New Mail Address


	Please change my mail address to:

	decvax!tbardasz@cvbnet.prime.com

	Thanks,

		Ted Bardasz

∂23-Jan-89  0740	Common-Lisp-mailer 	Logical Operations on Numbers 
Received: from crash.cs.umass.edu ([128.119.40.235]) by SAIL.Stanford.EDU with TCP; 23 Jan 89  07:40:00 PST
Received: from vax3.cs.umass.edu by crash.cs.umass.edu (5.59/Ultrix2.0-B)
	id AA01738; Mon, 23 Jan 89 10:40:36 est
Message-Id: <8901231540.AA01738@crash.cs.umass.edu>
Date: Sun, 22 Jan 89 12:18 EST
From: ELIOT@cs.umass.EDU
Subject: Logical Operations on Numbers
To: Common-Lisp@sail.stanford.EDU
X-Vms-To: IN%"Common-Lisp@sail.stanford.edu"

   From:	IN%"seb1525@draper.COM" 20-JAN-1989 12:12
   Subj:	LOGICAL OPERATIONS ON NUMBERS

   From: SEB1525@mvs.draper.COM
   To: common-lisp@SAIL.STANFORD.EDU


   Isn't SUBSETP of A and B, where A and B are integers, implementable by
    (eql B (logior A B))?

Yes.  It is also (zerop (logandc2 A B)).  However, these expressions
are not efficient.  Suppose that the sets are large, hundreds or thousands
of elements.  In this case A and B are going to be 'bignums', certainly
not FIXNUMS.  Assuming that bignums are implemented so they can be 
operated on as a series of chunks we have:


	A = a1'a2'a3'...'an
	B = b1'b2'b3'...'bn
 

SUBSET implemented directly is:
	(AND[i=1..n] (%subset ai bi))

Where %subset operates on a single chunk.  AND[i=1..n] is a short circuit
logical 'AND' operation.  This requires n operations, and allocates NO new
memory.

SUBSET implemented as (eql B (logior A B)) requires n operations to compute
the logior, perhaps some overhead to normalize the new bignum,
plus n more operations to compute EQL, plus it allocates
memory to store max(A, B).

SUBSET implemented as (zerop (logandc2 A B)) requires n operations
to compute the logandc2, perhaps some overhead to normalize the new bignum,
and 1 operation to compute zero, plust it allocates memory to store
the intermediate result.  This is slightly more efficient, because
ZEROP is microscopically more efficient that EQL.  (ZEROP is FALSE for
all bignums.  EQL has to look at them.)  Furthermore the intermediate
result may be smaller than the intermediate result in the logior
construct.

I draw three conclusions from this.

(1) A naive computation of subset in Common Lisp requires approximately
twice the number of operations than it should, due to missing primitives.

(2) An optimizing compiler should try to recognize the SUBSET operation
and compile it efficiently.  This may be difficult, because there are
at least two (and probably many) ways to encode this operation using the
existing Common Lisp primitives.

(3) For logical completeness, clarity and consistency of source programs
and efficient implementation of some algorithms Common Lisp should be
extended to include a logical subset operation for integers.  The name
subsetp is already used (CLtL P.279) so I propose LOGSUBSETP with
semantics equivalent to:

(defun logsubsetp (a b)
  (zerop (logandc2 a b)))

∂23-Jan-89  0946	Common-Lisp-mailer 	Order of "processing" of arguments 
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 23 Jan 89  09:45:51 PST
Received: from fafnir.think.com by Think.COM; Mon, 23 Jan 89 12:22:12 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Mon, 23 Jan 89 12:42:29 EST
Received: by verdi.think.com; Mon, 23 Jan 89 12:41:17 EST
Date: Mon, 23 Jan 89 12:41:17 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8901231741.AA12978@verdi.think.com>
To: krulwich-bruce@yale.arpa
Cc: Common-Lisp@sail.stanford.edu
In-Reply-To: Bruce Krulwich's message of Thu, 12 Jan 89 12:49:19 EST <8901121749.AA18587@ATHENA.CS.YALE.EDU>
Subject: Order of "processing" of arguments

   Date: Thu, 12 Jan 89 12:49:19 EST
   From: Bruce Krulwich <krulwich-bruce@yale.arpa>

   Michael Greenwald said:
   >Actually, CLtL pg 61 says that the arguments and parameters are
   >processed in order, from left to right.  I don't know if "processed"
   >implies "evaluated", but I always assumed (perhaps incorrectly) it did.

   Guy Steele replied:
   >I interpret this as referring to how the (fully evaluated) arguments
   >are processed during lambda-binding, not to the order in which argument
   >forms in a function call are evaluated.  After all, the arguments referred
   >to on page 61 might have come from a list given to APPLY, rather then
   >from EVAL on a function call.

   This seems vacuous to me.  Does this mean that an implementation in which a
   procedure entry point knows how many arguments its receiving (through a link
   table, for instance, or simply by counting its arguments) and constructs a
   REST-arg list before doing the binding of the required args is in violation of
   CLtL because it processes the rightmost argument before the leftmost one??  I
   hope not.

   It seems to me that as long as actuals and formals are matched up correctly
   there is no reason for the language specification to specify the order of the
   "processing" of the arguments during lambda-binding.


   Bruce Krulwich
   krulwich@cs.yale.edu

The implementation need only behave "as if" it
processed them in that way.

It is always permissible to dye one's whiskers green
and then to use so large a fan that they cannot be seen.
--Guy

∂24-Jan-89  1317	Common-Lisp-mailer 	character proposal  
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 24 Jan 89  13:16:41 PST
Date: Tue, 24 Jan 89 11:16:13 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <890124.111613.baggins@almvma>
Subject: character proposal

Below are the minimum changes going into the character proposal.
This list was presented on a foil at the Hawaii meeting.


-- some minor corrections (bugs)

-- the registry document will:
     -- be an appendix to the standard, not required
     -- reference appropriate ISO standards (only)

-- character 'index' will be changed to character 'label' throughout
     (labels are strings, not numeric values)

-- add the function char-ccs-value which takes a character object
     and coded character set name and returns the value of
     the character within that encoding.

-- add the function sgchar which is similar to sbchar but takes
     a general-string object.

-- modify char-name, name-char, and #\name  to accept character
     names of the form 'registry:label'


As decided at the Hawaii meeting, the proposal will be voted on
at the March meeting (rather than by mail).  In particular, there
were requests to partition the vote.  If you have any specific
partition you would favor (eg. vote on external-width separately),
please let us know.  (Note, the ballot is being split, not the
document).  I'll probably send out a few informal ballots to get
a feeling for the partitioning as well identifing the controversial
items.


I will be revising the document and encourage any comments to
be sent immediately.  I hope to send out a revision at the end of
this week.  If there are additional comments (on the revision)
I will repeat this process if necessary to obtain a 'clean' version
for the March vote.


∂07-Feb-89  1759	Common-Lisp-mailer 	&environment extent 
Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 7 Feb 89  17:58:33 PST
Posted-Date: Tue, 07 Feb 89 17:55:58 PST
Message-Id: <8902080156.AA04251@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.59/5.51)
	id AA04251; Tue, 7 Feb 89 17:56:01 PST
To: common-lisp@sail.stanford.edu
From: goldman@vaxa.isi.edu
Subject: &environment extent
Date: Tue, 07 Feb 89 17:55:58 PST
Sender: goldman@vaxa.isi.edu

Can someone tell me whether the ENVIRONMENT object passed as the second
parameter to a macro-expander function is specified to have DYNAMIC or
INDEFINITE extent?

Thanks,
Neil

∂12-Feb-89  1326	Common-Lisp-mailer 	File I/O  
Received: from po2.andrew.cmu.edu by SAIL.Stanford.EDU with TCP; 12 Feb 89  13:26:36 PST
Received: by po2.andrew.cmu.edu (5.54/3.15) id <AA03940> for common-lisp@sail.stanford.edu; Sun, 12 Feb 89 16:21:55 EST
Received: via switchmail; Sun, 12 Feb 89 16:21:35 -0500 (EST)
Received: from kennettsq.andrew.cmu.edu via qmail
          ID </afs/andrew.cmu.edu/service/mailqs/q005/QF.EXxTFqy00jbbE0JEMo>;
          Sun, 12 Feb 89 16:17:52 -0500 (EST)
Received: from kennettsq.andrew.cmu.edu via qmail
          ID </afs/andrew.cmu.edu/usr13/dg1v/.Outgoing/QF.0XxTEhy00jbbI6jVMz>;
          Sun, 12 Feb 89 16:16:30 -0500 (EST)
Received: from Version.6.25.N.CUILIB.3.45.SNAP.NOT.LINKED.kennettsq.andrew.cmu.edu.rt.r3
          via MS.5.6.kennettsq.andrew.cmu.edu.rt_r3;
          Sun, 12 Feb 89 16:16:29 -0500 (EST)
Message-Id: <MXxTEhy00jbbQ6jVFp@andrew.cmu.edu>
Date: Sun, 12 Feb 89 16:16:29 -0500 (EST)
From: David Greene <dg1v+@andrew.cmu.edu>
X-Andrew-Message-Size: 402+0
To: +dist+/afs/andrew.cmu.edu/usr0/postman/DistLists/Andrew-Hints.dl@andrew.cmu.edu,
        bb+andrew.programming.lisp@andrew.cmu.edu,
        common-lisp@sail.stanford.edu,
        Outbound News <outnews+ext.nn.comp.lang.lisp@andrew.cmu.edu>
Subject: File I/O

I am trying to read various types of ascii data files into a standard common
LISP program (Ibuki Common Lisp).  There are a number of ways to create streams
and such, but how can I test for an End Of File so that my read won't return an
error?

I have gone through Steele, but apparently the appropriate function has eluded
me.  Thanks for any help.


-David

dg1v@andrew.cmu.edu
dpg@isl1.ri.cmu.edu

∂12-Feb-89  1353	Common-Lisp-mailer 	File I/O  
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 12 Feb 89  13:53:21 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 537730; Sun 12-Feb-89 16:51:03 EST
Date: Sun, 12 Feb 89 16:50 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: File I/O
To: dg1v+@andrew.cmu.edu
cc: Common-Lisp@SAIL.Stanford.EDU
In-Reply-To: <MXxTEhy00jbbQ6jVFp@andrew.cmu.edu>
Message-ID: <890212165052.3.KMP@BOBOLINK.SCRC.Symbolics.COM>

There's not a separate function. Most reader functions (eg, READ and READ-LINE)
take an eof-p argument that says whether to signal an error if you read past
the end of a file. The default is T, but if you specify NIL then you can specify
a value to be returned when you have read past the end of file. Here are some
examples:

 (DEFUN SHOW-FILE (FILE)
   (WITH-OPEN-FILE (STREAM FILE)
     (DO ((LINE (READ-LINE STREAM NIL NIL) (READ-LINE STREAM NIL NIL)))
         ((NOT LINE))
       (WRITE-LINE LINE))))

 (DEFUN GET-LISP-FORMS-FROM-FILE (FILE)
   (WITH-OPEN-FILE (STREAM FILE)
     (LET ((UNIQUE (LIST NIL)))
       (DO ((FORM (READ STREAM NIL UNIQUE) (READ STREAM NIL UNIQUE))
            (RESULT '() (CONS FORM RESULT)))
           ((EQ FORM UNIQUE) (NREVERSE RESULT))))))

By the way, the Common-Lisp list is -very- large (probably many hundreds of
recipients) and probably overkill for this kind of simple `how to' question.
Contacting your vendor or individually contacting just about any one of the
people you see contributing to this list would probably have gotten you the
same answer at lower cost to the community.

∂16-Feb-89  1402	Common-Lisp-mailer  
Received: from NMFECC.ARPA by SAIL.Stanford.EDU with TCP; 16 Feb 89  14:02:13 PST
Received: from tuva.sainet.mfenet by ccc.mfenet with Tell via MfeNet ;
	Thu, 16 Feb 89 13:59:35 PST
Date:	  Thu, 16 Feb 89 13:59:35 PST
From:     POTHIERS%TUVA.SAINET.MFENET@NMFECC.ARPA
Message-Id: <890216135935.20800216@NMFECC.ARPA>
To:       common-lisp@sail.stanford.edu

Subject: WANTED: Code Profiler
Date:    Thu, 16-FEB-1989 14:57 MST
X-VMS-Mail-To: ARPA%"common-lisp%sail.stanford.edu@nmfecc.arpa"

Does any have (or know where I can get) a Common Lisp code profiler?
I'm interested in something that will give be number of invocations &/or
caller &/or timing information for all the user written functions
in my system. I would really like to profile some of our stuff
that uses PCL too. I don't mind having to hack at the code some to
make it suit my puposes.

Please direct any advice to me directly at:
pothiers%tuva.sainet@nmfecc.arpa

Thanks,
Steve Pothier
Science Applications International Corporation
Tucson

∂22-Feb-89  1330	Common-Lisp-mailer 	cs proposal part1   
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 22 Feb 89  13:28:49 PST
Date: Wed, 22 Feb 89 00:13:28 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <890222.001328.baggins@almvma>
Subject: cs proposal part1




\documentstyle{report}     % Specifies the document style.

\pagestyle{headings}

\title{\bf
Extensions to Common LISP to Support International
Character Sets}
\author{
Michael Beckerle\thanks{Gold Hill Computers} \and
Paul Beiser\thanks{Hewlett-Packard} \and
Jerry Duggan\thanks{Hewlett-Packard} \and
Robert Kerns\thanks{Independent consultant} \and
Kevin Layer\thanks{Franz, Inc.} \and
Thom Linden\thanks{IBM Research, Subcommittee Chair} \and
Larry Masinter\thanks{Xerox Research} \and
David Unietis\thanks{Lucid, Inc.}
}
\date{February 21, 1989} % Deleting this command produces today's date.

\begin{document}

\maketitle                 % Produces the title.

\setcounter{secnumdepth}{4}

\setcounter{tocdepth}{4}
\tableofcontents


%----------------------------------------------------------------------
%----------------------------------------------------------------------
\newfont{\cltxt}{cmr10}
\newfont{\clkwd}{cmtt10}

\newcommand{\apostrophe}{\clkwd '}
\newcommand{\bq}{\clkwd\symbol{'22}}


%----------------------------------------------------------------------
%----------------------------------------------------------------------
\chapter{Introduction}

This is a proposal to the X3 J13 committee
for both extending and modifying the Common LISP
language definition to provide a standard basis for Common LISP
support of the variety of characters used to represent the
native languages of the international community.

This proposal was created by the Character Subcommittee of X3 J13.
We would like to acknowledge discussions with T. Yuasa and other
members of the JIS Technical Working Group,
comments from members of X3 J13,
and the proposals \cite{ida87},
\cite{linden87}, \cite{kerns87}, and \cite{kurokawa88} for
providing the motivation and direction for these extensions.
As all these documents and discussions were created
expressly for LISP standardization usage,
we have borrowed freely from their ideas as well as the texts
themselves.

This document is separated into two parts. The first part explains the
major language changes and their motivations. While intended as
commentary to a general audience, and not explicitly as
part of the standard document, the X3 J13 editor may
include sections at her/his discretion.  The second part,
Appendix A, provides
the page by page set of editorial changes to \cite{steele84}.
\section{Objectives}

The major objectives of this proposal are:
\begin{itemize}
\item To provide a consistent, well-defined scheme allowing support
of both very large character sets and multiple character sets.
\footnote{The distinction between the terms {\em character repertoire}
and {\em coded character set} is made later.  The usage
of the term {\em character set},
avoided after this introduction, encompasses both terms.}

Many software applications are intended for international use, or
have requirements for incorporation of language elements of multiple
native languages within a single application.
Also, many applications require specialized languages including,
for example, scientific and typesetting symbols.
In order
to ensure some portability of these applications, data expressed in
a mixture of these
languages must be treated uniformly by the
software language.

All character and string manipulations should operate uniformly,
regardless of the character set(s) of the character objects.
This applies to array indexing, readtable definitions, read
symbol construction and I/O operations.


\item To ensure efficient performance of string and character
operations.

Many native
languages, such as Japanese and Chinese, use character
sets which contain more characters than the Latin alphabet.
Supporting larger sized character sets frequently means employing
larger data fields to uniquely encode each character.
Common LISP implementations using
larger sized character sets can
incur performance penalties in terms
of space, time, or both.

The use of large and/or multiple character sets by an
implementation
implies the need for a more complex character type representation.
Given a more complex character representation, the efficiency
of language operations on characters (e.g. string operations)
could be affected.

\item To assure forward compatibility of the proposed model
and definition with existing Common LISP implementations.

Developers should not be required to re-write large amounts of either
LISP code or data representations in order to apply the proposed
changes to existing implementations.
The proposed changes should provide an easy
portability path for existing code to many possible implementations.
\end{itemize}

There are a number of issues, some under the general rubric of
internationalization, which this proposal does {\em not} cover.
Among these issues are:
\begin{itemize}
\item Time and date formats
\item Monetary formats
\item Numeric punctuation
\item Fonts
\item Lexicographic orderings
\item Right-to-left and bidirectional languages
\end{itemize}

%----------------------------------------------------------------------
%----------------------------------------------------------------------
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\chapter{Overview}

We use several terms within this document which
are new in the context of Common LISP.
Definitions for the following prominent
terms are provided for the reader's convenience.

A {\em character repertoire} defines a collection of characters
independent of their specific rendered image or font.  This
corresponds to the mathematical notion of a {\em set}
\footnote{We avoid the term {\em character set} as it has been
(over)used in the context of character repertoire as well
as in the context of coded character set.}.
Character
repertoires are specified independent of coding and their characters
are only identified with a unique {\em character label},
a graphic symbol, and
a character description.

A {\em coded character set} is a character repertoire plus
an {\em encoding} providing a unique mapping between each character
and a number which serves as the character representation.
There are numerous internationally standardized coded character
sets; for example, \cite{iso8859/1} and \cite{iso646}.

A character may be included in one or more character repertoires.
Similarly, a character may be included in one or more
coded character sets.  For example, the Latin letter "A" is contained
in the coded character set standards: ISO 8859/1, ISO 8859/2,
ISO 6937/2, and others.

To universally identify each character, we define a unique
collection of repertoires called {\em character
registries} as a partitioning of all characters.
That is, each character is included
in one and only one character registry.

In Common LISP a {\em character} data object is identified by its
{\em character code}, a unique numerical code.
Each character code is composed from
a character registry and a character label.

Character data objects which are classified as {\em graphic},
or displayable, are each associated with a {\em glyph}.  The
glyph is the visual representation of the character.

The primary purpose of introducing these terms is to provide a
consistent naming to Common LISP concepts which are related
to those found in ISO standardization of coded
character sets.
\footnote{The bibliography includes several relevant ISO
coded character set standards.}
They also serve as a demarcation between these
standardization activities.  For example, while Common LISP is free to
define unique manipulation facilities for characters, registries
and coded character sets, it should
not define standard coded character sets nor standard character
registries.

A secondary purpose is to detach the language specification from
underlying hardware representation.  From a language
specification viewpoint it is inconsequential whether
characters occupy one or more (8-bit) bytes or whether
a Common LISP implementation's
internal representation for characters is distinct from or identical
to any of the numerous
external representations (for example, the text interchange
representation \cite{iso6937/2}).
We specifically do not propose any standard coded character sets.

%----------------------------------------------------------------------
\section{Character Identity}


Characters are uniquely distinguished by their codes,
which are drawn from the set of
non-negative integers.  That is, within Common LISP
a unique numerical code
is assigned to each semantically different character.

It is important to separate the notion of glyph from the notion of
character data object when defining a scheme under which issues of
identity can be rigorously decided by a computer language.  Glyphs are
the visual aspects of characters, writable on surfaces, and sometimes
called 'graphics'.  A language specification valid for more than a
narrow range of systems can only make assumptions about the existence
of {\em abstract} glyphs (for example, the Latin letter A) and not about
glyph variants (for example, the italicized Latin letter {\em A})
or characteristics of display devices.  Thus, an important element of
this proposal is the removal of the {\em font} and {\em bits}
attributes from the language specification.
\footnote{These and other attributes may still be supported as
implementation-defined extensions.}
All functions
dealing with the {\em bits} and {\em font} attributes are either
removed or modified by this proposal.
The deleted functions and constants include:
{\em char-font-limit,
char-bits-limit,
int-char,
char-int,
char-bits,
char-font,
make-char,
char-control-bit,
char-meta-bit,
char-super-bit,
char-hyper-bit,
char-bit,
set-char-bit}.

The definition in \cite{steele84} of semi-standard characters has
been eliminated.  This is replaced by a more uniform approach
to character naming with the introduction of character registries
(see below).


%----------------------------------------------------------------------
\section{Character Naming}

A Common LISP program must be able to name, compose and decompose
characters in a uniform, portable manner, independent of any
underlying representation.  One possible composition is by
the pair $<$ coded character set standard, decimal representation $>$
\footnote{This syntax is for illustration only and is not being
proposed.}.
Thus, for example, one might compose the Latin 'A' with the pair
$<$ ISO8859/2-1987, 65 $>$,
$<$ ISO8859/6-1987, 65 $>$, or
$<$ ISO646-1983, 65 $>$, etc..  The difficulty here is two-fold.
First, there are several ways to compose the same character and
second, there may be multiple answers to
the question: {\em To what coded character set
does character object x belong?}.\footnote{Even
worse, the answer might change yearly.}
The identical problems occur if the pair
$<$ character repertoire standard, decimal representation $>$ is used.
\footnote{Existing ISO repertoires seem to be defined exclusively
in the context of coded character sets and not as standards
in their own right.}

The concept of character registry is introduced by this proposal
to resolve the problem of character naming, composition and
decomposition.
Each character is universally defined by the
pair $<$ character registry name, character label $>$. For this
to be a portable definition, it must have a standard meaning.
Thus we propose the formation of an ISO Working Group to
define an international
{\em Character Registry Standard}.
At this writing there is no existing Character Registry Standard nor
ISO Working Group organized to define such a standard.
\footnote{It is the intention of X3 J13 to promote and adopt
an eventual ANSI or ISO Character Registry Standard.  In particular, we
acknowledge that X3 J13 is {\em not} the appropriate forum to
define the standard.  We believe
it is a required component of all programming languages
providing support for international characters.}

Common LISP character codes are composed from a character registry and
a character label.  The convention by which a character label and
character registry compose a character code is implementation
dependent.

We introduce new functions {\clkwd find-char, char-registry-name,} and
{\clkwd char-label} to
compose and decompose character objects.  We also extend the
{\clkwd characterp} predicate to
support testing
membership of a character in a given character registry.
\footnote{
For example,
testing membership in the Japanese Katakana character registry.
}
A global variable {\clkwd *all-character-registry-names*}
is added to
support application determination of supported character registries.

The naming and content of the standard character registries
is left unspecified by this proposal.
\footnote{The only constraint is that character registries be
named using only {\clkwd standard-p} characters.}
Below are some candidate character registry names:
\begin{itemize}
\item Arabic
\item Armenian
\item Bo-po-mo-fo
\item Control   (meaning the collection of standard text communication
control codes)
\item Cyrillic
\item Georgian
\item Greek
\item Hangul
\item Hebrew
\item Hiragana
\item Japanese-Punctuation
\item Kanji
\item Katakana
\item Latin
\item Latin-Punctuation
\item Mathematical
\item Pattern
\item Phonetic
\item Technical
\end{itemize}
The list above is provided as a starting point for discussion
and is not intended to be representative
nor exhaustive.  The Common LISP language definition does not
depend on these names nor any specific content (for example:
Where should the plus sign appear?).  It is application
programs which require a reliable definition of the
registry names and their constituents.  The Common LISP language
definition imposes the framework for constructing and manipulating
character objects.

The proposed ISO Character Registry Standard is fixed;
an implementation may not extend a standard registry's
constituent set of characters beyond the
standard definition.

An implementation may provide support for all or part of any
character registry
and may provide new character registries which include characters
having unique semantics (i.e. not defined in any standard
character registry).
Implementation registries must be uniquely
named using only {\clkwd standard-p} characters.

An implementation must document the registries it supports.
For each registry supported the documentation must include
at least the following:
\begin{itemize}
\item Character Labels,
Glyphs, and Descriptions.
\item Reader Canonicalization.
\item Effect of character predicates.
In particular,
\begin{itemize}
\item {\clkwd alpha-char-p}
\item {\clkwd lower-case-p}
\item {\clkwd upper-case-p}
\item {\clkwd both-case-p}
\item {\clkwd graphic-char-p}
\item {\clkwd alphanumericp}
\end{itemize}
\item Interaction with File I/O.  In particular, the
coded character sets
\footnote{For example, ISO8859/1-1987.} and
external encoding schemes
\footnote{For example, {\em Xerox System Integration Character
Code Standard}\cite{xerox87}.}
supported are documented.
\end{itemize}

Which coded character sets and encoding schemes
are supported by the overall computing system, the
details of the mapping of glyphs to characters
to character codes are
left unspecified by Common LISP.

The diversity of glyph sets and coded character
set conventions in use worldwide and the desirability
of allowing Common LISP applications
to portabily manipulate symbolic elements from many
languages, perhaps simultaneously, mandate such a flexible approach.

%----------------------------------------------------------------------
\section{Hierarchy of Types}

Providing support for extensive character repertoires may
impact Common LISP implementation performance in terms
of space, time, or both.
\footnote{This does not apply to all implementations.
Unique hardware support and user community requirements must
be taken into consideration.}
In particular, many existing
implementations support variants of the ISO 8859/1 standard.
Supporting large
repertoires argues for a multi-byte internal representation
for each character, even if an application primarily (or exclusively)
uses the ISO 8859/1 characters.

This proposal extends the definition of the character and string
type hierarchy to include specialized subtypes
of character and string.  An implementation is free to associate
compact internal representation tailored to each subtype.
The {\clkwd string} type specifier, when used for object
creation, for example in {\clkwd make-sequence},
is defined to mean the most general string subtype supported
by the implementation (similarily for the {\clkwd simple-string}
type specifier).  This definition emphasizes portability
of existing Common LISP applications to international
character environments over performance.  Applications emphasizing
efficiency of text processing in non-international environments
will require some modification to utilize subtypes with
compact internal representations.

It has been suggested that either a single type is
sufficient to support international characters,
or that a hierarchy of types could be used, in a manner
transparent to the user.  A desire to provide flexibility which
encourages implementations to support international
characters without compromising application efficiency
led us to accept the need for more than one type.
We believe that these choices reflect a minimal
modification of this aspect of the type system, and that
exposing the types for string and character construction while
requiring uniform treatment for characters otherwise
is the most reasonable approach.

\subsection{Character Type}

The following type specifier is added as a subtype
of {\clkwd character}:
\begin{itemize}
\item {\clkwd base-character}
\end{itemize}

An implementation may support additional subtypes of {\clkwd character}
which may or may not be supertypes of {\clkwd base-character}.
In addition, an implementation may define {\clkwd base-character}
as equivalent to {\clkwd character}.

Characters of type {\clkwd base-character} are referred to as
{\em base characters}.  Characters of type {\clkwd
(and character (not base-character))}
are referred to as {\em extended characters}.
The base characters are
distinguished in the following respects:
\begin{itemize}
\item
The standard characters are a subrepertoire of the base characters.
The selection of base characters which are not standard characters
is implementation defined.
\item
Only members of the base character repertoire
can be elements of a base string.
\item
The base characters are, in general, the default characters for I/O
operations.
\end{itemize}
No upper bound is specified for the number of glyphs in the base
character repertoire--that
is implementation dependent.  The lower bound is 96, the
number of standard characters defined for Common LISP.
\footnote{Or, in contrast, the base repertoire may include all
implementation supported characters.}

The distinction of base characters is largely a pragmatic
choice.  It permits efficient handling of common situations, is
in some sense privileged for host system I/O, and can serve as an
intermediate basis for portability, less general than the standard
characters, but possibly more useful across a narrower range of
implementations.

Many computers have some "base" character representation which
is a function of hardware instructions for dealing with characters,
as well as the organization of the file system.  The base character
representation is likely to be the smallest transaction unit permitted
for text file and terminal I/O operations.  On a system with a record
based I/O paradigm, the base character representation is likely to
be the smallest record quantum.  On many computer systems,
this representation is a byte.

However, there are often multiple
coded character sets supportable on a
computer, through the use of special display and entry hardware, which
are varying interpretations of the basic system character
representation.  For example, ISO 8859/1 and ISO 6937/2 are two
different interpretations of the same 1-byte code representations.
Many countries have their own glyph-to-code mappings for 1-byte
character codes addressing the special requirements of national
languages.  Differentiating between these, without reference to
display hardware, is a matter of convention, since they all use the
same set of code representations.  When a single byte is not enough,
two or more bytes are sometimes used for character encoding.  This
makes character handling even more difficult on machines where the
natural representation size is a byte, since not only is the semantic
value of a character code a matter of convention, which may vary
within the same computing system, but so is the identification of a
set of bits as a complete character code.

It is the intention of this proposal that the composition of
base characters is typically
determined by the code capacity of the natural file system and I/O
transaction representations, and the assumed display glyphs should be
those of the terminals most commonly employed.
There are several advantages to this scheme.  Internal representation
of strings of just base characters can be more compact than
strings including extended characters.
Source programs are likely to consist predominantly of base characters
since the standard characters are a subset of the base character
repertoire. Parsing of pure base character text
can be more efficient than parsing of text including
extended characters.
I/O can be performed more simply
with base characters.

The standard characters are the 96 characters used in the Common LISP
definition {\bf or their equivalents}.

This was the Common LISP \cite{steele84} definition, but
{\em equivalents} is a vague term.

The standard characters are not defined by their glyphs, but by their
roles within the language.  There are two aspects to the roles of the
standard characters: one is their role in reader and format control
string syntax; the second is their role as components of the names of
all Common LISP
functions, macros, constants, and global variables.  As
long as an implementation chooses 96 glyphs
and treats those 96 in a manner consistent with
the language's specification for the standard characters (e.g.
the naming of functions), it doesn't matter what glyphs the I/O
hardware uses to represent those characters: they are the standard
characters.  Any program or
data text written wholly in those characters
is portable through simple code conversion.
\footnote{For example, the currency glyph, \$ , might be replaced
uniformly by the currency glyph available on a particular display.}

Additional
mechanisms, such as in \cite{linden87}, which support establishment of
equivalency between otherwise distinct characters are not excluded by
this proposal.
\footnote{We believe this is an important issue but it requires
additional implementation experience.  We also encourage
new proposals from JIS and ISO LISP Working Groups on this issue.}

\subsection{String Type}

The {\clkwd string} type
is defined as
a vector of characters.  More precisely, a string
is a specialized vector whose elements are of type
{\clkwd character} or a subtype of character.  Similarly, a simple
string is a specialized simple vector whose elements are of type
{\clkwd character} or a subtype of character.  The following string
subtypes are
distinguished with standardized names: {\clkwd base-string},
{\clkwd general-string}, {\clkwd simple-base-string}, and
{\clkwd simple-general-string}.
All strings which are not base strings
are referred to as {\em extended strings}.

A base string can only contain base characters.
{\clkwd general-string} is equivalent to {\clkwd (vector character)}
and can contain any implementation supported base or extended characters,
in any mixture.

All Common LISP functions defined to operate on strings treat
base and extended strings uniformly with the following
caveat: for any function which inserts a character into a string, it
is an error to insert an extended character
into a base string.
\footnote{An implementation may, optionally, provide automatic
coersion to an extended string.}

An implementation may support string subtypes in addition
to {\clkwd base-string} and
{\clkwd general-string}.
For example, a hypothetical
implementation supporting Arabic and Cyrillic character registries
might provide as extended characters:
\begin{itemize}
\item {\clkwd general-string} -- may contain Arabic, Cyrillic or
base characters in any mixture.
\item {\clkwd region-specialized-string} -- may contain installation
selected repertoire (Arabic/Cyrillic) or base characters in any
mixture.
\item {\clkwd base-string} -- may contain base characters
\end{itemize}
Though, clearly, portability of applications using
{\clkwd region-specialized-string} is limited, a performance
advantage might argue for its use.
\footnote{{\clkwd region-specialized-string} is used here for
illustration only; it is not being proposed as a standardized
string subtype.}

Alternatively,
an implementation
supporting a large base character repertoire
including, say, Japanese Kanji may define
{\clkwd base-character}
as equivalent to {\clkwd character}.

We expect that applications sensitive to the performance
of character handling in some host environments will
utilize the string subtypes to provide performance
improvement.  Applications with emphasis on international
portability will likely utilize only {\clkwd general-string}s.

The {\clkwd coerce} function is extended to
allow for explicit coercion between base strings and extended strings.
It is an error to coerce an extended character to a base character.

During reader
construction of symbols, if all the characters
in the symbol's name are of type {\clkwd base-character},
then the name of the symbol may be stored as a base string.
Otherwise it will be stored as an extended string.

The base string type allows for more compact representation of strings
of base characters, which are likely to predominate in any system.
Note that in any particular implementation the base characters
need not be the
most compactly representable, since others might have
a smaller repertoire.
However, in most implementations base strings are
likely to be more space efficient than extended strings.


%----------------------------------------------------------------------
\section{Streams and System I/O}

A lot of the work of ensuring that a
Common LISP implementation operates correctly in a
multiple coded character set environment must be performed by
the I/O interface.
The system I/O interface, abstracted in
Common LISP as streams, is responsible
for ensuring that text input from outside LISP is properly mapped
into character objects internally, and that the inverse mapping
is performed on output.  It is beyond the scope of a language
definition to specify the details of this operation, but options
are specified which allow runtime indication from the user as to
what coded character sets a stream uses, and how the mappings
should be done.  It is expected that implementations will provide
reasonable defaults and invocation options to accommodate desired use
at an installation.

One keyword argument is proposed as an addition to {\clkwd open}:
\begin{itemize}
\item {\clkwd :external-coded-character-format}
whose value would be:
\begin{itemize}
\item
A name or list of names indicating an implementation recognized
scheme for representing 1 or more coded character sets.
\footnote{
For example, the so/si convention used by IBM on 370
machines could be selected by a list including
the name {\clkwd :ibm-shift-delimited}.
The run-encoding convention defined by XEROX could be
selected by {\clkwd :xerox-run-encoded}.
The convention based on
ASCII which uses leading bit patterns to distinguish two-byte codes
from one-byte codes could be selected by
{\clkwd :ascii-high-byte-delimited}.
}
As many coded character set names must be provided as the
implementation requires for that external coding convention.
\footnote{
For example, if {\clkwd :ibm-shift-delimited} were the
argument, two
coded character set specifiers would have to be provided.
}
\end{itemize}
\end{itemize}

These arguments are provided for input, output, and
bidirectional streams.
It is an error to try to write a character other than a
member of the specified coded character sets
to a stream.  (This excludes the
\#$\backslash${\clkwd Newline} character.
Implementations must provide appropriate line division behavior
for all character streams.)

An implementation supporting multiple coded character sets
must allow for the external
representation of characters to be separately (and perhaps
multiply) specified to {\clkwd open},
since there can be circumstances under
which more than one external representation for characters
is in use, or more than one coded character set
is mixed together in an
external representation convention.

In addition to supporting conversion at the system interface, the
language must allow user programs to determine how much space data
objects will require when output in whichever external representations
are available.

The new function {\clkwd external-coded-string-length}
takes a character
or string object as its required argument.  It also takes an optional
{\em output-stream}.
It returns the number of implementation-defined
representation units
\footnote{
Often the same as the storage width of a base character, usually a byte.
}
required to externally store that object, using the
representation convention associated with the stream.
If the object cannot be represented in
that convention, the function returns {\clkwd nil}.
This function is necessary
to determine if strings can be written to fixed length
fields in databases or terminal screen templates.  Note that this
function does not
address the problem of calculating
screen width of strings printed in proportional fonts.

Related to the I/O interface,
we also introduce the function {\clkwd char-ccs-value}
which takes a character object and a coded character set name
(eg. {\clkwd :ISO8859/1-1987}) and returns the encoding of
the character within the coded character set.

%----------------------------------------------------------------------
%----------------------------------------------------------------------

∂22-Feb-89  1332	Common-Lisp-mailer 	cs proposal revisions    
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 22 Feb 89  13:32:18 PST
Date: Wed, 22 Feb 89 00:36:12 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <890222.003612.baggins@almvma>
Subject: cs proposal revisions

I've sent out a revised cs document for your review.  It reflects
a number of your comments from the Hawaii meeting and over the
net.  The larger changes were:

  --  The 'depreciated' appendix is eliminated.  I re-introduced
      the list of implementation-dependent attribute support
      items into the document proper.  The other items in
      appendix B were simply eliminated.

  --  The functions sbchar and sgchar are eliminated.  In general,
      the comments indicate that case discrimination by schar
      does not introduce a substantial performance penalty.

  --  Character registry names and constituents are NOT defined by
      Common LISP.  The proposal defines only the framework for
      composition and decomposition of characters.  The naming
      of registries and definition of their constituents are
      left completely as an ISO standard activity.

  --  Character registry names and constituents are NOT defined by
      Common LISP.  The proposal defines only the framework for
      composition and decomposition of characters.  The naming
      of registries and definition of their constituents are
      left completely as an ISO standard activity.


  Please send comments to the X3J13 mailing list.  If time allows
  and it seems needed, I will send out another revision in time to
  allow for an actual vote at the March meeting.  A straw vote list
  will follow shortly.

Regards,
  Thom

∂22-Feb-89  1332	Common-Lisp-mailer 	cs proposal part 2  
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 22 Feb 89  13:30:31 PST
Date: Wed, 22 Feb 89 00:14:09 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <890222.001409.baggins@almvma>
Subject: cs proposal part 2

%----------------------------------------------------------------------
%----------------------------------------------------------------------

\newcommand{\edithead}{\begin{tabular}{l p{3.95in}}
  \multicolumn{2}{l} }

\newcommand{\csdag}{\bf$\Rightarrow$\ddag}

\newcommand{\editstart}{}

\newcommand{\editend}{\\ & \end{tabular}}

%----------------------------------------------------------------------
%----------------------------------------------------------------------
\appendix
\chapter{Editorial Modifications to CLtL}

The following sections specify the editorial changes needed in
CLtL to support the proposal.  Section/subsection numbers and titles
match those found in \cite{steele84}.  The notation
{\csdag x (pn, function)} denotes a reference to paragraph x within the
subsection (we count each individual example or metastatement
as 1 paragraph of text).  Also, {\bf (pn, function)}, or simply
{\bf (pn)} is included as an additional
aid to the reader indicating the page number and function modified.
When an entire paragraph is deleted,
the first few words of the paragraph is noted.

If a section or paragraph of CLtL is {\em not} referenced,
no editorial changes are required to support this proposal.
\footnote{This may be an over optimistic statement since the changes
are fairly pervasive.  The editor should take the sense of
Chapter 1 into account in resolving any discrepancies.}

%----------------------------------------------------------------------
\setcounter{section}{1}
\section{Data Types}                        % 2
%----------------------------------------------------------------------


\edithead {\csdag 8 (p12)}
\editstart
\\ \bf replace &
\cltxt
   provides for a
   rich character set, including ways to represent characters of various
   type styles.
\\ \bf with &
\cltxt
   provides support for international language characters as well
   as characters used in specialized arenas, eg. mathematics.
\editend

\setcounter{subsection}{1}
\subsection{Characters}                     % 2.2.

\edithead {\csdag 1 (p20)}
\editstart
\\ \bf replace &
\cltxt
  Characters are represented as data objects of type {\clkwd character}.
  There are two subtypes of interest, called
  {\clkwd standard-char} and {\clkwd string-char}.
\\ \bf with &
\cltxt
  Characters are represented as data objects of type
  {\clkwd character}.
\editend
\\
\edithead {\csdag 2 (p20)}
\editstart
\\ \bf replace &
\cltxt
  This works well enough for printing characters. Non-printing
  characters
\\ \bf with &
\cltxt
  This works well enough for graphic characters.  Non-graphic
  characters
\editend

\subsubsection{Standard Characters}         % 2.2.1.

\edithead {\csdag 1 before (p20)}
\editstart
\\ \bf insert &
\cltxt
  A {\em character repertoire} defines a collection of characters
  independent of their specific rendered image or font.
  Character
  repertoires are specified independent of coding and their characters
  are only identified with a unique label, a graphic symbol, and
  a character description.
  A {\em coded character set} is a character repertoire plus
  an {\em encoding} providing a unique mapping between each character
  and a number which serves as the character representation.
\\ &
  Common LISP requires all implementations to support a {\em standard}
  character subrepertoire.  Typically, an implementation
  incorporates the standard
  characters as a subset of a larger repertoire corresponding
  to a frequently used set of characters, or base coded character
  set.
  The term {\em base character repertoire} refers to
  the collection of characters represented by
  the base coded character set.
\editend
\\
\edithead {\csdag 1 before (p20)}
\editstart
\\ \bf insert &
\cltxt
  The {\clkwd base-character} type is defined as a subtype of
  {\clkwd character}.  A {\clkwd base-character}
  object can contain any member of the base character repertoire.
  Objects of type
  {\clkwd (and character (not base-character))} are referred to
  as {\em extended characters}.
\editend
\\
\edithead {\csdag 1 (p20)}
\editstart
\\ \bf delete &
\cltxt
  Common LISP defines a "standard character set" ...
\editend
\\
\edithead {\csdag 1 (P20)}
\editstart
\\ \bf new &
\cltxt
  The Common LISP
  standard character subrepertoire consists of
  a newline \#$\backslash${\clkwd Newline}, the
  graphic space character \#$\backslash${\clkwd Space},
  and the following additional
  ninety-four graphic characters or their equivalents:
\editend
\\
\edithead {\csdag 2 (p21)}
\editstart
\\ \bf delete &
\cltxt
  ! " \# ...
\editend
\\
\edithead {\csdag 2 new (p21)}
\editstart
\\ &
  {\bf Common LISP Standard Character Subrepertoire}
\editend
\footnote{\cltxt \#$\backslash${\clkwd Space}
and \#$\backslash${\clkwd Newline} are omitted.
graphic labels and descriptions are from ISO 6937/2.
The first letter of the graphic label categorizes the
character as follows: L - Latin, N - Numeric, S - Special
.}
\\
{\small \begin{tabular}{||l|c|l||l|c|l||}    \hline
  Label  &    Glyph    &  Name or description
& Label  &    Glyph    &  Name or description
\\ \hline
  LA01  &  a  &  small a
& ND01  &  1  &  digit 1
\\ \hline
  LA02  &  A  &  capital A
& ND02  &  2  &  digit 2
\\ \hline
  LB01  &  b  &  small b
& ND03  &  3  &  digit 3
\\ \hline
  LB02  &  B  &  capital B
& ND04  &  4  &  digit 4
\\ \hline
  LC01  &  c  &  small c
& ND05  &  5  &  digit 5
\\ \hline
  LC02  &  C  &  capital C
& ND06  &  6  &  digit 6
\\ \hline
  LD01  &  d  &  small d
& ND07  &  7  &  digit 7
\\ \hline
  LD02  &  D  &  capital D
& ND08  &  8  &  digit 8
\\ \hline
  LE01  &  e  &  small e
& ND09  &  9  &  digit 9
\\ \hline
  LE02  &  E  &  capital E
& ND10  &  0  &  digit 0
\\ \hline
  LF01  &  f  &  small f
& SC03  &  \$    &  dollar sign
\\ \hline
  LF02  &  F  &  capital F
& SP02  &  !     &  exclamation mark
\\ \hline
  LG01  &  g  &  small g
& SP04  &  "     &  quotation mark
\\ \hline
  LG02  &  G  &  capital G
& SP05  &  \apostrophe     &  apostrophe
\\ \hline
  LH01  &  h  &  small h
& SP06  &  (     &  left parenthesis
\\ \hline
  LH02  &  H  &  capital H
& SP07  &  )     &  right parenthesis
\\ \hline
  LI01  &  i  &  small i
& SP08  &  ,     &  comma
\\ \hline
  LI02  &  I  &  capital I
& SP09  &  \_    &  low line
\\ \hline
  LJ01  &  j  &  small j
& SP10  &  -     &  hyphen or minus sign
\\ \hline
  LJ02  &  J  &  capital J
& SP11  &  .     &  full stop, period
\\ \hline
  LK01  &  k  &  small k
& SP12  &  /     &  solidus
\\ \hline
  LK02  &  K  &  capital K
& SP13  &  :     &  colon
\\ \hline
  LL01  &  l  &  small l
& SP14  &  ;     &  semicolon
\\ \hline
  LL02  &  L  &  capital L
& SP15  &  ?     &  question mark
\\ \hline
  LM01  &  m  &  small m
& SA01  &  +     &  plus sign
\\ \hline
  LM02  &  M  &  capital M
& SA03  &  $<$   &  less-than sign
\\ \hline
  LN01  &  n  &  small n
& SA04  &  =   &  equals sign
\\ \hline
  LN02  &  N  &  capital N
& SA05  &  $>$   &  greater-than sign
\\ \hline
  LO01  &  o  &  small o
& SM01  &  \#    &  number sign
\\ \hline
  LO02  &  O  &  capital O
& SM02  &  \%    &  percent sign
\\ \hline
  LP01  &  p  &  small p
& SM03  &  \&    &  ampersand
\\ \hline
  LP02  &  P  &  capital P
& SM04  &  *     &  asterisk
\\ \hline
  LQ01  &  q  &  small q
& SM05  &  @     &  commercial at
\\ \hline
  LQ02  &  Q  &  capital Q
& SM06  &  [     &  left square bracket
\\ \hline
  LR01  &  r  &  small r
& SM07  &  $\backslash$   &  reverse solidus
\\ \hline
  LR02  &  R  &  capital R
& SM08  &  ]     &  right square bracket
\\ \hline
  LS01  &  s  &  small s
& SM11  &  \{    &  left curly bracket
\\ \hline
  LS02  &  S  &  capital S
& SM13  &  $|$     &  vertical bar
\\ \hline
  LT01  &  t  &  small t
& SM14  &  \}    &  right curly bracket
\\ \hline
  LT02  &  T  &  capital T
& SD13  &  \bq   &  grave accent
\\ \hline
  LU01  &  u  &  small u
& SD15  &  $\hat{ }$  &  circumflex accent
\\ \hline
  LU02  &  U  &  capital U
& SD19  &  $\tilde{ }$ &  tilde
\\ \hline
  LV01  &  v  &  small v
& & &
\\ \hline
  LV02  &  V  &  capital V
& & &
\\ \hline
  LW01  &  w  &  small w
& & &
\\ \hline
  LW02  &  W  &  capital W
& & &
\\ \hline
  LX01  &  x  &  small x
& & &
\\ \hline
  LX02  &  X  &  capital X
& & &
\\ \hline
  LY01  &  y  &  small y
& & &
\\ \hline
  LY02  &  Y  &  capital Y
& & &
\\ \hline
  LZ01  &  z  &  small z
& & &
\\ \hline
  LZ02  &  Z  &  capital Z
& & &
\\
\hline
\end{tabular} }
\\
\edithead {\csdag 3 (p21)}
\editstart
\\ \bf delete &
\cltxt
  @ A B C...
\editend
\\
\edithead {\csdag 4 (p21)}
\editstart
\\ \bf delete &
\cltxt
  \bq a b c...
\editend
\\
\edithead {\csdag 5 (p21)}
\editstart
\\ \bf delete &
\cltxt
  The Common LISP Standard character set is apparently ...
\editend
\\
\edithead {\csdag 6 (p21)}
\editstart
\\ \bf replace &
\cltxt
  Of the ninety-four non-blank printing characters
\\ \bf with &
\cltxt
  Of the ninety-five graphic characters
\editend
\\
\edithead {\csdag 9 (p21)}
\editstart
\\ \bf delete &
\cltxt
  The following characters are called ...
\editend
\\
\edithead {\csdag 10 (p21)}
\editstart
\\ \bf delete &
\cltxt
  {\clkwd \#$\backslash$Backspace \#$\backslash$Tab } ...
\editend
\\
\edithead {\csdag 11 (p21)}
\editstart
\\ \bf delete &
\cltxt
  Not all implementations of Common ...
\editend

\subsubsection{Line Divisions}              % 2.2.2.

\edithead {\csdag 6 (p22)}
\editstart
\\ \bf replace &
\cltxt
  a two-character sequence, such as
  {\clkwd \#$\backslash$Return } and then
  {\clkwd \#$\backslash$Newline },
  is not acceptable,
\\ \bf with &
\cltxt
  a two-character sequence is not acceptable,
\editend
\\
\edithead {\csdag 8 (p22)}
\editstart
\\ \bf delete &
\cltxt
  Implementation note: If an implementation uses ...
\editend

\subsubsection{Non-standard Characters}     % 2.2.3.

\edithead {\csdag delete entire section (p23)}
\editstart
\editend

\subsubsection{Character Attributes}        % 2.2.4.

\edithead {\csdag 0 section heading (p23)}
\editstart
\\ \bf replace &
\cltxt
  Character Attributes
\\ \bf with &
\cltxt
  Character Identity
\editend
\\
\edithead {\csdag 1 through 8 (p23)}
\editstart
\\ \bf delete all paragraphs&
\cltxt
  Every object of type {\clkwd character} ...
\editend
\\
\edithead {\csdag 1 (p23)}
\editstart
\\ \bf new &
\cltxt
Characters are uniquely distinguished by their codes,
which are drawn from the set of
non-negative integers.  That is, within Common LISP
a unique numerical code
is assigned to each semantically different character.
\\ &
Common LISP
characters are partitioned into a unique collection of
repertoires called {\em
character registries}.  That is, each character is included
in one and only one character registry.
\\ &
Character codes are composed from a character registry and a
character label.  The convention by which a character registry and
character label compose a character code is implementation
dependent.
\editend

\subsubsection{String Characters}           % 2.2.5.

\edithead {\csdag delete entire section (p23)}
\editstart
\editend

\setcounter{subsection}{4}
\subsubsection{Character Registries}           % 2.2.5.

\edithead {\csdag new section (p23)}
\editstart
\\ \bf new &
\cltxt
An implementation must document the registries it supports.
Registries must be uniquely
named using only {\clkwd standard-p} characters.
For each registry supported,
an implementation must define the individual characters supported
including at least the following:
\begin{itemize}
\item Character Labels,
Glyphs, and Descriptions.
\item Reader Canonicalization.
\item Effect of character predicates.
\begin{itemize}
\item {\clkwd alpha-char-p}
\item {\clkwd lower-case-p}
\item {\clkwd upper-case-p}
\item {\clkwd both-case-p}
\item {\clkwd graphic-char-p}
\item {\clkwd alphanumericp}
\end{itemize}
\item Interaction with File I/O.  In particular, the
coded character set standards
\footnote{For example, ISO8859/1-1987.} and
external encoding schemes
which are supported must be specified.
\end{itemize}
\editend

\subsection{Symbols}                        % 2.3.

\edithead {\csdag 12 (p25)}
\editstart
\\ \bf replace &
\cltxt
  A symbol may have uppercase letters, lowercase letters, or both
  in its print name.
\\ \bf with &
\cltxt
  A symbol may have characters from any supported character registry
  in its print name.
  It may have uppercase letters, lowercase letters, or both.
\editend

\setcounter{subsection}{4}
\subsection{Arrays}
\subsubsection{Vectors}

\edithead {\csdag 6 (p29)}
\editstart
\\ \bf replace &
\cltxt
  All implementations provide specialized arrays for the cases when
  the components are characters (or rather, a special subset of the
  characters);
\\ \bf with &
\cltxt
  All implementations provide specialized arrays for the cases when
  the components are characters (or optionally, special subsets of
  the characters);
\editend

\subsubsection{Strings}

\edithead {\csdag 1 (p30)}
\editstart
\\ \bf replace &
\cltxt
  A string is simply a vector of characters.  More precisely, a string
  is a specialized vector whose elements are of type
  {\clkwd string-char}.
\\ \bf with &
\cltxt
  A string is simply a vector of characters.  More precisely, a string
  is a specialized vector whose elements are of type
  {\clkwd character} or a subtype
  of character.
\editend

\setcounter{subsection}{14}
\subsection{Overlap, Inclusion, and Disjointness of Types} % 2.15.


\edithead {\csdag 14 (p34)}
\editstart
\\ \bf replace &
\cltxt
  The type {\clkwd standard-char} is a subtype of {\clkwd string-char};
  {\clkwd string-char} is a subtype of {\clkwd character}.
\\ \bf with &
\cltxt
  The type {\clkwd base-character} is a subtype of
  {\clkwd character}.
  The type {\clkwd string-char} is implementation defined as either
  {\clkwd base-character} or {\clkwd character}.
\editend
\\
\edithead {\csdag 15 (p34)}
\editstart
\\ \bf replace &
\cltxt
  The type {\clkwd string} is a subtype of {\clkwd vector},
  for {\clkwd string} means {\clkwd (vector string-char)}.
\\ \bf with &
\cltxt
  The type {\clkwd string} is a subtype of {\clkwd vector},
  {\clkwd string} consists of vectors specialized by subtypes of
  {\clkwd character}.
\editend
\\
\edithead {\csdag 15 after (p34)}
\editstart
\\ \bf insert &
\cltxt
  The type {\clkwd base-string} means
  {\clkwd (vector base-character)}.
\editend
\\
\edithead {\csdag 15 after (p34)}
\editstart
\\ \bf insert &
\cltxt
  The type {\clkwd general-string} means
  {\clkwd (vector character)} and is a subtype of {\clkwd string}.
\editend
\\
\edithead {\csdag 20 (p34)}
\editstart
\\ \bf replace &
\cltxt
  {\clkwd (simple-array string-char (*))};
\\ \bf with &
\cltxt
  {\clkwd (and string simple-array)};
\editend
\\
\edithead {\csdag 20 after (p34)}
\editstart
\\ \bf insert &
\cltxt
  The type {\clkwd simple-base-string} means
  {\clkwd (simple-array base-character (*))} and
  is the most efficient string which can hold
  the standard characters. {\clkwd simple-base-string}
  is a subtype of {\clkwd base-string}.
\editend
\\
\edithead {\csdag 20 after (p34)}
\editstart
\\ \bf insert &
\cltxt
  The type {\clkwd simple-general-string} means
  {\clkwd (simple-array character (*))}.
  {\clkwd simple-general-string}
  is a subtype of {\clkwd general-string}.
\editend
\\
\edithead {\csdag 22 after (p34)}
\editstart
\\ \bf replace &
\cltxt
  The type {\clkwd simple-string} is a subtype of
  {\clkwd string}. (Note that although
  {\clkwd string}
  is a subtype of {\clkwd vector, simple-string} is not
  a subtype of {\clkwd simple-vector}.
\\ \bf with &
\cltxt
  The type {\clkwd simple-string} is a subtype of
  {\clkwd string}, {\clkwd simple-string} consists of
  simple vectors specialized by subtypes of
  {\clkwd character}. (Note that although
  {\clkwd string}
  is a subtype of {\clkwd vector, simple-string} is not
  a subtype of {\clkwd simple-vector}.
\editend



%----------------------------------------------------------------------
\setcounter{section}{3}
\section{Type Specifiers}                   % 4
%----------------------------------------------------------------------
\setcounter{subsection}{1}
\subsection{Type Specifier Lists} % 4.2.


\edithead {\csdag 8 Table 4-1 (alphabetic list) (p43)}
\editstart
\\ \bf remove &
\\ &
\cltxt
  {\clkwd standard-char}
\\ &
  {\clkwd string-char}
\editend
\\
\edithead {\csdag 8 Table 4-1 (alphabetic list) (p43)}
\editstart
\\ \bf insert &
\\ &
\cltxt
  {\clkwd base-character}
\\ &
  {\clkwd base-string}
\\ &
  {\clkwd general-string}
\\ &
  {\clkwd simple-base-string}
\\ &
  {\clkwd simple-general-string}
\editend

\setcounter{subsection}{2}
\subsection{Predicating Type Specifiers} % 4.3.

\edithead {\csdag 2 (p43)}
\editstart
\\ \bf delete &
\cltxt
  As an example, the entire ...
\editend
\\
\edithead {\csdag 3 delete example (p43)}
\editstart
\\ \bf delete &
\cltxt
  {\clkwd (deftype string-char () } ...
\editend

\setcounter{subsection}{4}
\subsection{Type Specifiers That Specialize} % 4.5.

\edithead {\csdag 5 after (p46)}
\editstart
\\ \bf insert &
\cltxt
  {\clkwd (character {\em repertoire})}
\\  &
  This denotes a character type specialized to members
  of the specified repertoire.  {\em Repertoire} may be
  {\clkwd :base} or {\clkwd :standard} or any supported
  character registry name or a list of names.
\editend

\setcounter{subsection}{5}
\subsection{Type Specifiers That Abbreviate} % 4.6.

\edithead {\csdag 20 (p49)}
\editstart
\\ \bf replace &
\cltxt
  Means the same as {\clkwd (array string-char ({\em size}))}: the set of
  strings of
  the indicated size.
\\ \bf with &
\cltxt
  Means the union of the vector types specialized by subtypes of
  character
  and the indicated size.
  For the purpose of object creation, it is equivalent to
  {\clkwd (general-string ({\em size}))}.
\editend
\\
\edithead {\csdag 23 (p49)}
\editstart
\\ \bf replace &
\cltxt
  Means the same as {\clkwd (simple-array string-char ({\em size}))}: the
  set of simple strings of the indicated size.
\\ \bf with &
\cltxt
  Means the union of the simple vector types specialized by subtypes of
  character and the indicated size.
  For the purpose of object creation, it is equivalent to
  {\clkwd (simple-general-string ({\em size}))}.
\editend
\\
\edithead {\csdag 23 after (p49)}
\editstart
\\ \bf insert &
\cltxt
  {\clkwd (base-string {\em size})}
\\ &
  Means the same as {\clkwd (array base-character ({\em size}))}: the
  set of base strings of the indicated size.
\\ &
  {\clkwd (simple-base-string {\em size})}
\\ &
  Means the same as {\clkwd (simple-array base-character ({\em size}))}:
  the set of simple base strings of the indicated size.
\editend
\\
\edithead {\csdag 23 after (p49)}
\editstart
\\ \bf insert &
\cltxt
  {\clkwd (general-string {\em size})}
\\ &
  Means the same as {\clkwd (array character ({\em size}))}: the
  set of base strings of the indicated size.
\\ &
  {\clkwd (simple-general-string {\em size})}
\\ &
  Means the same as
  {\clkwd (simple-array general-character ({\em size}))}:
  the set of simple general strings of the indicated size.
\editend

\setcounter{subsection}{7}
\subsection{Type Conversion Function} % 4.8.

\edithead {\csdag 6 (p51)}
\editstart
\\ \bf replace &
\cltxt
  Some strings, symbols, and integers may be converted to
  characters.  If {\em object} is a string of length 1,
  then the sole element of the print name is returned.
  If {\em object} is a symbol whose print name is of length
  1, then the sole element of the print name is returned.
  If {\em object} is an integer {\em n}, then {\clkwd (int-char }
  {\em n}{\clkwd )} is returned.  See {\clkwd character}.
\\ \bf with &
\cltxt
  Some strings amd symbols may be converted to
  characters.  If {\em object} is a string of length 1,
  then the sole element of the print name is returned.
  If {\em object} is a symbol whose print name is of length
  1, then the sole element of the print name is returned.
  See {\clkwd character}.
\editend
\\
\edithead {\csdag 6 after (p52)}
\editstart
\\ \bf insert &
\begin{itemize}
\cltxt
\item Any string subtype may be converted to any other string
subtype, provided the new string can contain all actual
elements of the old string.  It is an error if it cannot.
\end{itemize}
\editend


%----------------------------------------------------------------------
\setcounter{section}{5}
\section{Predicates}                        % 6
%----------------------------------------------------------------------
\edithead {\csdag 2 (p71)}
\editstart
\\ \bf replace &
\cltxt
  but {\clkwd standard-char} begets {\clkwd standard-char-p}
\\ \bf with &
\cltxt
  but {\clkwd bit-vector} begets {\clkwd bit-vector-p}
\editend

\setcounter{subsection}{1}
\subsection{Data Type Predicates} % 6.2.

\setcounter{subsubsection}{1}
\subsubsection{Specific Data Type Predicates} % 6.2.2.

\edithead {\csdag 36 (p75)}
\editstart
\\ \bf replace &
\cltxt
  {\clkwd characterp} {\em object}
\\ \bf with &
\cltxt
  {\clkwd characterp} {\em object} \&{\clkwd optional}
  {\em repertoire}
\editend
\\
\edithead {\csdag 37 (p75)}
\editstart
\\ \bf replace &
\cltxt
  {\clkwd characterp} is true if its argument is a character,
  and otherwise is false.
\\ \bf with &
\cltxt
  If {\em repertoire} is omitted, {\clkwd characterp}
  is true if its argument is a character object,
  and otherwise is false.
  If a {\em repertoire} argument is specified,
  {\clkwd characterp} is true if its argument
  is a character object and a member of the specified repertoire,
  and
  otherwise is false.
  For example, {\clkwd (characterp  \#$\backslash$A}
  {\clkwd :Latin)}
  is true since \#$\backslash$A is a member of the
  Latin character registry.  {\em repertoire} may be any supported
  character registry name or the names
  {\clkwd :base} or {\clkwd :standard}. {\clkwd (characterp x :base)} is
  true if its argument is a member of the base character
  repertoire and false
  otherwise.
  {\clkwd (characterp x :standard)} is
  true if its argument is a member of the standard character
  subrepertoire and false
  otherwise.
\editend
\\
\edithead {\csdag 38 (p75)}
\editstart
\\ \bf replace &
\cltxt
  {\clkwd (characterp x) $\equiv$ (typep x \apostrophe character)}
\\ \bf with &
\cltxt
  {\clkwd (characterp x :standard) $\equiv$ (typep x \apostrophe
  (character :standard)}
\editend
\\
\edithead {\csdag 72 (p76)}
\editstart
\\ \bf replace &
\cltxt
  See also {\clkwd standard-char-p, string-char-p, streamp,}
\\ \bf with &
\cltxt
  See also {\clkwd standard-char-p, streamp,}
\editend

\setcounter{subsubsection}{2}
\subsubsection{Equality Predicates} % 6.2.3.

\edithead {\csdag 75 (p81)}
\editstart
\\ \bf replace &
\cltxt
  which ignores alphabetic case and certain other attributes
  of characters;
\\ \bf with &
\cltxt
  which ignores alphabetic case
  of characters;
\editend

%----------------------------------------------------------------------
\setcounter{section}{6}
\section{Control Structure}                 % 7
%----------------------------------------------------------------------

\setcounter{subsection}{1}
\subsection{Generalized Variables} % 7.2.

\edithead {\csdag 19 modify table (p95)}
\editstart
\\ \bf replace &
\cltxt
  char               string-char
\\ &
  schar              string-char
\\ \bf with &
\cltxt
  char               character
\\ &
  schar              character
\editend
\\
\edithead {\csdag 22 table entry (p96)}
\editstart
\\ \bf delete &
\cltxt
  char-bit           first                  set-char-bit
\editend

%----------------------------------------------------------------------
\setcounter{section}{9}
\section{Symbols}                           % 10
%----------------------------------------------------------------------

\edithead {\csdag 3 (p163)}
\editstart
\\ \bf replace &
\cltxt
  It is ordinarily not permitted to alter a symbol's print name.
\\ \bf with &
\cltxt
  It is an error to alter a symbol's print name.
\editend

\setcounter{subsection}{1}
\subsection{The Print Name} % 10.2.

\edithead {\csdag 5 (p168)}
\editstart
\\ \bf replace &
\cltxt
  It is an extremely bad idea
\\ \bf with &
\cltxt
  It is an error and an extremely bad idea
\editend

%----------------------------------------------------------------------
\setcounter{section}{10}
\section{Packages}                           % 11
%----------------------------------------------------------------------

\setcounter{subsection}{6}
\subsection{Package System Functions and Variables} % 11.7.

\edithead {\csdag 31 (p184,intern)}
\editstart
\\ \bf append &
\cltxt
  All strings, base and extended, are acceptable {\em string}
  arguments.
\editend

%----------------------------------------------------------------------
\setcounter{section}{12}
\section{Characters}                        % 13
%----------------------------------------------------------------------


\edithead {\csdag 6 after (p233)}
\editstart
\\ \bf insert &
\cltxt
  {\clkwd char-code-limit}   [{\clkwd Constant}]
\\ &
  The value of {\clkwd char-code-limit} is a non-negative integer
  that is the upper exclusive bound on values produced by the
  function {\clkwd char-code}, which returns the {\em code}
  of a given character; that is, the values returned by
  {\clkwd char-code} are non-negative and strictly less than
  the value of {\clkwd char-code-limit}.
  There may be unassigned codes between 0 and
  {\clkwd char-code-limit} which
  are not legal arguments to {\clkwd code-char}.
\\  &
\cltxt
  {\clkwd *all-character-registry-names*}   [{\clkwd Variable}]
\\ &
  The value of {\clkwd *all-character-registry-names*} is a list of
  all character registry names supported by the implementation.
\editend


\setcounter{subsection}{0}
\subsection{Character Attributes} % 13.1.

\edithead {\csdag replace entire section (p233)}
\editstart
\\ \bf with &
\cltxt
  Earlier versions of Common LISP incorporated {\em font} and
  {\em bits} as attributes of character objects.  These are
  considered implementation-defined attributes and
  if supported by an implementation
  effect the action of selected functions.  In particular,
  the following effects are noted:
\\ &
\begin{itemize}
\item Attributes, such as those
  dealing with how the character is displayed or its typography,
  are not part of the character code.
  For example, bold-face, color
  or size are not considered part of the character code.
\item If two characters differ in any attributes,
  then they are not {\clkwd char=}.
\item If two characters have identical
  attributes, then their ordering by
  {\clkwd char}$<$ is consistent with the numerical ordering by the
  predicate $<$ on
  their code attributes. (Similarly for {\clkwd char}$>$,
  {\clkwd char}$>=$ and {\clkwd char}$<=$.)
\item The effect, if any, on {\clkwd char-equal} of each
  attribute has to be specified as part of
  the definition of that attribute.
\item The effect of {\clkwd char-upcase} and {\clkwd char-downcase}
  is to preserve attributes.
\item The function {\clkwd char-int} is equivalent to {\clkwd char-code}
  if no attributes are associated with
  the character object.
\item The function {\clkwd int-char} is equivalent to {\clkwd code-char}
  if no attributes are associated with
  the character object.
\item It is implementation dependent whether characters within
  double quotes have attributes removed.
\item  It is implementation dependent whether
  attributes are removed from symbol names by {\clkwd read}.
\end{itemize}
\editend

\setcounter{subsection}{1}
\subsection{Predicates on Characters} % 13.2.


\edithead {\csdag 3 (p234)}
\editstart
\\ \bf replace &
\cltxt
  argument is a "standard character" that is, an object of type
  {\clkwd standard-char}.
   Note that any character with a non-zero {\em bits} or {\em font}
   attribute
   is non-standard.
\\ \bf with &
\cltxt
  argument is one of the Common LISP standard character subrepertoire.
\editend
\\
\edithead {\csdag 4 (p234)}
\editstart
\\ \bf delete &
\cltxt
  Note that any character with non-zero ...
\editend
\\
\edithead {\csdag 6 (p235)}
\editstart
\\ \bf replace &
\cltxt
  Of the standard characters all but \#$\backslash${\clkwd Newline}
  are graphic.
  The semi-standard characters \#$\backslash${\clkwd Backspace},
  \#$\backslash${\clkwd Tab},
  \#$\backslash${\clkwd Rubout},
  \#$\backslash${\clkwd Linefeed},
  \#$\backslash${\clkwd Return},
  and \#$\backslash${\clkwd Page} are not graphic.
\\ \bf with &
\cltxt
  Of the standard characters all but \#$\backslash${\clkwd Newline}
  are graphic.
\editend
\\
\edithead {\csdag 7 (p235)}
\editstart
\\ \bf delete &
\cltxt
  Programs may assume that graphic ...
\editend
\\
\edithead {\csdag 8 (p235)}
\editstart
\\ \bf delete &
\cltxt
  Any character with a non-zero bits...
\editend
\\
\edithead {\csdag 9 (p235)}
\editstart
\\ \bf delete &
\cltxt
  {\clkwd string-char-p} ...
\editend
\\
\edithead {\csdag 10 (p235)}
\editstart
\\ \bf delete &
\cltxt
  The argument {\em char} must be ...
\editend
\\
\edithead {\csdag 13 (p235)}
\editstart
\\ \bf replace &
\cltxt
  If a character is alphabetic, then it is perforce graphic.  Therefore
  any character
  with a non-zero bits attribute cannot be alphabetic.  Whether a
  character is
  alphabetic is may depend on its font number.
\\ \bf with &
\cltxt
  If a character is alphabetic, then it is perforce graphic.
\editend
\\
\edithead {\csdag 22 (p236)}
\editstart
\\ \bf replace &
\cltxt
  If a character is either uppercase or lowercase, it is necessarily
  alphabetic (and
  therefore is graphic, and therefore has a zero bits attribute).
  However, it is permissible in theory for an alphabetic character
  to be neither
  uppercase nor lowercase (in a non-Roman font, for example).
\\ \bf with &
\cltxt
  If a character is either uppercase or lowercase, it is necessarily
  alphabetic (and
  therefore is graphic).
\editend
\\
\edithead {\csdag 25 (p236)}
\editstart
\\ \bf replace &
\cltxt
  The argument {\em char} must be a character object, and {\em radix}
  must be a non-negative
  integer. If {\em char} is not a digit of the radix specified
\\ \bf with &
\cltxt
  The argument {\em char} must be in the standard character
  subrepertoire and
  {\em radix} must be a non-negative integer.
  If {\em char} is not a standard character or is not a digit of the
  radix specified
\editend
\\
\edithead {\csdag 51 (p237)}
\editstart
\\ \bf delete &
\cltxt
  If two characters have the same bits ...
\editend
\\
\edithead {\csdag 52 (p237)}
\editstart
\\ \bf replace &
\cltxt
  If two characters differ in any attribute (code, bits, or font), then
  they are different.
\\ \bf with &
\cltxt
  If the codes of two characters differ, then
  they are different.
\editend
\\
\edithead {\csdag 94 (p239)}
\editstart
\\ \bf replace &
\cltxt
  The predicate {\clkwd char-equal} is like {\clkwd char=}, and
  similarly for the others, except
  according to a different ordering such that differences of bits
  attributes and case are ignored, and font information is taken into
  account in an implementation dependent manner.
\\ \bf with &
\cltxt
  The predicate {\clkwd char-equal} is like {\clkwd char=}, and
  similarly for the others, except
  according to a different ordering such that differences of case
  are ignored.
\editend
\\
\edithead {\csdag 97 example (p239)}
\editstart
\\ \bf delete &
\cltxt
  {\clkwd (char-equal \#$\backslash$A \#$\backslash$Control-A) is true}
\editend
\\
\edithead {\csdag 98 (p239)}
\editstart
\\ \bf delete &
\cltxt
  The ordering may depend on the font ...
\editend

\setcounter{subsection}{2}
\subsection{Character Construction and Selection} % 13.3.

\edithead {\csdag 3 (p239)}
\editstart
\\ \bf replace &
\cltxt
  The argument {\em char} must be a character object.
  {\clkwd char-code} returns the {\em code} attribute of the
  character object;
  this will be a non-negative integer less than the (normal) value
\\ \bf with &
\cltxt
  The argument {\em char} must be a character object.
  {\clkwd char-code} returns the {\em code} of the
  character object;
  this will be a non-negative integer less than the value
\editend
\\
\edithead {\csdag 4 (p240)}
\editstart
\\ \bf delete &
\cltxt
  {\clkwd char-bits } ...
\editend
\\
\edithead {\csdag 5 (p240)}
\editstart
\\ \bf delete &
\cltxt
  The argument {\em char} must be ...
\editend
\\
\edithead {\csdag 6 (p240)}
\editstart
\\ \bf delete &
\cltxt
  {\clkwd char-font } ...
\editend
\\
\edithead {\csdag 7 (p240)}
\editstart
\\ \bf delete &
\cltxt
  The argument {\em char} must be ...
\editend
\\
\edithead {\csdag 8 (p240)}
\editstart
\\ \bf replace &
\cltxt
  {\clkwd code-char {\em code} \&optional {\em (bits 0) (font 0)}
  [{\em Function}]}
\\ \bf with &
\cltxt
  {\clkwd code-char {\em code}
  [{\em Function}]}
\editend
\\
\edithead {\csdag 9 (p240)}
\editstart
\\ \bf replace &
\cltxt
  All three arguments must be non-negative integers.  If it is possible
  in the
  implementation to construct a character object whose code attribute
  is {\em code},
  whose
  bits attribute is {\em bits}, and whose font attribute is {\em font},
  then such an object
  is returned;
\\ \bf with &
\cltxt
  The argument must be a non-negative integer.  If it is possible
  in the
  implementation to construct a character object identified by
  {\em code},
  then such an object is returned;
\editend
\\
\edithead {\csdag 10 (p240)}
\editstart
\\ \bf replace &
\cltxt
  For any integers, {\em c, b,} and {\em f}, if {\clkwd (code-char
  {\em c b f})} is
\\ \bf with &
\cltxt
  For any integer, {\em c}, if {\clkwd (code-char
  {\em c})} is
\editend
\\
\edithead {\csdag 12 (p240)}
\editstart
\\ \bf delete &
\cltxt
  {\clkwd (char-bits (code-char } ...
\editend
\\
\edithead {\csdag 13 (p240)}
\editstart
\\ \bf delete &
\cltxt
  {\clkwd (char-font (code-char } ...
\editend
\\
\edithead {\csdag 14 (p240)}
\editstart
\\ \bf delete &
\cltxt
  If the font and bits attributes ...
\editend
\\
\edithead {\csdag 15 (p240)}
\editstart
\\ \bf delete &
\cltxt
  {\clkwd (char= (code-char (char-code ...}
\editend
\\
\edithead {\csdag 16 (p240)}
\editstart
\\ \bf delete &
\cltxt
  is true.
\editend
\\
\edithead {\csdag 17 (p240)}
\editstart
\\ \bf delete &
\cltxt
  {\clkwd make-char} ...
\editend
\\
\edithead {\csdag 18 (p240)}
\editstart
\\ \bf delete &
\cltxt
 The argument {\em char} must be ...
\editend
\\
\edithead {\csdag 19 (p240)}
\editstart
\\ \bf delete &
\cltxt
 If {\em bits} or {\em font} are zero ...
\editend
\\
\edithead {\csdag 19 (p240)}
\editstart
\\ \bf append &
\cltxt
  {\clkwd find-char} {\em label registry}    [{\em Function}]
\\ &
  {\clkwd find-char} returns a character object.
  The arguments {\em label} and {\em registry} are names
  (objects coerceable to strings as if by the function {\clkwd string})
  of character registries and labels.
  {\em label}
  uniquely identifies a character within the character
  registry named {\em registry}.
  If the implementation does not support the specified
  character, {\clkwd nil} is returned.
\editend

\setcounter{subsection}{3}
\subsection{Character Conversions} % 13.4.

\edithead {\csdag 8 (p241)}
\editstart
\\ \bf replace &
\cltxt
  {\clkwd char-upcase} returns a character object with the same
  font and bits attributes as {\em char}, but with possibly a
  different code attribute.
\\ \bf with &
\cltxt
  {\clkwd char-upcase} returns a character object with possibly
  a different code.
\editend
\\
\edithead {\csdag 10 (p241)}
\editstart
\\ \bf replace &
\cltxt
  Similarly, {\clkwd char-downcase} returns a character object with the
  same font and bits attributes as {\em char}, but with possibly a
  different code attribute.
\\ \bf with &
\cltxt
  Similarly, {\clkwd char-downcase} returns a character object with
  possibly a different code.
\editend
\\
\edithead {\csdag 12 (p241)}
\editstart
\\ \bf delete &
\cltxt
  Note that the action of ...
\editend
\\
\edithead {\csdag 13 (p241)}
\editstart
\\ \bf replace &
\cltxt
  {\clkwd digit-char {\em weight} \&optional ({\em radix} 10)
  ({\em font} 0)      [{\em Function}]}
\\ \bf with &
\cltxt
  {\clkwd digit-char {\em weight} \&optional ({\em radix} 10)
       [{\em Function}]}
\editend
\\
\edithead {\csdag 14 (p241)}
\editstart
\\ \bf replace &
\cltxt
  All arguments must be integers.  {\clkwd digit-char} determines
  whether or not it is
  possible
  to construct a character object whose font attribute is {\em font},
  and whose {\em code}
\\ \bf with &
\cltxt
  All arguments must be integers.  {\clkwd digit-char} determines
  whether or not it is
  possible to construct a character object whose {\em code}
\editend
\\
\edithead {\csdag 15 (p242)}
\editstart
\\ \bf replace &
\cltxt
  {\clkwd digit-char} cannot return {\clkwd nil} if {\em font}
  is zero, {\em radix}
\\ \bf with &
\cltxt
  {\clkwd digit-char} cannot return {\clkwd nil}.
  {\em radix}
\editend
\\
\edithead {\csdag 22 (p242)}
\editstart
\\ \bf delete &
\cltxt
  Note that no argument is provided for ...
\editend
\\
\edithead {\csdag 23 through 30 (p242, char-int, int-char)}
\editstart
\\ \bf delete &
\cltxt
  {\clkwd char-int} {\em char}
\editend
\\
\edithead {\csdag 32 (p242)}
\editstart
\\ \bf replace &
\cltxt
  All characters that have zero font and bits attributes and that are
  non-graphic
\\ \bf with &
\cltxt
  All characters that are
  non-graphic
\editend
\\
\edithead {\csdag 33 (p243)}
\editstart
\\ \bf replace &
\cltxt
  The standard newline and space characters have the respective
  names {\clkwd Newline} and {\clkwd Space}.  The semi-standard
  characters have the names {\clkwd Tab, Page, Rubout, Linefeed,
  Return,} and {\clkwd Backspace}.
\\ \bf with &
\cltxt
  The standard newline and space characters have the respective
  names {\clkwd Newline} and {\clkwd Space}.
\editend
\\
\edithead {\csdag 35 (p243)}
\editstart
\\ \bf delete &
\cltxt
  {\clkwd char-name} will only locate "simple" ...
\editend
\\
\edithead {\csdag 36 (p243)}
\editstart
\\ \bf append &
\cltxt
  {\clkwd name-char} may accept other names for characters
  in addition to those returned by {\clkwd char-name}.
\editend
\\
\edithead {\csdag 36 (p243)}
\editstart
\\ \bf append &
\cltxt
  {\clkwd char-registry-name} {\em char}    [{\em Function}]
\\ &
  {\clkwd char-registry-name} returns a string representing
  the character registry to which {\em char} belongs.
\editend
\\
\edithead {\csdag 36 (p243)}
\editstart
\\ \bf append &
\cltxt
  {\clkwd char-label} {\em char}    [{\em Function}]
\\ &
  {\clkwd char-label} returns a string representing
  the character label of {\em char}.
\editend
\\
\edithead {\csdag 36 (p243)}
\editstart
\\ \bf append &
\cltxt
  {\clkwd char-ccs-value} {\em char name}    [{\em Function}]
\\ &
  {\clkwd char-ccs-value} returns the non-negative integer
  representing the encoding of the character {\em char} in
  The coded character set named by {\em name}.
  If the implementation does not support the specified
  coded character set, {\clkwd nil} is returned.  If the
  named coded character set does not contain the character,
  {\clkwd nil} is returned.
\editend

\setcounter{subsection}{4}
\subsection{Character Control-Bit Functions} % 13.5.

\edithead {\csdag delete entire section (p243)}
\editstart
\editend

%----------------------------------------------------------------------
\setcounter{section}{13}
\section{Sequences}                         % 14
%----------------------------------------------------------------------
\setcounter{subsection}{0}
\subsection{Simple Sequence Functions}         % 14.1

\edithead {\csdag 21 (p249,make-sequence)}
\editstart
\\ \bf append &
\cltxt
  If type {\clkwd string} is specified, the result is
  equivalent to {\clkwd make-string}.
\editend

%----------------------------------------------------------------------
\setcounter{section}{17}
\section{Strings}                           % 18
%----------------------------------------------------------------------

\edithead {\csdag 1 (p299)}
\editstart
\\ \bf replace &
\cltxt
  Specifically, the type {\clkwd string} is identical to the type
  {\clkwd (vector string-char),}
  which in turn is the same as {\clkwd (array string-char (*))}.
\\ \bf with &
\cltxt
  Specifically, the type {\clkwd string} is a subtype of
  {\clkwd vector}
  and consists of vectors specialized by subtypes of {\clkwd character}.
\editend

\setcounter{subsection}{0}
\subsection{String Access}  % 18.1.
\edithead {\csdag 4 (p300)}
\editstart
\\ \bf replace &
\cltxt
  character object.  (This character will necessarily satisfy the
  predicate
  {\clkwd string-char-p}).
\\ \bf with &
\cltxt
  character object.
\editend
\\
\edithead {\csdag 9 (p300)}
\editstart
\\ \bf replace &
\cltxt
  {\clkwd setf} may be used with {\clkwd char} to destructively
  replace a character within a string.
\\ \bf with &
\cltxt
  {\clkwd setf} may be used with {\clkwd char} to destructively
  replace a character within a string.
  The new character must be of a type which can be stored in the
  string; it is an error otherwise.
\editend

\setcounter{subsection}{2}
\subsection{String Construction and Manipulation}  % 18.3.

\edithead {\csdag 2 (p302)}
\editstart
\\ \bf replace &
\cltxt
  {\clkwd make-string {\em size} \&key :initial-element  [{\em Function}]}
\\ \bf with &
\cltxt
  {\clkwd make-string {\em size} \&key :initial-element  :element-type
  [{\em Function}]}
\editend
\\
\edithead {\csdag 3 (p302,make-string)}
\editstart
\\ \bf replace &
\cltxt
  This returns a string (in fact a simple string) of length {\em size},
  each of whose characters has been initialized to the
  {\clkwd :initial-element} argument.  If an {\clkwd :initial-element}
  argument is not specified, then the string will be initialized
  in an implementation-dependent way.
\\ \bf with &
\cltxt
  This returns a string of length {\em size},
  each of whose characters has been initialized to the
  {\clkwd :initial-element} argument.  If an {\clkwd :initial-element}
  argument is not specified, then the string will be initialized
  in an implementation-dependent way.
  The {\clkwd :element-type} argument names the type of the elements
  of the string; a string is constructed of the most specialized
  type that can accommodate elements of the given type.
  If {\clkwd :element-type} is omitted, the type
  {\clkwd character} is the default.
\editend
\\
\edithead {\csdag 5 (p302,make-string)}
\editstart
\\ \bf replace &
\cltxt
  A string is really just a one-dimensional array of "string
  characters" (that is,
  those characters that are members of type {\clkwd string-char}).
  More complex character arrays may be constructed using the function
  {\clkwd make-array}.
\\ \bf with &
\cltxt
  More complex character arrays may be constructed using the function
  {\clkwd make-array}.
\editend
\\
\edithead {\csdag 29 (p304,make-string)}
\editstart
\\ \bf replace &
\cltxt
  If {\em x} is a string character (a character of type
  {\clkwd string-char}), then
\\ \bf with &
\cltxt
  If {\em x} is a character, then
\editend

%----------------------------------------------------------------------
\setcounter{section}{21}
\section{Input/Output}                      % 22

\setcounter{subsection}{0}
\subsection{Printed Representation of LISP Objects}  % 22.1.

\setcounter{subsubsection}{0}
\subsubsection{What the Read Function Accepts}  % 22.1.1.

\edithead {\csdag Table 22-1: Standard Character Syntax Types (p336)}
\editstart
\\ \bf delete entry &
\cltxt
  {\clkwd <tab>} {\em whitespace}
\\ &
  {\clkwd <page>} {\em whitespace}
\\ &
  {\clkwd <backspace>} {\em constituent}
\\ &
  {\clkwd <return>} {\em whitespace}
\\ &
  {\clkwd <rubout>} {\em constituent}
\\ &
  {\clkwd <linefeed>} {\em whitespace}
\editend

\setcounter{subsubsection}{1}
\subsubsection{Parsing of Numbers and Symbols}  % 22.1.2.

\edithead {\csdag Table 22-3: Standard Constituent Character
Attributes (p340)}
\editstart
\\ \bf delete entry &
\cltxt
  {\clkwd <backspace>} {\em illegal}
\\  &
  {\clkwd <tab>} {\em illegal}
\\  &
  {\clkwd <linefeed>} {\em illegal}
\\  &
  {\clkwd <page>} {\em illegal}
\\  &
  {\clkwd <return>} {\em illegal}
\\  &
  {\clkwd <rubout>} {\em illegal}
\editend

\setcounter{subsubsection}{3}
\subsubsection{Standard Dispatching Macro Character Syntax}  % 22.1.4.

\edithead {\csdag Table 22-4: Standard \# Macro Character Syntax (p352)}
\editstart
\\ \bf delete entry &
\cltxt
  {\clkwd \#<backspace>} {\em signals error}
\\  &
  {\clkwd \#<tab>} {\em signals error}
\\  &
  {\clkwd \#<linefeed>} {\em signals error}
\\  &
  {\clkwd \#<page>} {\em signals error}
\\  &
  {\clkwd \#<return>} {\em signals error}
\\  &
  {\clkwd \#<rubout>} {\em undefined}
\editend
\\
\edithead {\csdag 8 (p353)}
\editstart
\\ \bf replace &
\cltxt
  The following names are standard across all implementations:
\\ \bf with &
\cltxt
  All non-graphic
  characters, including extended characters, are uniquely
  named in an implementation-dependent manner.
  In particular, an implementation may support names of the
  form {\em label:registry}.
  The following names are standard across all implementations:
\editend
\\
\edithead {\csdag 11 through 18 inclusive delete (p353)}
\editstart
\\ \bf delete &
\cltxt
  The following names are semi-standard; ...
\editend
\\
\edithead {\csdag 20 through 26 inclusive delete (p354)}
\editstart
\\ \bf delete &
\cltxt
  The following convention is used in implementations ...
\editend
\\
\edithead {\csdag 108 (p360)}
\editstart
\\ \bf replace &
\cltxt
  {\clkwd \#<space>, \#<tab>, \#<newline>, \#<page>, \#<return>}
\\ \bf with &
\cltxt
  {\clkwd \#<space>, \#<newline>}
\editend

\setcounter{subsubsection}{4}
\subsubsection{The Readtable}  % 22.1.5.

\edithead {\csdag 3 (p360)}
\editstart
\\ \bf replace &
\cltxt
  Even if an implementation supports characters with non-zero
  {\em bits} and {\em font}
  attributes, it need not (but may) allow for such characters to
  have syntax
  descriptions
  in the readtable.  However, every character of type
  {\clkwd string-char}
  must be represented in the readtable.
\\ \bf with &
\cltxt
  All base and extended characters
  are representable in the readtable.
\editend

\setcounter{subsubsection}{5}
\subsubsection{What the Print Function Produces}  % 22.1.6.

\edithead {\csdag 13 (p366)}
\editstart
\\ \bf replace &
\cltxt
  is used.  For example, the printed representation of the character
  \#$\backslash$A
  with control
  and meta bits on would be \#$\backslash${\clkwd CONTROL-META-A},
  and that of
  \#$\backslash$a with control and meta bits on would be
  \#$\backslash${\clkwd CONTROL-META-$\backslash$a}.
\\ \bf with &
\cltxt
  is used (see 22.1.4).
\editend

\setcounter{subsection}{2}
\subsection{Output Functions}  % 22.3.

\setcounter{subsubsection}{0}
\subsubsection{Output to Character Streams}  % 22.3.1.

\edithead {\csdag 26 (p384)}
\editstart
\\ \bf replace &
\cltxt
  ({\em not} the substring delimited by {\clkwd :start} and
  {\clkwd :end}).
\\ \bf with &
  ({\em not} the substring delimited by {\clkwd :start} and
  {\clkwd :end}).
  Only characters which are members of the coded character set(s)
  associated with the output stream or \#$\backslash${\clkwd Newline}
  are valid to be written;
  it is an error otherwise.  All character streams must provide
  appropriate line division behavior for
  \#$\backslash${\clkwd Newline}.
\editend
\\
\edithead {\csdag 27 after (p384)}
\editstart
\\ \bf insert &
\cltxt
  {\clkwd external-coded-string-length} {\em object} \&{\clkwd optional}
  {\em output-stream}   [{\em Function}]
\\  &
  {\clkwd external-coded-string-length}
  returns the number of implementation defined
  units required for the object on the output-stream. If
  not applicable to the output stream, the function
  returns {\clkwd nil}.
  This number corresponds to the current state of the stream
  and may change if there has been intervening output.
  If the output stream is not specified {\clkwd *standard-output*}
  is the default.
\editend

\setcounter{subsubsection}{2}
\subsubsection{Formatted Output to Character Streams}  % 22.3.3.

\edithead {\csdag 23 delete example (p387)}
\editstart
\\ \bf delete &
\cltxt
  {\clkwd (format nil "Type} $\tilde{ }$
  {\clkwd :C to $\tilde{ }$ :A."} . . .
\editend
\\
\edithead {\csdag 66 (p389)}
\editstart
\\ \bf replace &
\cltxt
  $\tilde{ }${\clkwd :C} spells out the names of the control bits and
  represents non-printing
  characters by their names: {\clkwd Control-Meta-F, Control-Return,
  Space}.
  This is a "pretty" format for printing characters.
\\ \bf with &
\cltxt
  $\tilde{ }${\clkwd :C}
  represents non-printing
  characters by their names: {\clkwd Newline,
  Space}.  This is a "pretty" format
  for printing characters.
\editend
%----------------------------------------------------------------------

%----------------------------------------------------------------------
\setcounter{section}{22}
\section{File System Interface}             % 23

\setcounter{subsection}{1}
\subsection{Opening and Closing Files}  % 23.2.

\edithead {\csdag 2 (p418)}
\editstart
\\ \bf replace &
\cltxt
  {\clkwd open {\em filename} \&key :direction :element-type}
  {\clkwd :if-exists :if-does-not-exist}
  [{\em Function}]
\\ \bf with &
\cltxt
  {\clkwd open {\em filename} \&key :direction :element-type}
  {\clkwd
  :external-coded-character-format}
  {\clkwd :if-exists :if-does-not-exist}
  [{\em Function}]
\editend
\\
\edithead {\csdag 11 (p419)}
\editstart
\\ \bf replace &
\cltxt
  {\clkwd string-char}
\\  &
  The unit of transaction is a string-character.  The functions
  {\clkwd read-char}
  and/or {\clkwd write-char} may be used on the stream.
\\ \bf with &
\cltxt
  The default value of {\clkwd :element-type} is
  implementation-defined as character or a subtype of character.
\\  &
  {\clkwd base-character}
\\  &
  The unit of transaction is a base character.  The functions
  {\clkwd read-char}
  and/or {\clkwd write-char} may be used on the stream.
\editend
\\
\edithead {\csdag 16 (p419)}
\editstart
\\ \bf replace &
\cltxt
  {\clkwd character}
\\  &
  The unit of transaction is any character, not just a string-character.
  The functions {\clkwd read-char} and/or {\clkwd write-char} may
  be used on the stream.
\\ \bf with &
\cltxt
  {\clkwd character}
\\  &
  The unit of transaction is any character.
  The functions {\clkwd read-char} and/or {\clkwd write-char} may
  be used on the stream.
\editend
\\
\edithead {\csdag 19 after (p420)}
\editstart
\\ \bf insert &
\cltxt
  {\clkwd :external-coded-character-format}
\\  &
This argument specifies a name or list of
names(s) indicating an implementation recognized scheme for
representing 1 or more coded character sets with non-homogeneous codes.
\\  &
The default value is {\clkwd :default} and is
implementation defined but must include the
base characters.
\\  &
As many coded character set names must be provided as the
implementation requires for that external coding convention.
\\  &
References to standard ISO coded character set names must
include the full ISO reference number and approval year.
The following are valid ISO reference names:
:ISO8859/1-1987, :ISO6937/2-1983, :ISO646-1983, etc..
All implementation recognized schemes are formed from
{\clkwd standard-p} characters.
\editend
%----------------------------------------------------------------------
%----------------------------------------------------------------------
%----------------------------------------------------------------------
\begin{thebibliography}{wwwwwwww 99}


\bibitem[Ida87]{ida87} M. Ida, et al.,
{\em
JEIDA Common LISP Committee Proposal on Embedding Multi-Byte Characters
},
ANSI X3J13 document 87-022, (1987).

\bibitem[ISO 646]{iso646} ISO,
{\em
Information processing -- ISO 7-bit coded character set
for information interchange
},
ISO (1983).

\bibitem[ISO 4873]{iso4873} ISO,
{\em
Information processing -- ISO 8-bit code for information
interchange -- Structure and rules for implementation
},
ISO (1986).

\bibitem[ISO 6937/1]{iso6937/1} ISO,
{\em
Information processing -- Coded character sets for text
communication -- Part 1: General introduction
},
ISO (1983).

\bibitem[ISO 6937/2]{iso6937/2} ISO,
{\em
Information processing -- Coded character sets for text
communication -- Part 2: Latin alphabetic and non-alphabetic
graphic characters
},
ISO (1983).

\bibitem[ISO 8859/1]{iso8859/1} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 1: Latin alphabet No. 1
},
ISO (1987).

\bibitem[ISO 8859/2]{iso8859/2} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 2: Latin alphabet No. 2
},
ISO (1987).

\bibitem[ISO 8859/6]{iso8859/6} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 6: Latin/Arabic alphabet
},
ISO (1987).

\bibitem[ISO 8859/7]{iso8859/7} ISO,
{\em
Information processing -- 8-bit single-byte coded
graphic character sets -- Part 7: Latin/Greek alphabet
},
ISO (1987).

\bibitem[Kerns87]{kerns87} R. Kerns,
{\em
Extended Characters in Common LISP
},
X3J13 Character Subcommittee document, Symbolics Inc (1987).

\bibitem[Kurokawa88]{kurokawa88} T. Kurokawa, et al.,
{\em
Technical Issues on International Character Set Handling in Lisp
},
ISO/IEC SC22 WG16 document N33, (1988).

\bibitem[Linden87]{linden87} T. Linden,
{\em
Common LISP - Proposed Extensions for International Character Set
Handling
},
Version 01.11.87, IBM Corporation (1987).

\bibitem[Steele84]{steele84} G. Steele Jr.,
{\em
Common LISP: the Language
},
Digital Press (1984).

\bibitem[Xerox87]{xerox87} Xerox,
{\em
Character Code Standard, Xerox System Integration Standard
},
Xerox Corp. (1987).

\end{thebibliography}

\end{document}             % End of document.

∂22-Feb-89  1333	Common-Lisp-mailer 	Jan 1 cs proposal comments    
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 22 Feb 89  13:32:43 PST
Date: Wed, 22 Feb 89 02:09:18 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <890222.020918.baggins@almvma>
Subject: Jan 1 cs proposal comments

>>   From: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
>>   Subject: Comments on the Character proposal dated January 1, 1989
>>
>>   Page 6 -- *all-registry-names* should be renamed to
>>   *all-character-registry-names*; the word "registry" by itself
>>   is too general.

I made this change to the latest version of the proposal.

>>
>>   Page 9 -- the fourth bullet requires a defined total ordering of all
>>   characters.  This seems unnecessary, and is impossible to implement in any
>>   system (such as Symbolics Genera) that allows dynamic addition of character
>>   registries by third-party software vendors and by users; in such a system
>>   character codes have to be allocated dynamically and therefore their order
>>   cannot be fixed ahead of time.

You are quite right.  This bullet is removed.

>>
>>   Page 9 -- This says an implementation must define the result of
>>   standard-char-p on the characters it supports.  I think that is incorrect.
>>   Common Lisp fully defines the result of standard-char-p, which is NIL
>>   for all characters added by an implementation.

Right.  This bullet is removed.

>>
>>   Page 14 -- This EXTERNAL-WIDTH function probably should be part of a
>>   database facility or a terminal screen template facility; I'm not sure it
>>   is useful by itself.  Also note that its result is only meaningful with
>>   respect to a specific state of the stream.  To give two examples, with the
>>   SO/SI encoding the answer can vary by 1 depending on whether the stream is
>>   already shifted into the correct state for the first character; with the
>>   universal encoding Symbolics uses, the answer can vary by a lot depending on
>>   whether the character repertoires appearing in the string have been used
>>   earlier on the same stream (and hence have been assigned encoding numbers).
>>   Because of this dependence on the state of the stream, I cannot think of
>>   any correct use of EXTERNAL-WIDTH that does not involve immediately
>>   outputting the string to the stream.  Therefore I believe the same effect
>>   can be achieved without adding any new functions, by calling FILE-POSITION,
>>   outputting to the stream, calling FILE-POSITION again, and subtracting.  If
>>   you still want to propose this feature, you should change the name: use
>>   "length" instead of "width", since that's the word Common Lisp always uses,
>>   and use a name that relates to the :EXTERNAL-CODE-FORMAT option to OPEN;
>>   for example, STRING-LENGTH-IN-EXTERNAL-CODE-FORMAT or
>>   EXTERNAL-CODED-STRING-LENGTH.

I changed the name to EXTERNAL-CODED-STRING-LENGTH.  The description
already contained a comment regarding current state.  Actually, I
favored the STREAM-INFO proposal which was voted down.  This is
much less ambitious but I still feel more useful than actually
forcing I/O, backing up and rewriting.  It's also not clear
that your alternative has the same effect since it seems that
some unwanted side-effects would occur such as premature appearance
on a display screen.

>>
>>   Page 24 -- I can't figure out what you intend the meaning of SIMPLE-STRING
>>   to be.  Your report mostly does not mention it, but it doesn't say to
>>   remove it either.  If I have correctly correlated page 24 back to CLtL, you
>>   are defining SIMPLE-STRING to be synonymous with SIMPLE-GENERAL-STRING.
>>   Maybe what you really meant, though, was what you said in November you
>>   would do, which was to make SIMPLE-STRING mean (AND STRING SIMPLE-ARRAY),
>>   in other words a union of several subtypes.  This is particular confusing
>>   because Common Lisp uses the name SIMPLE-VECTOR to mean what you might call
>>   a simple general vector, that is, (SIMPLE-ARRAY T 1) rather than
>>   (SIMPLE-ARRAY * 1).  Here are my suggestions for what to do with the
>>   various names for string subtypes:
>>
>>     STRING                  As a union of all strings, this is fine.
>>     GENERAL-STRING          I think (VECTOR CHARACTER) is just as good.
>>     BASE-STRING             I think (VECTOR BASE-CHARACTER) is just as good.
>>     SIMPLE-STRING           Should mean (SIMPLE-ARRAY CHARACTER 1).
>>     SIMPLE-BASE-STRING      This is fine.
>>     SIMPLE-GENERAL-STRING   This name is horrible, use SIMPLE-STRING.
>>
>>   My rationale for these suggestions largely comes from thinking about
>>   which of these names would ever be used in type declarations and about
>>   how these names relate to the other names already in Common Lisp.  To
>>   repeat older comments:
>>
>>     Pages 19 and 20 introduce a new type named simple-base-string, in addition
>>     to simple-string.  If you think about how simple-string would be used for
>>     compiler optimization, it makes sense for simple-string to be the name for
>>     the single simplest representation, rather than a name for a whole family
>>     of representations that would have to be discriminated at run time.  Thus
>>     what you call simple-base-string should be called simple-string, and what
>>     you call simple-string should just be called (simple-array character (*)).
>>     This would not be an incompatible change in the meaning of simple-string.
>>     Simple-string would be analogous to simple-vector.
>>
>>   I changed my mind slightly on that and now claim that while SIMPLE-STRING
>>   should still be a single representation, not a union, it should be the
>>   representation that can hold all characters.  This is both because of the
>>   principle that correct programs should be easier to write than
>>   extra-efficient programs, and because of the powerful analogy with the name
>>   SIMPLE-VECTOR.  Then the name SIMPLE-BASE-STRING is also needed for
>>   convenient type declarations of the more efficient but less functional
>>   string representation.  That name is good, by analogy to BASE-CHARACTER.
>>
>>   Adopting the above suggestions helps you decide what to do about the
>>   SCHAR, SBCHAR, and SGCHAR mess.  First of all, you only need two functions,
>>   not three, because there are only two specified specialized representations.
>>   SCHAR should be for what I've called SIMPLE-STRING, SBCHAR should be
>>   for SIMPLE-BASE-STRING, and SGCHAR is not needed.  (In fact I would prefer
>>   to remove all of the specialized versions of AREF from the language, in
>>   favor of THE or type declarations, but I know that would only pass over
>>   some peoples' dead bodies so I won't push it.)
>>
>>   In case you are wondering, I have no quarrel with the name BASE-CHARACTER
>>   and would not want to see it removed.  I guess I differ from Larry here,
>>   unless I erred when I wrote down his comments during the meeting.

The statement on p24 making SIMPLE-STRING == (SIMPLE-ARRAY CHARACTER (*))
was in error.  P25 had it right.  Since we changed SCHAR to accept
all simple strings there is no reason for SGCHAR and SBCHAR and
these are eliminated.

  String and simple-string are (more clearly I hope) defined as union
types.  I've changed the terminology from 'for the purpose of
declaration' to 'for object creation'.   Perhaps there is a better
term but the effect seems to be identical to what you suggest. That is,
correct, portable programs are easier to write, one simply uses
string and simple-string.  More efficient, less portable programs
need to specify the specialized subtype(s) explicitly.
  Having both string and simple-string defined as union types seems
desirable on the basis of uniformity.
  Of the type abbreviations I think BASE-CHARACTER is the most
useful and GENERAL-STRING, SIMPLE-BASE-STRING and SIMPLE-GENERAL-STRING
less so.  I don't believe that any of these really complicate the
language.

>>
>>   Page 25 -- The discussion of STRING and SIMPLE-STRING thinks that there
>>   is a distinction between declaration and discrimination, but Common Lisp
>>   no longer has such a distinction.  Even when Common Lisp did have such
>>   a distinction, the meanings for declaration stated here were incorrect.

I changed this to 'object creation'.  Perhaps there is a better term.

>>
>>   Page 29 -- *all-character-registry-names* has to be a variable, not a
>>   constant, to accomodate systems (such as Symbolics Genera) that allows
>>   dynamic addition of character registries by third-party software vendors
>>   and by users.

Right, I made this change.

>>
>>   Page 35 -- CHAR-REGISTRY should be renamed to CHAR-REGISTRY-NAME, so that
>>   if at some later time character registry objects are added, there is no
>>   possibility of confusion about whether this function returns a name or
>>   an object.

Right, I made this change.

>>
>>   Page 40 -- the default :ELEMENT-TYPE for OPEN cannot be BASE-CHARACTER.  I
>>   think this was discussed at the X3J13 meeting.  The report suffers from a
>>   confusion between two meanings of BASE-CHARACTER: the character type
>>   implemented most efficiently by the Lisp, and the character type most
>>   natural to the file system.  These are not always the same.  Furthermore,
>>   in a network-based system that supports multiple file systems equally
>>   (Symbolics Genera is an example), each file system might have a different
>>   natural character type.  BASE-CHARACTER should just mean the character type
>>   implemented most efficiently by the Lisp.  The default for :ELEMENT-TYPE
>>   has two viable choices that I can see, and maybe you should just propose
>>   both and let people vote:
>>
>>     (1) CHARACTER.  This matches the behavior of MAKE-STRING and friends,
>>     adheres to the principle that writing correct programs should be easier
>>     than writing extra-efficient programs (since making a program correct
>>     requires making every part of it correct, while making a program
>>     efficient only requires improving the bottlenecks), and doesn't cost
>>     anything in implementations that don't have extended characters.
>>
>>     (2) The most natural type for the particular pathname being opened.
>>     In some systems this would be a constant, and in a subset of those
>>     systems this would be BASE-CHARACTER, however in general this might
>>     depend on the host, device, or even type fields of the pathname,
>>     and might also depend on information stored in the file system.
>>     In general this would always be an (improper) supertype of
>>     BASE-CHARACTER, but it's probably a bad idea to make that a requirement,
>>     as some file systems might not be able to implement it conveniently.
>>     Again this doesn't cost anything in implementations that don't have
>>     extended characters.

The discussion on p16 about the base coded character set efficiency
has been removed.  The default element-type now states that it is
implementation defined as character or a subtype of character.

>>
>>   The relationship of option 2 to :ELEMENT-TYPE :DEFAULT (a feature that
>>   already exists in Common Lisp) needs to be clarified.  Perhaps they
>>   are the same.

The same?  I don't understand.  For example, I can imagine the
element-type default as base-character and the external format
defaulted to either an ASCII or EBCDIC encoding.

>>
>>   Also the following promise from 14 November did not show up in the report:
>>
>>     >>     There should be a name for the "natural" encoding and there should be a
>>     >>     specification of the properties of the natural encoding that a programmer
>>     >>     can rely on.  Suggestions for the name include :BASE, :NATURAL, and
>>     >>     :INTERCHANGE.  The definition probably involves the concept of data
>>     >>     interchange with non-Lisp programs on the same system.
>>
>>     This will be added to the revision.

I lied.  No one came up with the 'properties' of such an encoding.
Do you have some text to suggest?

>>
>>   Appendix B -- I disagree with the way you've used deprecation.  I'll
>>   comment on each individual point:
>>    - I see no justification for deprecating STANDARD-CHAR.
>>    - I agree that STRING-CHAR should be deprecated, not deleted nor kept.
>>    - I think fonts and bits should be removed outright, not deprecated,
>>      because no portable program could possibly be using them.
>>    - I think the CHAR-INT function needs to be kept, although the INT-CHAR
>>      function should go away.  This is for hashing.  See comments below
>>      on character attributes.

I've removed Appendix B and mention of deprecation.  STANDARD-CHAR
is simply (characterp :standard).  String-char is back in as
implementation-defined either character or base-character (and
maybe should be voted as a deprecated type).

>>
>>   No particular page -- the use of strings for naming registries, labelling
>>   characters, and naming external code formats is objectionable.  Nothing
>>   else in Common Lisp is named by strings.  Use of strings might lead to
>>   efficiency problems.  We feel that keyword symbols are the appropriate
>>   objects to use for these three kinds of names.

I changed these back to symbols.

>>
>>   No particular page -- We agree with the deprecation or deletion of the two
>>   particular character attributes defined by CLtL, but not with the
>>   deprecation of the whole concept of character attributes.  In fact on page
>>   20 you say "characters are uniquely distinguished by their codes," which
>>   makes it impossible to have character attributes at all.  The language must
>>   define how conforming programs should be written so that they will work
>>   both in implementations with character attributes and in implementations
>>   without them.  For example, the value of (eql x (code-char (char-code x)))
>>   is unspecified.  Another thing that needs to be said is that the exact
>>   character operations (char=, string=, etc.) respect all character
>>   attributes, while the inexact character operations (char-equal,
>>   string-equal, etc.) respect or ignore each character attribute in an
>>   implementation-defined but consistent fashion.  Some of what you say on
>>   page 44 about attributes in general needs to be part of the spec, not
>>   deprecated.  I would retain everything on that page except for INT-CHAR and
>>   the last bullet (referring to bits and fonts), and I would add a remark
>>   that FIND-SYMBOL and INTERN respect character attributes.  If you want,
>>   perhaps I or someone else at Symbolics can provide exact text for what
>>   to say about character attributes that you could insert into your report.

I moved the attribute list previously in Appendix B back into the
description of characters.  Let me know what text you would like
to see for FIND-SYMBOL and INTERN and I'll add it to the list.

>>   No particular page -- On the subject of defining character registries in a
>>   separate document, and relating them to ISO standards for character
>>   encoding: I think that's fine.  I don't see anything wrong with introducing
>>   the concept of character registry and the requirement that each character
>>   object relates to exactly one registry.  However, I think the somewhat
>>   random list of character registries on pages 7-8 and again on page 21 does
>>   not belong in the language specification.  Even the names of the

Right.  They are not part of the Common LISP standard.  The revised
document is considerably clearer in this regards.

>>   standardized character registries belong in the character registry
>>   standard, not in the Common Lisp language standard.  I'm confused about the
>>   meaning of BASE, STANDARD, and CONTROL as character registry names; these
>>   are mentioned in your report but not explained very well.  If these are
>>   character registries that are required to exist in all Common Lisp
>>   implementations, then unlike the others they do belong in the Common Lisp
>>   language standard, not in the character registry standard.

By CONTROL, I meant a registry which contains the various control
codes mentioned in the various ISO coded character set standards.
BASE and STANDARD are no longer mentioned here.  They are allowed
as Common LISP repertiore names in characterp and the character
type specifier.

>>
>>   At the meeting there was some discussion about the issue of enumerating all
>>   characters in a character registry.  People claimed incorrectly that it was
>>   impossible.  In fact it's possible to do this, with questionable
>>   efficiency, by the following program:
>>
>>     (dotimes (code char-code-limit)
>>       (let ((char (code-char code)))
>>         (when char
>>           (when (eq (char-registry-name char) desired-registry-name)
>>             ... process this char ...))))
>>
>>   Of course you have to change the EQ to EQUALP if you continue to use
>>   strings to name character registries.  For more efficiency, you could add
>>   a way to iterate over all the codes in one character registry, but I think
>>   that is unnecessary.
>>
>>
>>   TYPOS:

Right. I've made these corrections.

>>
>>   25 -- base-string is missing from the Table 4-1 amendment.
>>
>>   26 -- general-string is not an array of BASE characters, also the first
>>   two paragraphs under A.4.8 are garbled (the two separate sentences for
>>   strings for symbols got smushed together).
>>
>>   37 -- This says the default for the :ELEMENT-TYPE option to MAKE-STRING
>>   is SIMPLE-STRING.  Actually it's CHARACTER.
>>

∂22-Feb-89  1334	Common-Lisp-mailer 	cs proposal comments
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 22 Feb 89  13:33:35 PST
Date: Wed, 22 Feb 89 03:48:56 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
Message-ID: <890222.034856.baggins@almvma>
Subject: cs proposal comments

>>   From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
>>   Subject: comments on character proposal
>>
>>   Getting rid of bits and fonts (section 2.1) seems like a very good
>>   idea to me.  I would argue for deleting these "features" completely
>>   instead of merely deprecating them, because there now seems to be
>>   general agreement that the whole idea was brain-damaged in the first
>>   place, plus it's just about impossible to use them portably anyway
>>   (since implementations are free not to support them).  Deprecating the
>>   features would simply perpetuate the current sad state of affairs in
>>   to the ANSI standard.

I deleted Appendix B from the proposal.  The attribute check list is
incorporated into the character chapter as implementation dependent.

>>
>>   I am not at all sure why we need to standardize the idea of character
>>   registries at all, much less state that a character can only belong to
>>   one registry, or define a standard set of registries.  What does having
>>   registries buy the user, other than perhaps a way to test whether a
>>   character belongs to one or not?  Why isn't it sufficient just to say
>>   that implementations can support extended characters, and leave it at
>>   that?

The registries are introduced to allow an application a portable
way to name, compose and decompose characters.  Currently, there is
no way to do this in any programming language.  There are other
possiblities.  For example, simply labeling all characters
uniquely; another to define a universal coded character set and use
these numeric codes to 'name' characters.  I don't think using
numbers for naming characters is useful since I'll always forget
what character 34539 actually is!  Registries seem to provide a
framework for useful categorization of characters.  It also
avoids the current mess that the coded character set standards
are in.


>>
>>   I'm confused about how you propose to handle characters that appear in
>>   more than one character repetoire, and whether characters with accent
>>   marks are considered distinct from characters without accents.  For
>>   example, is the French "C" with a cedilla distinct from a normal
>>   French "C", and is that distinct from the standard-char "C"?

We handle characters that appear in more than one repertoire by
using registries.  No character appears in more than one registry.
The constituents of the registries are not defined by Common LISP.
I believe that in most environments today, it is recognized that
characters with accents are distinct from their vanilla cousins.
As we have proposed registries, they contain semantically
distinct characters.

>>
>>   The way the document describes things now, it seems like the Common
>>   Lisp standard would have to include a statement of exactly what
>>   characters belong in each of the standard registries listed in section
>>   2.2.  Otherwise, implementors might go off and define their own
>>   character registries that happen to include some characters that ought
>>   to belong in one of these standard registries.  For instance, the machine
>>   I happen to be sitting in front of right now supports an 8-bit native
>>   character set, and it seems perfectly reasonable for a Lisp runnning on
>>   this machine to include all 256 characters in its base character set,
>>   but some of those might actually be supposed to live off in some other
>>   registry.

The registries are independent of any coded character sets.
In particular, coded character sets are not registries.  Your base
repertoire (set of 256 characters) are possibly drawn from
several registries.

You are correct that lacking an international standard (or ANSI one),
for character registries an implementation could define the
a single registry containing all supported characters.  It could
also define NO registries and use only the conventional naming
of characters.  I expect an implementation taking the no-cost way
would choose the second approach.  On the other hand, an
implementation supporting text processing across international
boundaries is more likely to define some reasonable registries
eg. Latin, Greek, etc..


>>
>>   Also in section 2.2, why is it necessary for there to be a total
>>   ordering, or even a partial ordering, of all characters?  It seems
>>   like CHAR< and friends are not very useful except when comparing base
>>   characters anyway.  It seems like it would difficult to get things
>>   like the Spanish N-with-twiddle character to collate correctly anyway,
>>   given the constraints you have put on how character codes are derived
>>   and the requirement that CHAR< be just like < on the char-codes.

Right.  This is now removed.

>>
>>   It doesn't seem like STANDARD-CHAR-P belongs in the list of character
>>   predicates on p. 9, since no extended characters can possibly be
>>   STANDARD-CHAR-P anyway.

Right.  This is now removed.

>>
>>   The stuff in section 2.3 seems mostly reasonable to me.  It's not really
>>   clear why you need GENERAL-STRING (as distinct from STRING) and
>>   SIMPLE-GENERAL-STRING (as distinct from SIMPLE-STRING).  Again, some
>>   rationale would be helpful.

GENERAL-STRING means (VECTOR CHARACTER).  This is not the meaning of
STRING (a union type).  I agree that GENERAL-STRING is not much
of an abbreviation over (VECTOR CHARACTER).  It still seems somewhat
more mnemonic.

>>
>>   In section 2.4, the general idea of specifying an external character
>>   encoding to OPEN seems reasonable.  However, I'm confused by the
>>   business about having more than one coded character set mixed
>>   together.  If a character appears in more than one coded character
>>   set, which encoding takes precedence?  It seems like this has not been
>>   well thought-out.  Also, seeing as though we have just voted down a
>>   proposal to add an EXTERNAL-WIDTH function, it seems like a very bad
>>   idea to lump it in here.

Some encoding schemes allow disjoint coded characters sets to
coexist.  That is, a given character would appear on one but not
the other.  For example, a ISO8859/1 coded character set could
coexist with a coded character set for Chinese.

As for External-width, it was part of our subcommittee discussions
long before the recent stream proposal.  It will be a separate
item in the list of character votes.

>>
>>   Now for the general comments.
>>
>>   One thing that is not clear to me from reading this document is how
>>   much of it has already been standardized by ISO.  I share Larry's
>>   concern that we might standardize one thing, and then have ISO go off
>>   and standardize something completely different.  I think it's a
>>   mistake to try to second-guess what ISO might do.

The revision might make this clearer.  I think this is a
red herring anyhow.  As a programming language committee
we need to specify what is useful in the context of LISP.  We
can't expect a coded character set committee to figure it out.

On the other hand, we can influence what gets standardized
by defining our framework.  The ISO Prolog std committee is
interested in what we define.

>>
>>   I am also concerned about trying standardize things that have not yet
>>   been implemented.  I think it's a mistake to try to do language design
>>   in a standards committee.
>>
>>   Finally, I have some problems with the presentation of your proposal.
>>   One problem, as I mentioned at the meeting, is that you've made it an
>>   all-or-nothing package, and I can't vote for the whole thing because
>>   there are some parts of it that do not seem appropriate, even though I
>>   would support some of the other changes individually.  The other
>>   problem is that Appendix A is virtually unreadable.  Some of the
>>   conceptual changes involve wording changes to several passages, and I
>>   know that there are some other changes in the appendix that are not
>>   mentioned in the introductory blurb at all.  Is it totally impossible
>>   to recast the changes in standard cleanup format proposals?  The
>>   advantage of that format is that it presents more context, including a
>>   clear statement of why the existing CLtL behavior is "broken" and a
>>   rationale for the proposed change.

There will be several votes regarding this proposal.  I don't
intend to rewrite the document in a cleanup format.


>>
>>   I know that we adopted things like the CLOS document that were
>>   presented as single mega-proposals, but those were primarily additions
>>   to the language and what you are proposing is essentially a large
>>   number of incompatible changes.  I'm having a hard time identifying
>>   what all of those changes are.
>>

Actually, I don't think it's as large a number of changes as you
imply.  In any case, the vote split should help this out.


∂22-Feb-89  1334	Common-Lisp-mailer 	cs proposal comments
Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 22 Feb 89  13:34:09 PST
Date: Wed, 22 Feb 89 04:51:15 PST
From: Thom Linden <baggins@IBM.com>
To: Common Lisp mailing <common-lisp@sail.stanford.edu>
cc: David Gray <GRAY%DSG.CSC.TI.COM@RELAY.CS.NET>
Message-ID: <890222.045115.baggins@almvma>
Subject: cs proposal comments

>>   From: David N Gray <Gray@DSG.csc.ti.com>
>>   Subject: characters proposal
>>
>>   I have read the documented titled "Extensions to Common LISP to Support
>>   International Character Sets" dated January 1, 1989, and feel that it is
>>   not much of an improvement over what we saw in October.  Following are
>>   some random comments about things I happened to notice; this is not
>>   intended to be a comprehensive analysis.
>>
>>   First, documents such as this ought to be labelled with an X3J13
>>   document number so that they can be referred to conveniently and
>>   unambiguously.
>>
>>   "Appendix A" and "Appendix B" really should be chapters 3 and 4 since
>>   they are an essential part of the proposal, rather than being an
>>   appendage to it.

Appendix B is now eliminated.  Appendix A is really quite unlike
chapters 1 and 2 in structure.

>>
>>   Page 7 says that the definition of semi-standard-characters "is replaced
>>   by a more uniform approach with introduction of the Control Character
>>   Registry".  Do you really mean that it _will_be_ replaced when the
>>   Control Character Registry is defined in some subsequent document?  I
>>   certainly don't see anything in this document that could be considered a
>>   replacement.

Yes.  The revision is clearer on this.  This document does not define
names for character registries nor their constituents.

>>
>>   This whole concept of registries seems rather strange.  Is the intent
>>   that the alphabetic characters of the standard characters are to be in
>>   the "Latin" registry while characters such as period and comma are in
>>   "Latin-Punctuation"?   Is #\NEWLINE in the "Control" registry?  Where do
>>   the digits go -- "Mathematical"?.  Is #\- a "Latin-Punctuation" or a
>>   "Mathematical"?  Which registry is #\SPACE in?  Now tell me what to do
>>   with the extra non-Latin alphabetic characters used in Sweedish?  Does
>>   that require a separate registry for just those additional characters?
>>   Now we have simple text in a single language using characters from at
>>   least four different registries.  Do you really think it possible to
>>   agree on a "fixed", non-extensible, set of "Mathematical" or "Pattern"
>>   characters?

  Actually, I believe the simplicity of the registry framework will make
agreement easy.  Currently, members of the coded character set
committees spend vast amounts of time lobbying for inclusion of their
favorite character(s) in the 'popular' coded character set standard.
The effect of not being included means fewer installations will
support their native language properly.

  I think a new group, hopefully formed within
programming languages, should define the registries rather than
the existing coded character set committees.  There is no competition
between registries, ie. no advantage of one over another.  What this
committee has to agree upon is 1) a useful set of registry names and
2) definition of the constituents of each registry.  The only argument
I would anticipate is "are the semantics of my alpha the same
or different from your alpha" type debates.
  By the way,
the registries are fixed only in that a Common LISP implementation
cannot modify the standard definitions.  This guarantees an application
program can portably rely on the composition and decomposition
functions to establish the availability of any given character.

>>
>>   Page 9 says that an implementation needs to specify the total ordering
>>   of characters within each registry, but what about the ordering of
>>   characters in different registries?  Is that completely undefined?

There is no ordering of characters within registries.  As mentioned
in Hawaii, the character index (a number) was changed to character
label (a symbol) throughout the proposal.

>>
>>   Page 25 section A.4.5 doesn't specify the syntax of a registry name; did
>>   you intend it to be a string?

These have been changed to be symbols.

>>
>>   Page 27 has an example using  (typep x '(character "standard"))  but
>>   page 25 said that had to be a registry name; "standard" is not a
>>   registry name.

The revision is clearer on this.  character and characterp can take
registry names, :base or :standard.  The meaning of :base and :standard
is defined by Common LISP as the base character repertoire and
standard character repertoire respectively.

>>
>>   Page 29 - *ALL-REGISTER-NAMES* -- a list of strings?

Now a list of symbols.

>>
>>   Page 33 -- FIND-CHAR -- does the index value within a registry have any
>>   portable meaning?  Is that intended to be specified for the standard
>>   registries?  Is "base" supposed to be accepted here?  If not, how can
>>   you access the base codes?  If I were going to construct a character
>>   from its index value, it would be more meaningful to use an index
>>   relative to some coded character set rather than these registries.

FIND-CHAR takes a character label and registry.  These are specified
by the registry standard.  Base is not a registry name.  We have
introduced a new function CHAR-CCS-VALUE which takes a character
object and a coded character set name (a symbol) and returns the
encoding of the character in the coded character set.

>>
>>   Page 36, the last sentence doesn't make sense.  The default for
>>   :ELEMENT-TYPE would have to be either CHARACTER or BASE-CHARACTER.

Right. I've made this change.

>>
>>   Page 37, section A.22.1.1 -- the part being deleted specifies the
>>   meaning of including tab and form-feed characters in a Common Lisp
>>   source file; do you really intend that to not have any standard meaning?
>>   If my editor uses tabs for indenting, does that mean that the resulting
>>   source file is not a standard-conforming program?

That really depends on the definition of a conforming program. Is
this defined yet?

>>
>>   Page 38, the first reference to p360 of CLtL should be p353; the
>>   deletion here says that there shall not be any standard name for the
>>   commonly used control characters such as tab and form-feed.  That still
>>   seems wrong to me.
>>
>>   Page 41, what's the point of appending "ccs" to the name of the
>>   standard?  Presumably that stands for "coded character set", but isn't
>>   that adequately implied by the fact that this string will follow the
>>   keyword :EXTERNAL-CODE-FORMAT ?   The use of "default" seems odd since
>>   :DEFAULT is used everywhere else.

This was to distinguish from someone referring to the set of characters
(repertoire) represented in a given coded character set. Ie. to
distinguish ISO8859/6-1987 coded character set from the ISO8850/6-1987
repertoire.  In fact, the ISO coded character set standards never
refer to repertoires in isolation (ie. without the codes), so I've
dropped the 'ccs'.  Also, "default" is now :DEFAULT as elsewhere.


>>
>>   I agree with Moon that the excising of bits and fonts has not been done
>>   carefully enough for them to be compatible extensions.
>>

I think the new revision takes care of this by incorporating the
attribute list as part of the language proper (ie. not deprecated).


∂27-Feb-89  0140	Common-Lisp-mailer 	pluralization:  two proposals 
Received: from DST.BOLTZ.CS.CMU.EDU ([128.2.220.61]) by SAIL.Stanford.EDU with TCP; 27 Feb 89  01:39:51 PST
Received: from DST.BOLTZ.CS.CMU.EDU by DST.BOLTZ.CS.CMU.EDU; 27 Feb 89 04:37:12 EST
To: common-lisp@sail.stanford.edu
Reply-To: Dave.Touretzky@cs.cmu.edu
Subject: pluralization:  two proposals
Date: Mon, 27 Feb 89 04:37:06 EST
Message-ID: <3127.604575426@DST.BOLTZ.CS.CMU.EDU>
From: Dave.Touretzky@B.GP.CS.CMU.EDU

The ~P format directive and its : and @ variants provide only the suffixes
"s" and "ies".  What about nouns whose singular forms end in "s" or
"z"?  They use "es" to form their plural, e.g.

   bus     -->  buses
   glass   -->  glasses
   buzz    -->  buzzes

First, I propose that ~P and ~:P be modified to produce the "es" plural
form instead of "s" when given a numeric argument of -1.

Second, a more ambitious proposal: how about introducing a new conditional
directive to handle arbitrary singular/plural distinctions:

  ~:@[ singular ~; plural ~]

If the argument is EQL to 1, the first alternative is taken; otherwise the
second alternative is taken.  This lets you do neat things like:

  (format nil "There ~:@[is~;are~]~:* ~D~:* ~:@[wolf~;wolves~] here." 3)
    ==>  "There are 3 wolves here."

  (format nil "There ~:@[is~;are~]~:* ~D~:* ~:@[wolf~;wolves~] here." 1)
    ==>  "There is 1 wolf here."


  (format nil "Your tab comes to ~D~:* ~:@[wolfs'~;wolves'~] head~:P." -5)
    ==>  "Your tab comes to -5 wolves' heads."

  (format nil "Your tab comes to ~D~:* ~:@[wolf's~;wolves'~] head~:P." 1)
    ==>  "Your tab comes to 1 wolf's head."

Notes:

1) The example with -5 shows why special plural forms can't simply be
handled with an ordinary conditional by writing

  ~[plural~;singular~:;plural~]

2) The pluralization conditional is also useful for handling things like
possessive forms (wolf's vs. wolves') and the verb "be" (is vs. are).

-- Dave

∂01-Mar-89  1218	Common-Lisp-mailer 	Why do input functions need RECURSIVE-P argument? 
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 1 Mar 89  12:18:14 PST
Return-Path: <barmar@Think.COM>
Received: from sauron.think.com by Think.COM; Wed, 1 Mar 89 15:14:26 EST
Received: from OCCAM.THINK.COM by sauron.think.com; Wed, 1 Mar 89 15:12:30 EST
Date: Wed, 1 Mar 89 15:15 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Why do input functions need RECURSIVE-P argument?
To: common-lisp@sail.stanford.edu
Message-Id: <19890301201524.9.BARMAR@OCCAM.THINK.COM>

Something has been bothering me for a while, and I was reminded about it
when reading the latest version of the draft chapter on I/O for ANSI CL:
why is the RECURSIVE-P argument necessary for Common Lisp input
functions?

I understand that it is necessary for an input function to know whether
it is a top-level call or a recursive call, but that doesn't tell me why
this must be an argument to the functions.  The implementation could
simply make use of a flag in the stream object, e.g.

(defstruct stream
  ...
  (inside-input-function-p nil)
  ...)

(defun read (&optional stream ...)
  ...
  (let ((recursive-p (stream-inside-input-function-p stream)))
    (unwind-protect
	(progn
	  (setf (stream-inside-input-function-p stream) t)
	  ...)
      (setf (stream-inside-input-function-p stream) recursive-p)))
  ...)

The only justification for making it an argument would be to allow calls
that actually are recursive to pretend that they aren't; however, I
can't think of a legitimate reason to want to do this.  And this
provides an easy trap for read-macro programmers to fall into, when they
accidentally forget to include the RECURSIVE-P argument.

MacLisp didn't have a RECURSIVE-P argument and it worked OK in this
regard, didn't it?

                                                barmar

∂01-Mar-89  1934	Common-Lisp-mailer 	Why do input functions need RECURSIVE-P argument? 
Received: from ALDERAAN.SCRC.Symbolics.COM ([128.81.41.109]) by SAIL.Stanford.EDU with TCP; 1 Mar 89  19:32:23 PST
Received: from GANG-GANG.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 276814; Wed 1-Mar-89 22:26:31 EST
Date: Wed, 1 Mar 89 22:26 EST
From: Glenn S. Burke <gsb@ALDERAAN.SCRC.Symbolics.COM>
Subject: Why do input functions need RECURSIVE-P argument?
To: barmar@Think.COM, common-lisp@sail.stanford.edu
In-Reply-To: <19890301201524.9.BARMAR@OCCAM.THINK.COM>
Message-ID: <19890302032621.6.GSB@GANG-GANG.SCRC.Symbolics.COM>

    Date: Wed, 1 Mar 89 15:15 EST
    From: Barry Margolin <barmar@Think.COM>

    Something has been bothering me for a while, and I was reminded about it
    when reading the latest version of the draft chapter on I/O for ANSI CL:
    why is the RECURSIVE-P argument necessary for Common Lisp input
    functions?

    I understand that it is necessary for an input function to know whether
    it is a top-level call or a recursive call, but that doesn't tell me why
    this must be an argument to the functions.  The implementation could
    simply make use of a flag in the stream object, e.g.

    (defstruct stream
      ...
      (inside-input-function-p nil)
      ...)

    (defun read (&optional stream ...)
      ...
      (let ((recursive-p (stream-inside-input-function-p stream)))
	(unwind-protect
	    (progn
	      (setf (stream-inside-input-function-p stream) t)
	      ...)
	  (setf (stream-inside-input-function-p stream) recursive-p)))
      ...)

    The only justification for making it an argument would be to allow calls
    that actually are recursive to pretend that they aren't; however, I
    can't think of a legitimate reason to want to do this.  And this
    provides an easy trap for read-macro programmers to fall into, when they
    accidentally forget to include the RECURSIVE-P argument.

This won't work right on an interactive stream (*terminal-io*) when a
new toplevel call to read can be initiated while within the dynamic
scope of that unwind-protect body.

It is true, however, that the same sort of stream encapsulation
technology which can be used to handle sophisticated printing (to get
around the lack of a recursive-p argument to the printing functions!) 
could be used by the reader.  That is, recursive calls to read don't get
the original stream argument, but some other stream which encapsulates
other state of the read in progress.

    MacLisp didn't have a RECURSIVE-P argument and it worked OK in this
    regard, didn't it?

No.  Maclisp went to lots of effort to reset state on when stacking
anything (error, interrupts, etc.).  i.e., global knowledge about the
state of the reader (and other things) was needed.

						    barmar



∂02-Mar-89  1512	Common-Lisp-mailer  
Received: from NMFECC.ARPA by SAIL.Stanford.EDU with TCP; 2 Mar 89  15:11:08 PST
Received: from tuva.sainet.mfenet by ccc.mfenet with Tell via MfeNet ;
	Thu, 2 Mar 89 15:06:40 PST
Date:	  Thu, 2 Mar 89 15:06:40 PST
From:     POTHIERS%TUVA.SAINET.MFENET@NMFECC.ARPA
Message-Id: <890302150640.23200215@NMFECC.ARPA>
To:       COMMON-LISP@SAIL.STANFORD.EDU

Subject: LOOP macro
Date:    Thu,  2-MAR-1989 16:07 MST
X-VMS-Mail-To: @CL

I'm looking for a LOOP macro. Is it going to be in the new CL standard?
If it is going to be in the standard, can someone tell me what the
standard says about it? 

Unfortunately, I'm not sure what type of loop macro I'm looking for!
I'm porting some code that is supposed to be CL except for the LOOP.
It looks similar to the Symbolics LOOP. I know they at least use
COLLECT, FOR, DO and probably lots more.

If anyone can send be a relatively complete LOOP I can wing it from
there. 

Please send replies directly to me at
pothiers%tuva.sainet@nmfecc.arpa

Thank Yew!

∂09-Mar-89  1246	Common-Lisp-mailer 	Loop 
Received: from cheops.cis.ohio-state.edu by SAIL.Stanford.EDU with TCP; 9 Mar 89  12:43:02 PST
Received: by cheops.cis.ohio-state.edu (5.59/2.890120)
	id AA04131; Thu, 9 Mar 89 15:40:50 EST
Date: Thu, 9 Mar 89 15:40:50 EST
From: Arun Welch <welch@cis.ohio-state.edu>
Message-Id: <8903092040.AA04131@cheops.cis.ohio-state.edu>
To: common-lisp@sail.stanford.edu
Subject: Loop


Can someone out there point me to documentation for/a description of the
recently-passed LOOP macro?  Portable code would be nice, too.
Converting between Interlisp Clisp forms and CL DO is really twisting
my brain...:-)

...arun


----------------------------------------------------------------------------
Arun Welch
Lisp Systems Programmer, Lab for AI Research, Ohio State University
welch@tut.cis.ohio-state.edu

∂10-Mar-89  0734	Common-Lisp-mailer 	re: [LOOP docs and source]    
Received: from crash.cs.umass.edu ([128.119.40.235]) by SAIL.Stanford.EDU with TCP; 10 Mar 89  07:34:36 PST
Received: from cousteau.cs.umass.edu by crash.cs.umass.edu (5.59/Ultrix2.0-B)
	id AA00200; Fri, 10 Mar 89 10:35:09 est
Message-Id: <2814536088-2521485@Cousteau>
Sender: DAVID%Cousteau@cs.umass.edu
Date: Fri, 10 Mar 89  10:34:48 EST
From: Forster%vax2@cs.umass.edu
To: common-lisp@sail.stanford.edu
Cc: welch@cis.ohio-state.EDU
Subject: re: [LOOP docs and source]


> From: Arun Welch <welch@cis.ohio-state.EDU>
>
> Can someone out there point me to documentation for/a description of the
> recently-passed LOOP macro?  Portable code would be nice, too.

In September of 1987, and later on New Year's in 1988, two loop macros were
advertised in this netnews group, one the actual distribution, and the other
indicating the ftp address.  I'm including editted versions of the original
messages at the end of this message.
I don't know if these correspond to the proposal (apparently from Lucid?)
100%, but they're a start, I guess, and pretty much PD, I gather.  As far as
documentation goes, perhaps the originators could forward the proposal
presented to the committee to this list?

    - David Forster

________________ KCL stuff: ________________

From: Taiichi Yuasa
 <yuasa%kurims.kurims.kyoto-u.junet%utokyo-relay.csnet@RELAY.CS.NET>

Here is my code for LOOP, which will be included in the next release of
KCL available from University of Texas.

-- Taiichi
...

;; (c) Copyright Taiichi Yuasa and Masami Hagiya, 1984.  All rights reserved.
;; Copying of this file is authorized to users who have executed the true and
;; proper "License Agreement for Kyoto Common LISP" with SIGLISP.

;;;;    loop.lsp
;;;;
;;;;         defines the sophisticated LOOP macro, with the hope it's
;;;;	     compatible with Symbolics Common Lisp.

________________ sloop stuff: ________________
From: Bill Schelter <wfs@rascal.ics.utexas.EDU>
... sloop.lisp ... is available on  rascal:/usr2/ftp/pub/sloop.lisp
Internet Address:
128.83.144.1	rascal.ics.utexas.edu rascal # sun unix
login anonymous with password guest.
...
Any bug reports or complaints (or even contented user reports)
should also go to that address.

Bill Schelter
________________ End of forwarded text ________________

∂10-Mar-89  0744	Common-Lisp-mailer 	[LOOP docs and source]   
Received: from cheops.cis.ohio-state.edu by SAIL.Stanford.EDU with TCP; 10 Mar 89  07:44:54 PST
Received: by cheops.cis.ohio-state.edu (5.59/2.890120)
	id AA07623; Fri, 10 Mar 89 10:41:58 EST
Date: Fri, 10 Mar 89 10:41:58 EST
From: Arun Welch <welch@cis.ohio-state.edu>
Message-Id: <8903101541.AA07623@cheops.cis.ohio-state.edu>
To: Forster%vax2@cs.umass.edu
Cc: common-lisp@sail.stanford.edu
In-Reply-To: Forster%vax2@cs.umass.edu's message of Fri, 10 Mar 89  10:34:48 EST <2814536088-2521485@Cousteau>
Subject: [LOOP docs and source]

Thanks.


...arun

∂22-Mar-89  0919	Common-Lisp-mailer 	Common Lisp function signatures    
Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 22 Mar 89  09:19:10 PST
Posted-Date: Wed, 22 Mar 89 09:18:16 PST
Message-Id: <8903221718.AA01878@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.59/5.51)
	id AA01878; Wed, 22 Mar 89 09:18:26 PST
To: common-lisp@sail.stanford.edu
From: goldman@vaxa.isi.edu
Subject: Common Lisp function signatures
Date: Wed, 22 Mar 89 09:18:16 PST
Sender: goldman@vaxa.isi.edu

Does anyone out there have a machine processable file containing a 
representation of the input-output type signatures of the functions of
CommonLisp?  i.e., something that would let me define a function
IO-SIGNATURE, where
IO-SIGNATURE[CONS] ==> (T T) , (CONS)
IO-SIGNATURE[VALUES-LIST] ==> (CONS), (&REST T)
IO-SIGNATURE[+] ==> (NUMBER &rest NUMBER), (NUMBER)
etc.

I would also be interested in other abstract characterizations of 
the common lisp functions, such as whether they are "applicative"
or "context dependent".

neil

∂24-Mar-89  1245	Common-Lisp-mailer 	email address change -- "cvaxa" -> "cogs"    
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 24 Mar 89  12:45:27 PST
Received: from syma.sussex.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa05669; 24 Mar 89 20:33 GMT
Received: from csuna.cogs.susx.ac.uk (csuna-gateway) by uk.ac.sussex.syma; Fri, 24 Mar 89 20:38:57 GMT
From: Aaron Sloman <aarons%cogs.sussex.ac.uk@NSS.Cs.Ucl.AC.UK>
Date: Fri, 24 Mar 89 20:33:20 GMT
Message-Id: <18371.8903242033@csuna.cogs.susx.ac.uk>
To: various_colleagues%cogs.sussex.ac.uk@NSS.Cs.Ucl.AC.UK
Subject: email address change -- "cvaxa" -> "cogs"

In case nobody else has told you, or you need reminding: Please change
all reference in University of Sussex email addresses from "cvaxa" to "cogs".

Cvaxa refers to a machine that dies this month. "cogs" comes via the new
Sequent Symmetry in our computing centre, known as "uk.ac.sussex.syma".
"cogs" is registered as a subdomain of this.
[Apologies if you have received this information more than once.]
Aaron
-----------------------------------------------------------------------
Aaron Sloman,
School of Cognitive and Computing Sciences,
Univ of Sussex, Brighton, BN1 9QN, England
    ARPANET : aarons%uk.ac.sussex.cogs@nss.cs.ucl.ac.uk
              aarons%uk.ac.sussex.cogs%nss.cs.ucl.ac.uk@relay.cs.net
    JANET     aarons@cogs.sussex.ac.uk
    BITNET:   aarons%uk.ac.sussex.cogs@uk.ac
        or    aarons%uk.ac.sussex.cogs%ukacrl.bitnet@cunyvm.cuny.edu
    UUCP:     ...mcvax!ukc!cogs!aarons
            or aarons@cogs.uucp
IN CASE OF DIFFICULTY use "syma" instead of "cogs"

∂14-Apr-89  2343	Common-Lisp-mailer 	the "N" in "NCONC"  
Received: from DST.BOLTZ.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 14 Apr 89  23:43:53 PDT
Received: from DST.BOLTZ.CS.CMU.EDU by DST.BOLTZ.CS.CMU.EDU; 15 Apr 89 02:43:45 EDT
To: common-lisp@sail.stanford.edu
cc: jmc@sail.stanford.edu
Reply-To: Dave.Touretzky@cs.cmu.edu
Subject: the "N" in "NCONC"
Date: Sat, 15 Apr 89 02:43:43 EDT
Message-ID: <2558.608625823@DST.BOLTZ.CS.CMU.EDU>
From: Dave.Touretzky@B.GP.CS.CMU.EDU

To complete the 2nd edition of my Lisp book, I am researching the origin of
the "N" convention for naming destructive functions.

>From the description of NCONC in the Lisp 1.5 Programmer's Manual (p. 62),
it seems plausible that the "N" originally stood for "No copy".  The manual
never says this explicitly, though.

If any of you Lisp historians out there can shed more light on this
important matter, I'd be much obliged.

-- Dave

∂17-Apr-89  1032	Common-Lisp-mailer 	the "N" in "NCONC"  
Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 17 Apr 89  10:32:49 PDT
Received: from INRIA.INRIA.FR by argus.Stanford.EDU with TCP; Mon, 17 Apr 89 10:21:34 PDT
Received: by inria.inria.fr (5.61+/89.0.7) via Fnet-EUnet id AA14241; Mon, 17 Apr 89 09:33:56 +0200 (MET)
Date: Mon, 17 Apr 89 09:30:16 +0200
Received: by ilog.ilog.fr, Mon, 17 Apr 89 09:30:16 +0200
From: padget@ilog.ilog.fr (Julian Padget)
Message-Id: <8904170730.AA08639@ilog.ilog.fr>
To: Dave.Touretzky@CS.CMU.EDU
Cc: common-lisp@sail.stanford.edu, jmc@sail.stanford.edu
In-Reply-To: Dave.Touretzky@b.gp.cs.cmu.edu's message of Sat, 15 Apr 89 02:43:43 EDT <2558.608625823@DST.BOLTZ.CS.CMU.EDU>
Subject: the "N" in "NCONC"

I remember this being discussed on an old lisp mailing list about 5
years ago.  KMP (I think) avowed that it was a result of a
misunderstanding which arose as follows: there was a function CONC
which destructively joined two lists together (once upon a time) and
then it was generalised into an N-ary function and renamed NCONC.
Someone else (no names remembered or given) reading the description
decided that the N prefix distinguished it as a destructive operation
and so christened destructive reverse NREVERSE, and so on.

--Julian.

∂17-Apr-89  1120	Common-Lisp-mailer 	the "N" in "NCONC"  
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 17 Apr 89  11:20:37 PDT
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 578392; Mon 17-Apr-89 14:20:32 EDT
Date: Mon, 17 Apr 89 14:19 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: the "N" in "NCONC"
To: padget@ilog.ilog.fr
cc: Dave.Touretzky@CS.CMU.EDU, common-lisp@sail.stanford.edu,
    jmc@sail.stanford.edu
In-Reply-To: <8904170730.AA08639@ilog.ilog.fr>
Message-ID: <890417141925.9.KMP@BOBOLINK.SCRC.Symbolics.COM>

    Date: Mon, 17 Apr 89 09:30:16 +0200
    From: padget@ilog.ilog.fr (Julian Padget)

    I remember this being discussed on an old lisp mailing list about 5
    years ago.  KMP (I think) avowed that it was a result of a
    misunderstanding which arose as follows: there was a function CONC
    which destructively joined two lists together (once upon a time) and
    then it was generalised into an N-ary function and renamed NCONC.
    Someone else (no names remembered or given) reading the description
    decided that the N prefix distinguished it as a destructive operation
    and so christened destructive reverse NREVERSE, and so on.

Yes, you probably heard this from me but I got the story (I think) from
Drew McDermott. When I heard it, I raced to my Lisp 1.5 manual to check
it out, and sure enough it doesn't align. I still tell the story,
though, usually disclaiming it as having come from Drew and observing it
to be `probably apocryphal' just because it's so typical of things that
really -do- happen.

∂17-Apr-89  1245	Common-Lisp-mailer 	Re: the "N" in "NCONC"   
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 17 Apr 89  12:45:35 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa09161; 17 Apr 89 20:30 BST
Date: Mon, 17 Apr 89 20:22:42 BST
Message-Id: <15142.8904171922@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: the "N" in "NCONC"
To: Julian Padget <padget%ilog.ilog.fr@NSS.Cs.Ucl.AC.UK>, 
    Dave.Touretzky@cs.cmu.edu
In-Reply-To: Julian Padget's message of Mon, 17 Apr 89 09:30:16 +0200
Cc: common-lisp@sail.stanford.edu, jmc@sail.stanford.edu

> I remember this being discussed on an old lisp mailing list about 5
> years ago.  KMP (I think) avowed that it was a result of a
> misunderstanding which arose as follows: there was a function CONC
> which destructively joined two lists together (once upon a time) and
> then it was generalised into an N-ary function and renamed NCONC.
> Someone else (no names remembered or given) reading the description
> decided that the N prefix distinguished it as a destructive operation
> and so christened destructive reverse NREVERSE, and so on.

I've long thought that this story was correct, but if you look at the
Lisp 1.5 manual you'll see that CONC is the n-arg version, NCONC is a
2-arg function, and both work without copying.

-- Jeff

∂17-Apr-89  1319	Common-Lisp-mailer 	the "N" in "NCONC"  
To:   common-lisp@SAIL.Stanford.EDU
CC:   JMC@SAIL.Stanford.EDU, padget@ILOG.ILOG.FR   
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>


I believe the term comes from ``Non-consing CONCatenate,'' which predates
Maclisp. Possbly Greenblatt, Gosper, or even Mike Levin came up with it.
The InterLisp equivalent is D- as in ``dreverse.''

			-rpg-

∂17-Apr-89  1429	Common-Lisp-mailer 	Re: the "N" in "NCONC"   
Received: from SPICE.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 17 Apr 89  14:27:16 PDT
Date: Mon, 17 Apr 1989 17:19-EDT 
From: Jamie.Zawinski <jwz@spice.cs.cmu.edu>
To:   common-lisp@SAIL.Stanford.EDU
Subject: Re: the "N" in "NCONC"  

> I believe the term comes from ``Non-consing CONCatenate,'' which predates
> Maclisp. Possbly Greenblatt, Gosper, or even Mike Levin came up with it.
> The InterLisp equivalent is D- as in ``dreverse.''

Does that mean that "Dedit" is a non-consing editor?  :-)

∂17-Apr-89  1434	Common-Lisp-mailer 	Re: the "N" in "NCONC"   
Received: from gremlin.nrtc.northrop.com by SAIL.Stanford.EDU with TCP; 17 Apr 89  14:34:38 PDT
Received: from tribble by gremlin.nrtc.northrop.com id aa03485;
          17 Apr 89 14:31 PDT
To: Dick Gabriel <RPG@sail.stanford.edu>
cc: common-lisp@sail.stanford.edu, JMC@sail.stanford.edu, 
    padget@ilog.ilog.fr, jbarnett@gremlin.nrtc.northrop.com
Subject: Re: the "N" in "NCONC" 
In-reply-to: Your message of 17 Apr 89 13:19:00 -0700.
             <1UPwyf@SAIL.Stanford.EDU> 
Date: Mon, 17 Apr 89 14:30:56 -0700
From: jbarnett@gremlin.nrtc.northrop.com

The name, "NCONC" was in existence long before InterLisp was ever thought
about.  It appeared in the Q32 LISP 1.5 and I think in the MAC Lisp on the
7094 and PDP 10.  I'm sure from my own experience that it was in vogue by
the early 1960's.  The N in NCONC may be like the D in DREVERSE, but both
NCONC and DREVERSE were in the same systems.  In any event, what is more
curious to me than the fact that the name NCONC starts with an N, is the
fact that the function was never and is not called DAPPEND or even NAPPEND.

∂18-Apr-89  0231	Common-Lisp-mailer 	the "N" in "NCONC"  
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 18 Apr 89  02:31:29 PDT
Received: from bhopal ([192.43.178.13]) by heavens-gate.lucid.com id AA09534g; Tue, 18 Apr 89 02:31:09 PDT
Received: by bhopal id AA03330g; Tue, 18 Apr 89 02:31:03 PDT
Date: Tue, 18 Apr 89 02:31:03 PDT
From: Jon L White <jonl@lucid.com>
Message-Id: <8904180931.AA03330@bhopal>
To: padget@ilog.ilog.fr
Cc: Dave.Touretzky@CS.CMU.EDU, common-lisp@sail.stanford.edu,
        jmc@sail.stanford.edu
In-Reply-To: Julian Padget's message of Mon, 17 Apr 89 09:30:16 +0200 <8904170730.AA08639@ilog.ilog.fr>
Subject: the "N" in "NCONC"

re: . . . KMP (I think) avowed that it was a result of a
    misunderstanding which arose as follows: there was a function CONC
    which destructively joined two lists together (once upon a time) and
    then it was generalised into an N-ary function and renamed NCONC.

This explanation doesn't seem very likely to me.  The Lisp 1.5 Programmer's
Manual -- which dates to mid 1962 -- shows both CONC and NCONC as being
N-ary operations.

When I first showed up around MIT in the late 60's, the common gossip
was that the "N" stood for "Non-Consing".  Interlisp (nee, BBN-Lisp)
had another nomenclature -- a prefix "D" meant "Destructive" rather
than "Non-Consing".  Interestingly, there was one exception to the
Interlisp scheme -- NCONC.  Possibly, then, it was trying to remain
compatible with Lisp 1.5.  But the pattern must have been instituted 
after the break in communications between the BBN gang and the MIT 
gang, since MacLisp's predecessor on the PDP6 had NREVERSE whereas
Interlisp has DREVERSE.


In the early days of 7094 Lisp (on CTSS), consing "too much" could
be disastrous.  People were known even back then to try tricks to
avoid it.  Despite the humongous increase in address space that the
7094 afforded over the 650, there was still the likelihood that all
of the nearly 32 thousand cells would be occupied.  And the first 
garbage collectors were known to "take a while".


Hmmmm, 32 thousand "new cells"; hmmm, we've come a long way, baby.



-- JonL --

∂19-Apr-89  0857	Common-Lisp-mailer 	questions about EVALHOOK 
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 19 Apr 89  08:56:57 PDT
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
	id AA13751; Wed, 19 Apr 89 09:57:00 -0600
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
	id AA07006; Wed, 19 Apr 89 09:56:57 -0600
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8904191556.AA07006@defun.utah.edu>
Date: Wed, 19 Apr 89 09:56:56 MDT
Subject: questions about EVALHOOK
To: common-lisp@sail.stanford.edu

I have some questions about how EVALHOOK is supposed to work in
implementations whose evaluators compile (or partially compile) forms
passed to EVAL.  Page 321 of CLtL says that this technique "renders
the EVALHOOK mechanism relatively useless".  Does this mean it's
possible that the *EVALHOOK* function might never be called by EVAL?
Or, might the form argument it receives be some kind of structure
representing the source code, instead of the Lisp source code itself? 

Also, page 323 says that "the STEP facility is implemented using this
hook".  Is this really a *requirement* on the implementation of STEP,
or just a suggestion on how it *might* be implemented? 

-Sandra
-------

∂19-Apr-89  1344	Common-Lisp-mailer 	intent of (THE <type> <expression>)
Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 19 Apr 89  13:44:06 PDT
Posted-Date: Wed, 19 Apr 89 12:44:00 PST
Message-Id: <8904192044.AA21853@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.61/5.61)
	id AA21853; Wed, 19 Apr 89 13:44:07 -0700
To: common-lisp@sail.stanford.edu
From: goldman@vaxa.isi.edu
Subject: intent of (THE <type> <expression>)
Date: Wed, 19 Apr 89 12:44:00 PST
Sender: goldman@vaxa.isi.edu

1) Is program P1 a correct common lisp program, or is it "an error":

P1:  (let ((x 0))
	(declare (integer x))
	(setf x (truncate 7 3)))

If P1 is correct, how about P2

P2:   (let ((x 0))
	(declare (integer x))
	(setf x (the integer (truncate 7 3))))

Why this is a question:  TRUNCATE returns 2 values.  Is (THE INTEGER <EXP>)
equivalent to (THE (VALUES INTEGER &rest T) <EXP>)) -- in which case P2 is
correct, and (THE INTEGER (TRUNCATE 7 3)) returns 2 values, 2 and 1?
Or is (THE INTEGER <EXP>) equivalent to 
     (THE (VALUES INTEGER &REST T) (VALUES <EXP>))
in which case P2 is correct and (THE INTEGER (TRUNCATE 7 3)) returns a single
value, 2?

Observations:  If P1 is correct, and P2 is "an error", then the 
   "transformation" of wrapping (the <type-specifier> <expression>) around
   expressions being assignmened to a variable for which a type has been
   declared is NOT a correct transformation in Common Lisp.
   Of course if BOTH P1 and P2 are incorrect, it may still be a legitimate
   transformation.

Empirical observation that raised this question:
Symbolics' implementation signals an error for P2 (interpreted, though NOT
compiled).  It does not signal an error for P1 in any case.  This is 
consistent with considering P2 to be "is an error" and considering P1 to
be either correct OR "is an error".  I don't know what their position is.
I am not able to determine a stance on this question from the text on
pp 161-162 of CLtL84.

Personal preference:  I would like (the  <type-spec> <exp>), where
<type-spec> was not a VALUES type specifier, to mean
  (the <type-spec> (VALUES <exp>))

(the (values integer) (values 1 2)) would be an error.

(the  integer (values 0 3)) would be correct and return only one value, 0.

(the (values integer integer) (values 1 2)) would be correct and return 2 
values, 1 and 2.


Remotely related question -- can DEFTYPE be used to define VALUES style
or FUNCTION style type specifiers, or only the kind that TYPEP is willing
to accept?  On my symbolics implementation, I can do
  (deftype two-integers () (values integer integer))
without any error.  The interpreter accepts
  (the (values integer integer) (values 1 2))
returning two values, 1 and 2.
but the interpreter signals an error for
  (the (two-integers) (values 1 2))
which is consistent with considering it to be an error for a use of a
type "macro" defined with DEFTYPE to produce a VALUES style type specifier.
(although the error message scarcely makes that appear to be the offense.)

Neil

∂19-Apr-89  1432	Common-Lisp-mailer 	intent of (THE <type> <expression>)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 19 Apr 89  14:32:23 PDT
Return-Path: <mincy@Think.COM>
Received: from sauron.think.com by Think.COM; Wed, 19 Apr 89 17:32:24 EDT
Received: from ZENO.THINK.COM by sauron.think.com; Wed, 19 Apr 89 17:31:33 EDT
Date: Wed, 19 Apr 89 17:31 EDT
From: Jeff Mincy <mincy@Think.COM>
Subject: intent of (THE <type> <expression>)
To: goldman@vaxa.isi.edu, common-lisp@sail.stanford.edu
In-Reply-To: <8904192044.AA21853@vaxa.isi.edu>
Message-Id: <19890419213156.5.MINCY@ZENO.THINK.COM>

    Date: Wed, 19 Apr 89 12:44:00 PST
    From: goldman@vaxa.isi.edu

    If P1 is correct, how about P2

    P2:   (let ((x 0))
	    (declare (integer x))
	    (setf x (the integer (truncate 7 3))))

    Personal preference:  I would like (the  <type-spec> <exp>), where
    <type-spec> was not a VALUES type specifier, to mean
      (the <type-spec> (VALUES <exp>))

    (the  integer (values 0 3)) would be correct and return only one value, 0.
    Neil

(Correct) type declarations are not supposed to affect
the semantics of a correct program.  Your type declaration
just changed the the semantics.  

(setq x (the integer (truncate 7 3))) should not signal an error.
After all, only one value is being used, and I want to declare
that one value.  When giving a non values type declaration such
as INTEGER, it should be taken to declare the first value.  Any
other values returned are not declared.  If I want to declare
that something returns exactly one value, and it is an integer,
then I can use the type (values integer).  

The types INTEGER and (VALUES INTEGER) should either be
equivalent or not,  and this should be specified better
in CLtL.  I think is it more useful if they are not equivalent.

-jeff

∂19-Apr-89  1522	Common-Lisp-mailer 	intent of (THE <type> <expression>)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 19 Apr 89  15:21:49 PDT
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Wed, 19 Apr 89 18:17:14 EDT
Date: Wed, 19 Apr 89 18:16 EDT
From: Barry Margolin <barmar@Think.COM>
Subject: intent of (THE <type> <expression>)
To: Jeff Mincy <mincy@Think.COM>
Cc: goldman@vaxa.isi.edu, common-lisp@sail.stanford.edu
In-Reply-To: <19890419213156.5.MINCY@ZENO.THINK.COM>
Message-Id: <19890419221642.8.BARMAR@OCCAM.THINK.COM>

    Date: Wed, 19 Apr 89 17:31 EDT
    From: Jeff Mincy <mincy@Think.COM>

	Date: Wed, 19 Apr 89 12:44:00 PST
	From: goldman@vaxa.isi.edu

	If P1 is correct, how about P2

	P2:   (let ((x 0))
		(declare (integer x))
		(setf x (the integer (truncate 7 3))))

	Personal preference:  I would like (the  <type-spec> <exp>), where
	<type-spec> was not a VALUES type specifier, to mean
	  (the <type-spec> (VALUES <exp>))

	(the  integer (values 0 3)) would be correct and return only one value, 0.
	Neil

    (Correct) type declarations are not supposed to affect
    the semantics of a correct program.  Your type declaration
    just changed the the semantics.  

The operative word is "correct".  If the expression returns two values
and the type declaration is interpreted as specifying that it returns
exactly one value, then the type declaration isn't correct.  If this is
the correct interpretation of non-VALUES type specifiers in THE forms,
then the above is just as incorrect as (the float 0).

I'm not sure what the right interpretation of this is.  As far as I can
tell, it hasn't come up in X3J13 (there's only one Cleanup issue related
to THE, and it's about a different problem).  In the description of the
THE special form, the only wording I can find that indicates either way
is the comments in the examples on p.162.  When describing the
interpretation of (the integer (+ x 3)) the comments say "the result of
+ will be an integer."  The use of the singular in these comments
implies that the declaration specifies that + will only return one
value.

However, the description of THE as used with SETF, p.96, implies the
other way.  It says that

	(setf (the <type> <place>) <value>)

is processed as if it were

	(setf <place> (the <type> <value>))

Therefore, (setf (the integer x) (truncate 7 3)) would be treated as
(setf x (the integer (truncate 7 3))).  Intuitively, the original
version seems correct, so the transformed version should be valid.  It
is certainly counterintuitive to require one to write

	(setf (the (values integer integer) x)
	      (truncate 7 3))

This latter problem could be fixed either by fixing the definition of
the THE special form, or by fixing the definition of the THE SETF-place.

                                                barmar

∂20-Apr-89  0741	Common-Lisp-mailer 	Re: the "N" in "NCONC"   
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 20 Apr 89  07:41:39 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa08443; 20 Apr 89 15:31 BST
Date: Thu, 20 Apr 89 15:25:29 BST
Message-Id: <20806.8904201425@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: the "N" in "NCONC"
To: Jon L White <@sail.stanford.edu:jonl@lucid.com>, 
    padget%ilog.ilog.fr@NSS.Cs.Ucl.AC.UK
In-Reply-To: Jon L White's message of Tue, 18 Apr 89 02:31:03 PDT
Cc: Dave.Touretzky@cs.cmu.edu, common-lisp@sail.stanford.edu, 
    jmc@sail.stanford.edu

> This explanation doesn't seem very likely to me.  The Lisp 1.5 Programmer's
> Manual -- which dates to mid 1962 -- shows both CONC and NCONC as being
> N-ary operations.

Um, JonL, when I look in the Lisp 1.5 manual, I see NCONC (p 62)
described as a 2-argument function.  CONC is n-argument,  Both are
destructive.

∂20-Apr-89  0809	Common-Lisp-mailer 	Re: the "N" in "NCONC"   
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 20 Apr 89  07:41:39 PDT
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK   via Janet with NIFTP
           id aa08443; 20 Apr 89 15:31 BST
Date: Thu, 20 Apr 89 15:25:29 BST
Message-Id: <20806.8904201425@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: the "N" in "NCONC"
To: Jon L White <@sail.stanford.edu:jonl@lucid.com>, 
    padget%ilog.ilog.fr@NSS.Cs.Ucl.AC.UK
In-Reply-To: Jon L White's message of Tue, 18 Apr 89 02:31:03 PDT
Cc: Dave.Touretzky@cs.cmu.edu, common-lisp@sail.stanford.edu, 
    jmc@sail.stanford.edu

> This explanation doesn't seem very likely to me.  The Lisp 1.5 Programmer's
> Manual -- which dates to mid 1962 -- shows both CONC and NCONC as being
> N-ary operations.

Um, JonL, when I look in the Lisp 1.5 manual, I see NCONC (p 62)
described as a 2-argument function.  CONC is n-argument,  Both are
destructive.

∂20-Apr-89  0936	Common-Lisp-mailer 	Re: the "N" in "NCONC"   
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 20 Apr 89  09:36:31 PDT
Received: from Riesling.ms by ArpaGateway.ms ; 20 APR 89 06:02:17 PDT
Sender: "Larry_Masinter.PARC"@Xerox.COM
Date: 19 Apr 89 09:36:38 PDT (Wednesday)
Subject: Re: the "N" in "NCONC"
From: masinter.PARC@Xerox.COM
To: KMP@STONY-BROOK.SCRC.Symbolics.COM
cc: padget@ilog.ilog.fr, Dave.Touretzky@CS.CMU.EDU,
 common-lisp@sail.stanford.EDU, jmc@sail.stanford.EDU
In-Reply-to: KMP%STONY-BROOK.SCRC.Symbolics:COM's message of Monday, April
 17, 1989 11:49 am 
Reply-to: masinter.PARC@Xerox.COM
Message-ID: <890420-060217-3764@Xerox>


The convention wasn't universal. While Interlisp had NCONC, it used
DREVERSE (for Destructive REVERSE) , DREMOVE, DSUBST, etc.

∂20-Apr-89  1036	Common-Lisp-mailer 	re: intent of (THE <type> <expression>) 
Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 20 Apr 89  10:35:54 PDT
Posted-Date: Thu, 20 Apr 89 09:35:50 PST
Message-Id: <8904201735.AA13354@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.61/5.61)
	id AA13354; Thu, 20 Apr 89 10:35:53 -0700
To: common-lisp@sail.stanford.edu
From: goldman@vaxa.isi.edu
Subject: re: intent of (THE <type> <expression>)
Cc: barmar@think.com, mincy@think.com
Date: Thu, 20 Apr 89 09:35:50 PST
Sender: goldman@vaxa.isi.edu

Jeff is absolutely correct in rejecting the resolution I stated as
my preference.  It would have said that:
a) (truncate 7 3) is a correct program, and it returns two values
b) (the integer (truncate 7 3)) is a correct program, and it returns one value

But all that has happened (syntactically) is the addition of a type 
declaration to a correct program.

I still think the meaning of (the <type-specifier> <expression>) needs 
clarification.
What do you think of this alternative:

1) if the <type-specifier> is not of the form (VALUES ...),
then let (VALUES <type-specifier> &rest T) be the effective type specifier.
Otherwise, <type-specifier> itself is the effective type specifier.
2) The value(s) returned by expression must be compatible with the
effective type specifer, where compatibility is as described on page 48
in the definition of VALUES style type specifiers.  [But that paragraph
should be expanded to include &allow-other-keys.  It should also make
explicit that 
  i) the  value-type list is a lambda list in which type-specifiers
     appear where parameter names would appear in a normal lambda list
 ii) none the the component type specifiers may be a VALUES type specifier
iii) the type specifiers all appear as top-level components of the value-type
     list for positional values (required or &optional),
     and as (<symbol> type-specifier) for keyword type-specifiers
     (I presume that was the intent?)  The <symbol>
     is NOT coerced to the keyword package.  For example, 


(the (values integer &optional number
	     &key (a symbol) (:b cons) &allow-other-keys)
     (values 7  8 :b '(x 1) 'a  3 'b 2))

would be correct.

(the integer (truncate 7 3) would be correct, because it is treated as
(the (values integer &rest t) (integer 7 3)

(the (values integer) (truncate 7 3)) would be an error.

Neil

∂20-Apr-89  1302	Common-Lisp-mailer 	Re: intent of (THE <type> <expression>) 
Received: from cayuga.cs.rochester.edu by SAIL.Stanford.EDU with TCP; 20 Apr 89  13:02:40 PDT
Received: from lesath.cs.rochester.edu by cayuga.cs.rochester.edu (5.59/l) id AA18246; Thu, 20 Apr 89 16:02:25 EDT
Received: from loopback by lesath.cs.rochester.edu (3.2/l) id AA02490; Thu, 20 Apr 89 16:02:14 EDT
Message-Id: <8904202002.AA02490@lesath.cs.rochester.edu>
To: common-lisp@sail.stanford.edu
Subject: Re: intent of (THE <type> <expression>) 
In-Reply-To: Your message of Thu, 20 Apr 89 09:35:50 -0800.
             <8904201735.AA13354@vaxa.isi.edu> 
Date: Thu, 20 Apr 89 16:02:10 -0400
From: quiroz@cs.rochester.edu

    Summary:  Don't disturb Unaware Callers.  Don't let THE pass
    back values that it didn't check.  [For details, search down for
    the string PROPOSAL.]

After the latest note by Neil Goldman, I think I see with less
sympathy the proposed transformations to clarify THE.  I suggest
that a guiding concern be this:  Unaware Callers don't suffer
unintended weirdness when they call a Multiple Value function.

By Unaware Callers I mean those that don not intentionally use any
of the forms that do something with multiple values.

So, I would have it this way:

    (setf x (truncate 7 3)) ; the second value is discarded, right?
    (setf x (the integer (truncate 7 3))) ; the second value is also discarded
    (setf (the integer x) (truncate 7 3))

would all do the same thing: discard the second value, even for type
checking.  I didn't request the second value, I don't want to have
to declare its type.  (Also, instead of truncate, think of a user
defined function that over time gets extended to return multiple
values, I don't want this benign extension to break anything that
worked before).

PROPOSAL:

What it boils down to, is that THE should check only as many types
as requested (and pass back only as many).  This entails rewording
the entry for THE in p. 138 of CLtL:

* If the type specifier specifier of the THE form is not of the form
(VALUES ...), only one value is checked and passed back.  Else, only
as many returned values as specified in the (VALUES ...) specifier
are checked and passed back. (Missing values are assumed to be nil,
they are checked and passed back.)  A type specifier of the form 
(VALUES ...  &rest T) is used to indicate that extra values may be
present, and are not type checked, but are passed back.

Possible draw-back:

    (multiple-value-bind (foo bar) (the integer (truncate 7 3))
       (declare (type integer foo bar))
       (list foo bar))

would be in error (bar would be nil).  The program without the THE
declaration looks correct to me, but the declaration screws it up.
That's is philosophically OK with me (Aware Callers have all the
responsibility to do the right thing; only Unaware Callers are
protected from peculiarities of the Multiple Value system), but
still some may feel it to be a touch rude.  The fix, of course,
would be:

    (multiple-value-bind (foo bar) (the (values integer integer)
                                        (truncate 7 3))
       ...)

So adding a corect declaration is still possible.

Sorry this got too long.
Cesar

∂20-Apr-89  1404	Common-Lisp-mailer 	intent of (THE <type> <expression>)     
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 20 Apr 89  14:04:41 PDT
Received: from fafnir.think.com by Think.COM; Thu, 20 Apr 89 17:04:38 EDT
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Thu, 20 Apr 89 17:03:41 EDT
Received: from joplin.think.com by verdi.think.com; Thu, 20 Apr 89 16:59:42 EDT
From: Guy Steele <gls@Think.COM>
Received: by joplin.think.com; Thu, 20 Apr 89 16:59:15 EDT
Date: Thu, 20 Apr 89 16:59:15 EDT
Message-Id: <8904202059.AA00383@joplin.think.com>
To: quiroz@cs.rochester.edu
Cc: common-lisp@sail.stanford.edu
In-Reply-To: quiroz@cs.rochester.edu's message of Thu, 20 Apr 89 16:02:10 -0400 <8904202002.AA02490@lesath.cs.rochester.edu>
Subject: intent of (THE <type> <expression>) 

   ...
   PROPOSAL:

   What it boils down to, is that THE should check only as many types
   as requested (and pass back only as many).

No, this is not cool.  THE is supposed to act purely as a declaration,
but you are changing it to require it to pass on only as many values
as the type specifer indicates.  This could change the semantics of
a suitably devious program.

Better to say that it checks as many types as requsted, but passes on
exactly the values it receives.
--Guy

∂20-Apr-89  1434	Common-Lisp-mailer 	Re: intent of (THE <type> <expression>) 
Received: from cayuga.cs.rochester.edu by SAIL.Stanford.EDU with TCP; 20 Apr 89  14:34:43 PDT
Received: from lesath.cs.rochester.edu by cayuga.cs.rochester.edu (5.59/l) id AA18692; Thu, 20 Apr 89 17:34:34 EDT
Received: from loopback by lesath.cs.rochester.edu (3.2/l) id AA02604; Thu, 20 Apr 89 17:34:28 EDT
Message-Id: <8904202134.AA02604@lesath.cs.rochester.edu>
To: Guy Steele <gls@Think.COM>
Cc: common-lisp@sail.stanford.edu
Subject: Re: intent of (THE <type> <expression>) 
In-Reply-To: Your message of Thu, 20 Apr 89 16:59:15 -0400.
             <8904202059.AA00383@joplin.think.com> 
Date: Thu, 20 Apr 89 17:34:24 -0400
From: quiroz@cs.rochester.edu

| Better to say that it checks as many types as requsted, but passes on
| exactly the values it receives.

That sounds better, indeed.  So, do both of Neil's programs remain
correct then?  (Meaning here:  "(setf x (the integer (truncate 7 3)))"
is as correct as "(setf x (truncate 7 3))")

Cesar

∂02-Jun-89  1725	X3J13-mailer 	New submission address for LASC
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 2 Jun 89  17:25:43 PDT
Received: from challenger ([192.9.200.17]) by heavens-gate id AA01255g; Fri, 2 Jun 89 16:28:47 PDT
Received: by challenger id AA01058g; Fri, 2 Jun 89 16:26:32 PDT
Date: Fri, 2 Jun 89 16:26:32 PDT
From: Jan Zubkoff <jlz@lucid.com>
Message-Id: <8906022326.AA01058@challenger>
To: common-lisp@sail.stanford.edu, x3j13@sail.stanford.edu
Subject: New submission address for LASC


LISP AND SYMBOLIC COMPUTATION Journal questions and submissions should be
sent to the following new address:

Jan Zubkoff
Associate Editor, LASC
Lucid, Inc.
Route 5, Box 2834
Crawfordville, FL 32327
904/926-8039

Please send 5 copies of your paper for review.  The final copy should be
submitted in electronic LaTex form, either by netmail or on a 1.2M floppy.

Volume 2 Issue 2 has just been mailed and Issue 3/4 will be another double
issue due to be mailed in about a month.

There have been some changes I thought you'd like to know about.

Guy L. Steele Jr. has taken a one year sabatical to devote his time to other
pressing activities.  Carolyn Talcott has graciously stepped in as Acting
Editor-in-Chief and has made short work of every paper.

Mark Wegman and L. Peter Deutsch have both resigned to devote their time to
research. 

Bob Kessler and JonL White have joined our Editorial Board and have given a
great deal of their time reviewing papers.

I'd like to thank each member of our Editorial Board for making this journal
possible.

Richard P. Gabriel		Carolyn Talcott
Daniel G. Bobrow		Kenneth Kahn
Robert S. Cartwright		Robert Kessler
Jerome Chailloux		John McCarthy
Daniel P. Friedman		Larry Masinter
Martin L. Griss			Julian Padget
Paul Hudak			David S. Touretzky
Masayuki Ida			Mitchell Wand
Gilles Kahn			John L. White

Thank you to all the authors who have submitted their work to LASC and have
made this an exceptional joural.

---jan---


∂06-Jul-89  0923	Common-Lisp-mailer 	CL flyer  
Received: from cayuga.cs.rochester.edu ([192.5.53.209]) by SAIL.Stanford.EDU with TCP; 6 Jul 89  09:22:57 PDT
Received: from sol.cs.rochester.edu by cayuga.cs.rochester.edu (5.59/m) id AA29685; Thu, 6 Jul 89 12:21:34 EDT
Received: from cayuga.cs.rochester.edu by sol.cs.rochester.edu (3.2/m) id AA06471; Thu, 6 Jul 89 12:22:17 EDT
Received: from QUCDN.QueensU.CA by cayuga.cs.rochester.edu (5.59/m) id AA29677; Thu, 6 Jul 89 12:20:17 EDT
Received: from qusuno.qucis.queensu.ca by QUCDN.QueensU.CA (IBM VM SMTP R1.2) with TCP; Thu, 06 Jul 89 12:20:55 EDT
Received: by qusuno.qucis.queensu.ca (3.2/SMI-3.2)
	id AA00289; Thu, 6 Jul 89 12:22:36 EDT
Date: Thu, 6 Jul 89 12:22:36 EDT
From: tomek@qucis.queensu.ca
Message-Id: <8907061622.AA00289@qusuno.qucis.queensu.ca>
To: cl@cs.rochester.edu
Subject: CL flyer

Dear James,
 I have just noticed the CL flyer that has been distributed at ACL meeting
in Vancouver, and I am somewhat baffled. It says that the number 3 of volume
15 (to appear in September) will contain a paper "Non-Singular Concepts
in Natural Language Discourse" by Nick Cercone. Well, Nick is the second of the
TWO authors of this paper, i.e., it is Tomek Strzalkowski and Nick Cercone.
My name may be difficult to spell but that's no reason to drop the first
author's name altogether! Just hoping my name will appear on top of the paper.

 Greetings,

 Tomek Strzalkowski

∂10-Jul-89  1449	Common-Lisp-mailer 	SYMBOL-MACROLET
Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 10 Jul 89  14:49:08 PDT
Posted-Date: Mon, 10 Jul 89 13:49:20 PST
Message-Id: <8907102149.AA27155@vaxa.isi.edu>
Received: from LOCALHOST by vaxa.isi.edu (5.61/5.61)
	id AA27155; Mon, 10 Jul 89 14:49:23 -0700
To: common-lisp@sail.stanford.edu
From: goldman@vaxa.isi.edu
Subject: SYMBOL-MACROLET
Date: Mon, 10 Jul 89 13:49:20 PST
Sender: goldman@vaxa.isi.edu

Is it the case that the expansion code for a symbol-macro, (unlike a lexical
macro introduced with MACROLET) has not means to obtain the current
lexical environment?

neil

∂10-Jul-89  1534	Common-Lisp-mailer 	SYMBOL-MACROLET
Received: from STONY-BROOK.SCRC.Symbolics.COM by SAIL.Stanford.EDU with TCP; 10 Jul 89  15:34:06 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 623054; 10 Jul 89 18:05:48 EDT
Date: Mon, 10 Jul 89 18:05 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: SYMBOL-MACROLET
To: goldman@vaxa.isi.edu
cc: common-lisp@sail.stanford.edu
In-Reply-To: <8907102149.AA27155@vaxa.isi.edu>
Message-ID: <19890710220541.4.MOON@EUPHRATES.SCRC.Symbolics.COM>

    Date: Mon, 10 Jul 89 13:49:20 PST
    From: goldman@vaxa.isi.edu

    Is it the case that the expansion code for a symbol-macro, (unlike a lexical
    macro introduced with MACROLET) has not means to obtain the current
    lexical environment?

There is no expansion code for a symbol-macro.  A symbol-macro always
expands into the same thing; one specifies the expansion directly, 
rather than specifying Lisp forms that will compute and return the
expansion.  Of course a symbol macro could expand into a call to a
regular macro, which could then expand into whatever it wants, potentially
looking at the lexical environment.