Kent Pitman's Common Lisp References
This comment, as with all comments received during X3J13's first public review
period, was gratefully acknowledged but not deemed important enough to require
immediate action (which action would have delayed publication of the standard).
--Kent Pitman (13 Mar 2002)
Date: Tue, 29 Dec 1992 16:18-0500
From: Paul Robertson <xxxxxxxxxx@xxxxxxxxxxx.xxxx.xxxxxxxxx.xxx>
Subject: Comments in Electronic Form
To: xxxxx-xx@xx.xxx.xxx
Sandra Loosemore request that I mail an electronic version of my ANSI CL
comments. I have therefore stripped formatting from the original and
attached the raw text of the hardcopy comments. I hope this helps.
Paul Robertson
------------------------------------------------------------------------
Name: Paul Robertson
Affiliation: Dynamic Object Language Group
Address: xxxxxxxxxxxxxxxx
City: xxxxxxxxx State: xx ZIP/Postal code: xxxxx
Country: xxx
Phone number: xxx xxx-xxxx Fax number: xxx xxx-xxxx
Email address: xxxxxxxxxxxxxxxxxxxxxxxx
Comment number: 1
dpANS draft version: Draft 12.24 X3J13/92-102
Section/Page reference:
Type of comment: ___ Editorial _X_ Technical
Suggested committee action: Change the specification.
Comment
There are many in the industry would would like to use Common Lisp
for commercial programming projects who are restricted from this by a
few iritating problems in the language. There are vendors who would
provide viable platforms were it not for the importance supporting
standards. A major problem is that the language is too big, its
implementations are too big, and compiled programs written in it are
too big. The standard needs to balance the needs to provide backward
compatibility with the flexibility to accomodate future application
development in a practical commercial environment. This flexibility
can be achieved by dividing the language.
If a kernal language is chosen and all other functions are removed,
everyone will reinvent them as incompatible extensions. That is a
disaster. If we leave everything in, the language will not be used
except by a decreasing number of LISP zealots. That too is a disaster.
We propose a way therefore of having our cake and eating it too. We
propose to keep everything, but to divide the language into mandatory
and discretionary parts. We can keep the flexibility of LISP to evolve
upon a well founded and nimble base language while retaining backward
compatibility through the discretionary components.
The history of the langauge has seen many stylistic trends come and go.
Many programs were written during these periods for which we would like to
retain compatibility. As the trends have passed, the language has accumulated
the overhead of these trends. We now seek a way of shaking loose the
barnacles while retaining the hull intact, furthermore we want to achieve
this without removing the support for legacy lisp code before its time.
Examples of stylistic trends include overuse of property lists in pre-OO-lisp
days, Heavy reader table hacking in implementing embedded languages. Heavy
dependence of dynamic binding and interpretation as a way of extending the
language, Overuse of the CONS datastructure in pre structure and pre-OO-lisp
etc.
In an era of openness and coexistance, the idea of a huge monolithic lisp
that doesn't 'fit in' with its environment is preposterous.
Since the addition of CLOS, the nature of Common Lisp has changed. We might
prefer now to have a better thought out heterarchy of standard types
and generic functions that operate over them. The CLtL sequences now
look like a very immature attempt. While it would be disruptive and
premature to force an evolution of the language to accomodate these
ideas now, by opening up the language by making many of its
historical parts discretionary, we allow the language users and
implementers to experiment with such directions that may be the focus
of a future standardization effort.
Pragmatically, with the AI boom behind us, and investment opportunity
for LISP at an all time low, standardizing Common Lisp as the current
huge monolithic language could finally kill the language. The
standardization committee must bear the responsbility of their
actions in this respect. The proposal to section the standard to
provide an explicit mechanism for smaller implementations will
generate renewed interest in the language, and will provide a greater
opportunity to lisp vendors to push back with new packaging for their
products.
The proposal below, while specific, is not refined. It is not a
proposal that has been studied enough to be adopted without change.
It should be used as a starting point for a careful division of the
language into essential and discretionary parts. We recognise that
the proposed standard already has specific accomodation for subsets,
but we believe that that is too weak. The stigma of a subset
prevents their development and if developed their acquisition.
History supports this perspective. We believe that by making a
language conform to the standard by implementing the mandatory CORE
only, we will protect the core language. By carefully enumerating
the details of the discretionary components, we will avoid the
randomness of reinvention that can be witnessed in the scheme community.
The following proposal adds no new functions, and removes none.
There is reason to believe that adding and removing may be useful
too, but in the interests of retaining as much benefit from the
cleanup work as possible, and reducing the scope of the proposed
reclassification of the language subparts we have restricted our comments
to reclassifying the contents. We propose that the language be divided
into a mandatory core component refered to below as "ANSI-CL CORE" and
16 descretionary components (ANSI-CL DEVELOPMENT*, ANSI-CL INTERP*
ANSI-CL LOOP*, ANSI-CL STRUCTURES*, ANSI-CL CONDITIONS*, ANSI-CL RANDOM*
ANSI-CL MATH*, ANSI-CL LISTS*, ANSI-CL STRINGS*, ANSI-CL SEQUENCES*
ANSI-CL PATHNAMES*, ANSI-CL FILES*, ANSI-CL PRETTY*, ANSI-CL FORMAT*
ANSI-CL READTABLE*, ANSI-CL TIME*).
Each function, variable, constant, macro, method, type, class etc in the
spec should be annotated to indicate to which component it belongs. All
implementors must implement the full CORE, but may decide which of the
optional components to implement. Implementers who would have implemented
all of this spec, will be able to implement all discretionary components
and claim ANSI-CL MOBY compliance. Others may provide separately loadable
subparts, or separate runtime kernals from development systems in a manner
consistant with engineering-wise pragmatic usage. This will promote wider
use of the language, greater numbers of viable product points and greater
room for the evolution of the language through discretionary component
replacement.
Suggested Change
Cost to Implementers - Almost None
If they would have implemented everything, they still can. Implementers
must specify which components they are providing.
Cost to Users - Almost None
If they choose a MOBY implementation, there is no change. If they
choose an implementation that provides some or none of the discretionary
components, the user must determine which components his program depends on
Benefits to Implementers - Numerous
Better able to structure their applications to fit needs of users.
Better able to match the size of the implementation to the target
system.
Providing an industry standard that won't be obsolete the day it's
published.
Benefits to Users - Numerous
Finally be able to justify LISP for projects where previously its huge
monolithic nature kept it as a research toy only.
Backward Compatibility - Same as proposed standard
Details
Define the core language "ANSI-CL CORE":
Section 1.1 ... 1.6
Mandatory ANSI-CL CORE.
Section 1.7: Sentence #1
The language described in this standard consists of a number of components.
(Mandatory components)
ANSI-CL CORE
(Discretionary Components)
ANSI-CL DEVELOPMENT*
ANSI-CL INTERP*
ANSI-CL LOOP*
ANSI-CL STRUCTURES*
ANSI-CL CONDITIONS*
ANSI-CL RANDOM*
ANSI-CL MATH*
ANSI-CL LISTS*
ANSI-CL STRINGS*
ANSI-CL SEQUENCES*
ANSI-CL PATHNAMES*
ANSI-CL FILES*
ANSI-CL PRETTY*
ANSI-CL FORMAT*
ANSI-CL READTABLE*
ANSI-CL TIME*
An implementation that supports the mandatory as well as all discretionary
parts will be said to be "ANSI-CL MOBY" compliant.
Section 1.7: Paragraph #2
Add the following:
The mandatory components may not be subseted. The discretionary
components may be on a case by case basis either omited entirely (preferably),
or partially supplied.
Section 1.7: Paragraph #3
A language that conforms to this requirement shall be described as being
subset of common lisp as specified by ANSI #. A subset should advertise
which discretionary components have been fully or partially included.
Section 1.7: Paragraph #4
New paragraph:
An implementation is free to provide additional/alternative discretionary
components. Such components will be outside of the standard, but will
not affect the language fro being considered a subset or MOBY implementation
of common lisp as specified by ANSI.
Section 1.8
Symbols should be segmented into symbols added by which components.
The mandatory components symbols would always be present, the discretionary
component symbols would be present if the discretionary component were
supplied. The same Symbol may appear under multiple discretionary sections.
Section 2 Syntax
All mandatory. ANSI-CL CORE
Section 3
3.1: All mandatory. ANSI-CL CORE
3.2: All mandatory. ANSI-CL CORE
3.4: All mandatory. ANSI-CL CORE
3.5: All mandatory. ANSI-CL CORE
3.6: All mandatory. ANSI-CL CORE
3.7:
COMPILE belongs to discretionary component ANSI-CL DEVELOPMENT*
EVAL belongs to discretionary component ANSI-CL INTERP*
rest of 3.7: Mandatory. ANSI-CL CORE
Section 4 Types and Classes
All mandatory. ANSI-CL CORE.
Section 5 Data and Control
All mandaory. ANSI-CL CORE.
Section 6 Iteration
6.1 LOOP belongs to discretionary component ANSI-CL LOOP*
rest of 6: Mandatory. ANSI-CL CORE
Section 7 Objects
All mandatory ANSI-CL CORE
Section 8 Structures
Belongs to discretionary component ANSI-CL STRUCTURES*
Section 9 Conditions
Belongs to discretionary component ANSI-CL CONDITIONS*
Section 10 Symbols
All mandatory ANSI-CL CORE
Section 11 Packages
All mandatory ANSI-CL CORE
Section 12 Numbers
12-49 RANDOM-STATE ... 12-53 *RANDOM-STATE* discretionary ANSI-CL RANDOM*
12-27 SIN,COS,TAN
12-28 ASIN, ACOS, ATAN
12-32 SINH, COSH, ASINH, ACOSH, ATANH
12-40 EXP, EXPT
12-41 GCD
12-43 LCM
12-44 LOG
12-48 SQRT ISQRT
12-54 CIS
12-56 CONJUGATE
12-57 PHASE
All belong to discretionary component ANSI-CL MATH*
Rest of 12 mandatory ANSI-CL CORE
Section 13 Characters
All mandatory ANSI-CL CORE
Section 14 Conses
14-11 COPY-TREE
14-12 SUBLIS, NSUBLIS
14-14 SUBST ... NSUBST-IF-NOT
14-28 NCONC
14-29 NRECONC
14-30 APPEND
14-31 REVAPPEND, BUTLAST, NBUTLAST
14-33 LAST
14-34 LDIFF
14-36 NTHCDR
14-39 MAPC ... MAPCON
14-41 ACONS
14-44 COPY-ALIST
14-45 PAIRLIS
14-51 INTERSECTION, NINTERSECTION
14-52 ADJOIN
14-55 SET-DIFFERENCE, NSET-DIFFERENCE
14-57 SET-EXCLUSIVE-OR, NSET-EXCLUSIVE-OR
14-58 SUBSETP
14-59 UNION, NUNION
All belong to discretionary component ANSI-CL LISTS*
All others: mandatory ANSI-CL CORE
Section 15 Arrays
All mandatory ANSI-CL CORE
Section 16 Strings
16-7 STRING-UPCASE ... 16-11 STRING@<=
All belong to discretionary component ANSI-CL STRINGS*
All others: mandatory ANSI-CL CORE
Section 17 Sequences
All belong to discretionary component ANSI-CL SEQUENCES*
Section 18 Hash Tables
All mandatory ANSI-CL CORE
Section 19 Filenames
All belong to discretionary component ANSI-CL PATHNAMES*
Section 20 Files
All belong to discretionary component ANSI-CL FILES*
Section 21 Streams
21-9 FILE-STREAM
21-25 FILE-LENGTH
21-26 FILE-POSITION
21-28 FILE-STRING-LENGTH
21-29 OPEN
21-35 WITH-OPEN-FILE
21-59 END-OF-FILE
All belong to discretionary component ANSI-CL FILES*
All others: mandatory ANSI-CL CORE
Section 22.1
All mandatory ANSI-CL CORE
Section 22.2
All belong to discretionary component ANSI-CL PRETTY*
Sectio 22.3
All belong to discretionary component ANSI-CL FORMAT*
All others: mandatory ANSI-CL CORE
Section 23 Reader
23-4 COPY-READTABLE
23-5 MAKE-DISPATCH-MACRO-CHARACTER
23-12 READTABLEP
23-13 SET/GET-DISPATCH-MACRO-CHARACTER
23-14 SET/GET-MACRO-CHARACTER
23-16 SET-SYNTAX-FROM-CHAR
23-17 WITH-STANDARD-IO-SYNTAX
All belong to discretionary component ANSI-CL READTABLE*
All others: mandatory ANSI-CL CORE
Section 24 System Construction
24-3 COMPILE-FILE
24-5 COMPILE-FILE-PATHNAME
All belong to discretionary component ANSI-CL DEVELOPMENT*
All others: mandatory ANSI-CL CORE
Section 25 Environment
25.1.1 Top level loop: discretionary component ANSI-CL DEVELOPMENT*
25.1.4 Time: discretionary component ANSI-CL TIME*
25-5 DECODE-UNIVERSAL-TIME
25-6 ENCODE-UNIVERSAL-TIME, GET-UNIVERSAL-TIME, GET-DECODED-TIME
25-14 TIME
25-15 INTERNAL-TIME-UNITS-PER-SECOND, GET-INTERNAL-REAL-TIME
25-16 GET-INTERNAL-RUN-TIME
All belong to discretionary component ANSI-CL TIME*
25-8 APROPOS, APROPOS-LIST
25-9 DESCRIBE
25-10 DESCRIBE-OBJECT
25-12 TRACE, UNTRACE
25-13 STEP
25-17 DISASSEMBLE, DOCUMENTATION
25-20 ROOM
25-21 ED
25-22 INSPECT
25-23 DRIBBLE
25-24 +, ++, +++
25-25 *, **, ***
25-26 /, //, ///
All belong to discretionary component ANSI-CL DEVELOPMENT*
All others: mandatory ANSI-CL CORE