[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
a standardization proposal
- To: common-lisp%SU-AI.ARPA@mcc
- Subject: a standardization proposal
- From: <krall%amethyst%mcc-pp@mcc (Ed Krall)>
- Date: Thu, 05 Jun 1986 12:24:00 -0000
- Cc: guzman%mcc-pp@mcc, hall%mcc-pp@mcc
- Posted-date: Thursday, 5 June 1986, 08:24-CDT
- Sender: KRALL%mcc-pp@mcc
I have been monitoring the portability issue for some
time and have been dismayed by the subset contingent.
The Lisp community must learn from Ada: subsets are
useful for testing, training, teaching, but not for
A program is fully portable
I. if every symbol used in the program is instantiated
(1) in the "Common-Lisp-only" package, or
(2) in the package associated with program
II. if the program uses only the standard readtable
or one defined by the program itself, and
III. if it was written with porting to many systems as
a goal, and
IV. if "everything else is OK!".
Thus no "compatible"
extensions may be used, and -- most importantly -- there
is no other package of symbols visible in the program.
Every symbol used is in (1) or (2) and everything not in
(1) and (2) is completely shadowed.
Implication: if I want a specific mathematical function
in my programs, I MUST reproduce ALL of the code of the
function and everything it depends on and put it
into my program! Even then I may not be able to
reproduce the environment successfully.
Implication #2: the Common Lisp packages must be identical
throughout the target world, containing no more nor no
less than any other Common Lisp package if the program is
to be ported.
I don't believe the portability impact on Lisp is any
different than that of C or Pascal or Ada; it's just that
Lisp programmers take advantage of "goodies". In C the
program is delivered with its library. So too in Lisp.
I urge the Common Lisp community to reject the pleas for
Microelectronics and Computer Technology Corporation
9430 Research Blvd.
Austin, Texas 78759