Here at IBUKI we do not think that "Lisp is Dead." Symbolic processing
is still a very under used technology and is clearly useful for many
applications (also the death of Lisp is not born out by our experience or
revenues which are better than ever).
As Bill Carlson from Franz pointed out each of the vendors can provide
support for applications. IBUKI runtime licenses are about the same
as those quoted in his note and it is NOT our experience that these charges
are major problems for delivery. IBUKI has been a leader in delivery
systems for applications. We offer two strategies that address the issue
of size.
1) IBUKI Common Lisp is already highly customizable. We have customers
who have delivered applications that run under DOS and occupy less than
150k bytes of 286 memory. The application I had in mind includes list
operations, the GC and some amount of arithmetic. Our customization
tools allow Lisp Kernal modification as well as reorganizing user code.
It does not reorganizing code to reduce working set size but simply
flushes unused code completely. Our implementation technology also has
the side effect that the same customization analysis works across the
more than 40 different machines we support.
2) At IJCAI last year we showed a version of our compiler that output
modules that could be directly linked with C code, i.e., the IBUKI
compiler has a mode whose behavior is exactly the same as a traditional
C compiler. This "old fashioned" Link and Go strategy allows IBUKI Common
Lisp to be used in conjunction with other CASE tools and at the same time
preserves the ability to debug in IBCL itself. One part of our demo at
IJCAI showed that a file containing the single function
(defun 3n+1 (n) (if (evenp n) (\ n 2) (3n+1 (1+ (* 3 n)))))
(which can have BIGNUM intermediate values for FIXNUM arguments) could be
compiled and linked into a C program (using ld) and then called from C
on arbitrary C int's. The resulting working set was under 350K bytes.
Each Common Lisp vendor will eventually supply facilities like these.
Lisp and Symbolic Processing is only starting to become useful in the
commercial world. Lisp is far from dead.
Richard Weyhrauch
President
IBUKI
PS: the latest release of IBUKI Common Lisp is a substantial departure
from it's KCL roots. IBCL has a completely new memory management system,
new calling sequences for functions (so it is not object compatible with
KCL), CLOS support and many other new options (see above). Therefore
Bill's listing of IBUKI Common Lisp with KCL should be regarded as out
of date.
===============================================================================
Richard Weyhrauch IBUKI
···@ibuki.com 1447 North Shoreline Blvd.
Mountain View, CA 94043
(415) 961-4996 fax (415) 961-8016
In article <··················@ibuki.com> ···@ibuki.com (Richard Weyhrauch) writes:
>2) At IJCAI last year we showed a version of our compiler that output
>modules that could be directly linked with C code, i.e., the IBUKI
>compiler has a mode whose behavior is exactly the same as a traditional
>C compiler. This "old fashioned" Link and Go strategy allows IBUKI Common
>Lisp to be used in conjunction with other CASE tools and at the same time
>preserves the ability to debug in IBCL itself.
This is an excellent idea which more implementations should support.
However, Lisp needs different sorts of initialization than does C.
For example, symbol and lists constants have to be created. Since
"ln" doesn't do such things, some sort of trick has to be used (maybe
the user has to call some init procedure from "main"), or else rather
severe restrictions must apply.
In article <····@skye.ed.ac.uk> ····@aiai.UUCP (Jeff Dalton) writes:
...
>However, Lisp needs different sorts of initialization than does C.
>For example, symbol and list constants have to be created. Since
>"ln" doesn't do such things, some sort of trick has to be used (maybe
>the user has to call some init procedure from "main"), or else rather
>severe restrictions must apply.
Constant data is immutable [in Scheme, and I presume CL] and does not
require runtime initialization. Automatic memory management usually
needs some initialization, but that is not typically supplied with C.
If all data is statically declared, no memory management may be needed.
Some C load modules need to be initialized.
I really do not see this case being different between C and compiled
Lisps. [Code is code and data is data, (except, of course, in Lisp) :^].
-Ken
From: Jeff Dalton
Subject: Re: Link and go
Date:
Message-ID: <2271@skye.ed.ac.uk>
In article <····@tekcrl.LABS.TEK.COM> ····@mrloog.WR.TEK.COM (Ken Dickey) writes:
>Constant data is immutable [in Scheme, and I presume CL] and does not
>require runtime initialization. [...]
>I really do not see this case being different between C and compiled
>Lisps. [Code is code and data is data, (except, of course, in Lisp) :^].
What I'm asking isn't whether Lisp and C are the same in principle
but whether the current C technology can handle compiled Lisp ".o"
files. Getting the C linker to do the initialization needed by
Lisp might be a problem even if it could in principle be done at
link-time.
In article <····@tekcrl.LABS.TEK.COM> ····@mrloog.WR.TEK.COM (Ken Dickey) writes:
KD>>Constant data is immutable [in Scheme, and I presume CL] and does not
KD>>require runtime initialization. [...]
>
KD>>I really do not see this case being different between C and compiled
KD>>Lisps.
In article <····@skye.ed.ac.uk> ····@aiai.UUCP (Jeff Dalton) writes:
JD>What I'm asking isn't whether Lisp and C are the same in principle
JD>but whether the current C technology can handle compiled Lisp ".o"
JD>files. Getting the C linker to do the initialization needed by
JD>Lisp might be a problem even if it could in principle be done at
JD>link-time.
It depends. What do you mean by `current C technology'? Dynamic,
incremental linkers? Mixed-code systems [e.g. w Saber interpreter]?
PARC's Portable Common Runtime System? [Remember that C with Unix is
circa '72--there is a lot of `old technology' out there]. How much
control to you have over the production tools? What is *the* C
linker?
If you are using newer C development tools, dynamic initialization and
binding means smarter linkers. If you are using Un*x [old technology]
static linkers, you have to supply the smarts yourself. As soon as
you start moving to newer technologies, the question becomes more
complex because you have to start stating which technologies you are
using.
If the question you are asking is whether current Lisps can produce
C-linkable `.o' files, the answer is typically not, because old
technology C linkers don't have the smarts. {On the other hand, some
compilers [DEC's Scheme->C and Brandeis' Gambit] have back ends which
produce C code which, when compiled, is by nature C-linkable 8^}
If you are asking if any Lisp compilers use old style C linker
technology, the answer is yes {e.g.: "ld $1 unvax_start_t.o
/lib/crt0.o unassist.o expand.o dynload.o float.o -lm -lc -e start -o
$2"}.
If you are asking if some Lisp compilers can put out code you can burn
into EPROMS, the answer is yes [the data really is static!].
If you are looking for a particular code generation format for a
specific project, let's get specific.
Sorry about the rambling reply, but I think that you are asking a
complex question. If the complexity is only on this side, you can
help me out.
-Ken ····@mrloog.WR.TEK.COM
From: Jeff Dalton
Subject: Re: why lisp is dead
Date:
Message-ID: <2258@skye.ed.ac.uk>
In article <··················@ibuki.com> ···@ibuki.com (Richard Weyhrauch) writes:
>Each Common Lisp vendor will eventually supply facilities like these.
>Lisp and Symbolic Processing is only starting to become useful in the
>commercial world. Lisp is far from dead.
Part of the problem is that the burden of proof seems to be on those
who advocate Lisp and that it's necessary to overcome the widespread
prejudice against Lisp's syntax and the image many people have of Lisp
as large and slow. There's also a prejudice against garbage
collection as a storage management strategy. Even people who do use
Lisp often feel they have to take great care not to generate any
garbage, which sometimes means they have to use Lisp in a rather
un-Lisplike way.
In article <····@skye.ed.ac.uk> ····@aiai.UUCP (Jeff Dalton) writes:
>[...] There's also a prejudice against garbage
>collection as a storage management strategy. Even people who do use
>Lisp often feel they have to take great care not to generate any
>garbage, which sometimes means they have to use Lisp in a rather
>un-Lisplike way.
There are at least two categories of Lispers who feel they have to take
care not to generate garbage - the unreformed C hackers, and the hackers
experienced enough to have once written a program that spent 90%+ of its
time allocating and recovering storage...
There might be less prejudice against GC if someone could demonstrate that
sufficiently large C programs almost always have homemade allocation
machinery that could be more efficiently replaced by general mechanisms.
On the other hand, I've noticed that well-written C programs will exploit
some detail of the storage requirements (< 100 objects at any time, no
circular structures, etc) so as to not need a fully general allocation
and recovery scheme. Perhaps the right answer is to specialize the
storage management code, by a process similar to compiler optimization;
there has been a little research on this, as yet inconclusive.
stan shebs
·····@apple.com
From: lawrence.g.mayka
Subject: Re: why lisp is dead
Date:
Message-ID: <15218@cbnewsc.ATT.COM>
In article <····@goofy.Apple.COM> ·····@Apple.COM (Stan Shebs) writes:
>In article <····@skye.ed.ac.uk> ····@aiai.UUCP (Jeff Dalton) writes:
>>collection as a storage management strategy. Even people who do use
>>Lisp often feel they have to take great care not to generate any
>>garbage, which sometimes means they have to use Lisp in a rather
>>un-Lisplike way.
...
>and recovery scheme. Perhaps the right answer is to specialize the
>storage management code, by a process similar to compiler optimization;
Compilation and garbage collection have some similarities in this
respect. Both instruction execution and storage management can
often be left unoptimized until after the application is up and
running. Only then may one need to go back and optimize the 20%
or fewer high-runner sequences that are generating 80% or more of
the overhead. High-powered Lisp systems such as Symbolics Genera
offer storage management options such as "areas" and "resources"
for just such situations.
And for both code generation and storage management, automatic
optimization is generally more cost-effective than that done by
hand, and premature hand-optimization may even do more harm than
good.
Lawrence G. Mayka
AT&T Bell Laboratories
···@ihlpf.att.com
Standard disclaimer.