Kent Pitman's Common Lisp References

Common Lisp Public Review Comments: Paul Robertson

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