Hello all you LISP experts.
I learned LISP about 25 years ago and used it intensely
for about 2 years. I had to convert the project to another
language because LISP of 1970 was simply too slow. It was
very expensive to run so slowly on a main frame.
Decades passed. Now we have cheap workstations. I've
also been hearing that LISP is now acceptably fast. SO,
like Rip Van Winkle I come back to LISP, only to find that
LISP is still not a mainstream language. This has certain
bad consequences.
1. The compilers, having fewer users per product, are more
likely to have bugs in them then compilers of Fortran,
Cobol or (is this a dirty word?) C++.
2. It's harder to find LISP programmers available for six
months or two years. In a mainstream language this is no
problem.
My question is, why after these decades, is Lisp, with
all its power and elegance, basically still confined to AI people in
Universities? What's wrong?
In article <·····················@alchemy.chem.utoronto.ca> M. Bersohn,
········@alchemy.chem.utoronto.ca writes:
> My question is, why after these decades, is Lisp, with
>all its power and elegance, basically still confined to AI people in
>Universities? What's wrong?
I believe that two difficulties have kept Lisp out of the mainstream. You
have already mentioned the first reason: for a long time to
run Lisp well required a Lisp machine, a very expensive proposition. In
fact, this remains the best way to run Lisp, but no longer such an
expensive proposition.
The second obstacle involves marketing. Lisp grew up in AI Labs, and
generally people still associate it with AI. For instance, if you examine
the marketing approach of Symbolics, you will see that they still
emphasize AI, even though the history of the company amply demonstrates
that this strategy loses big. It loses because no one does AI outside of
a few AI labs! People reason that if their problem doesn't involve AI,
then they can't benefit from Lisp. Nothing could be further from the
truth. We have been using Lisp machine technology for 6 years in the
domain of continuous systems simulation. Although Flavors and Genera form
the
foundation of our work, we employ no techniques that would be recognized
as AI. Yet we could never have accomplished what we did in any other
operating system. It remains, I believe, the finest program
development environment you can get; it certainly makes anything I've
ever seen in Unix look pathetic.
The point is that Lisp ranks top as a general purpose programming
language. C doesn't even come close; C against Lisp looks like Bobby
Riggs playing against Billy Jean King. But until people stop thinking,
"Lisp => AI", Lisp will remain outside the mainstream.
>
Tim Larkin
Federal Nutrition Laboratory
Tower Road
Ithaca, New York
····@cornell.edu
607-255-7008
From: John Doner
Subject: Re: Why Isn't Lisp a Mainstream Language?
Date:
Message-ID: <1jekrqINN339@news.aero.org>
In article <·····················@alchemy.chem.utoronto.ca>, ········@alchemy.chem.utoronto.ca (M. Bersohn) writes:
|> My question is, why after these decades, is Lisp, with
|> all its power and elegance, basically still confined to AI people in
|> Universities? What's wrong?
I think syntax and readability have a lot to do with it. Functional
notation puts off many people; they find it natural for short
expressions, but confusing for larger ones. Notation is extremely
important in mathematical communication, and the usual conventions of
infix operators, omitting parentheses, operations indicated by position
(superscripts for exponentiation, juxtaposition for multiplication),
and no doubt others, were introduced for good reasons and are of great
value. I have experienced many occasions where some proof was praised as
elegant, a significant improvement, etc., and where the key step was
devising a better notation. Lisp notation is simple and provides a
clear semantics, but for these very reasons is unable to provide much
syntactic flexibility or "information-hiding" (sweeping necessary but
picayune details into the background so they don't obscure the main
points).
Of course, C is almost as good for producing unreadable programs as APL,
and in the hands of a skilled obfuscator, can match the worst that Lisp
can do. But I do think that people's first impression when confronted
with some moderately complex textbook example programs will be that C is
more readable than Lisp.
John Doner
Math. Dept., UCSB
Date: Mon, 18 Jan 1993 11:11 EST
From: John Doner <·····@aero.org>
In article <·····················@alchemy.chem.utoronto.ca>, ········@alchemy.chem.utoronto.ca (M. Bersohn) writes:
|> My question is, why after these decades, is Lisp, with
|> all its power and elegance, basically still confined to AI people in
|> Universities? What's wrong?
I think syntax and readability have a lot to do with it. Functional
notation puts off many people; they find it natural for short
expressions, but confusing for larger ones. Notation is extremely
important in mathematical communication, and the usual conventions of
infix operators, omitting parentheses, operations indicated by position
(superscripts for exponentiation, juxtaposition for multiplication),
and no doubt others, were introduced for good reasons and are of great
value. I have experienced many occasions where some proof was praised as
elegant, a significant improvement, etc., and where the key step was
devising a better notation. Lisp notation is simple and provides a
clear semantics, but for these very reasons is unable to provide much
syntactic flexibility or "information-hiding" (sweeping necessary but
picayune details into the background so they don't obscure the main
points).
Surely you jest. Lisp macros provide an extremely powerful tool for
syntaxtic flexibility, extensibility, and information hiding. Nothing
in C (or just about any other language) even comes close to this.
Of course, C is almost as good for producing unreadable programs as APL,
and in the hands of a skilled obfuscator, can match the worst that Lisp
can do. But I do think that people's first impression when confronted
with some moderately complex textbook example programs will be that C is
more readable than Lisp.
Funny, the following looks OK to me:
(with-database (db "employees")
(with-transaction (db)
(for-each ((e employee) (:where (> (employee-salary) salary)))
... do something ...)))
Well, I guess it could be better -- I really would rather have this:
(defmacro map-over-employees-exceeding-salary ((database salary) &body body)
`(with-database (db ,database)
(with-transaction (db)
(for-each ((e employee) (:where (> (employee-salary) ,salary)))
,@body))))
and then use this:
(map-over-employees-exceeding-salary ("employees" 50000.0)
... do something ...)
I doubt that many non-Lisp programmers can so easily extend their
language to include the new MAP-OVER-EMPLOYEES-EXCEEDING-SALARY form.
From: Jeff Dalton
Subject: Re: Why Isn't Lisp a Mainstream Language?
Date:
Message-ID: <8260@skye.ed.ac.uk>
In article <·····················@netlabs.com> ·····@netlabs.com (Larry Wall) writes:
>The obvious answer is almost TOO obvious. People prefer "horrible" languages.
Some do; others don't. I think it's a mistake to think one side or
the other must be wrong. That is: there's more than one good way
to do programming languages.
>I believe in the waterbed theory of linguistics. If you push down
>here, it pops up there. The design of Lisp pushed down so hard on the
>morphology that it bulges out everywhere else. Lisp is your classical
>Turing Tarpit. If expressivity only measures what's possible, Lisp is
>wonderful. If it measures what's easy to say and understand, Lisp gets
>a big yawn from most folks.
One thing this leaves out is that many people find Lisp more readable
and easier to understand than other programming languages.
From: Jeff Dalton
Subject: Re: Why Isn't Lisp a Mainstream Language?
Date:
Message-ID: <8261@skye.ed.ac.uk>
In article <·····················@wavehh.hanse.de> ········@wavehh.hanse.de (Martin Cracauer) writes:
>I wonder, if it is possible, to change the synatx of LISP without
>loosing it's advantages.
You mean it's other advantages? For many of us, Lisp's syntax is
an advantage, not a disadvantage.
-- jd
Here are my favorite reasons:
(1) The major Common Lisp implementations that run under Unix are all
monolithic systems. They are also HUGE. This means that, as a
practical issue, it is very difficult to write SMALL programs in
common lisp. Shared libraries, eval servers, and (perhaps) various
extensions to the ANSI block compilation stuff could help but are
either unavailable or surprise prone.
(2) My experience with both Lucid and Franz implementations suggests
that using libraries implemented in other languages (typically "C")
doesn't work very well. There are several problems:
(A) The "foreign function" interface needs to be kept up to date.
Without automatic support this is tedious and error prone.
(B) There is no way to debug problems in foreign code.
(C) Wild pointers and array overflows in foreign code break the
entire system so that NOTHING can be debugged.
(D) Direct mappings of "C" library calls into foreign calls
usually yields an interface that is inferior to the native
interface and "weird" from a Lisp perspective.
(E) At least until multi-threaded "C" libraries are the norm,
using non-reentrant libraries from a multi-threaded
environment is trouble prone.
(F) Even without threads, a GC that moves objects can cause a lot
of trouble.
(3) "C++" programming environments are getting a lot of attention, and
are getting pretty good.
(4) Common Lisp I/O is poorly designed for systems tasks and is
typically very slow. Common Lisp streams suffer from the PASCAL
design flaw that supposes that files can be productively modeled as
big arrays. Standard Common Lisp streams are not extensible and the
usual CLOSish fix requires a generic dispatch per character or byte.
For fun, compare the overhead of "getc" in "C" with the overhead of a
generic function dispatch and a couple of slot fetches.
(5) There are a lot of libraries and support tools available for "C"
and "C++" programmers. These include window system support, database
interfaces, numerical computation libraries, parser generators,
lexical analyzers, etc. If they cannot be used easily and naturally
from Lisp, then any technical advantages that Lisp has will be swamped
by the practical advantages having those libraries available.
(6) I need to be able to share my results with my colleagues.
Given the current lisp implementations, a "C" programmer needs to
switch to a lisp environment in order to use any code that I might
write. He or she then needs to:
(A) Buy a lot more memory ($1,000) and some more disk ($1,000).
(B) Shell out $6,000 to $8,000 dollars for a Lisp development
environment.
So, having spent $10,000, my collegue gets to:
(A) Run my code.
(B) Work in a very, very, inverior "C" development environment.
This puts a real burden on me to write extraordinarily brilliant code.
So.... what (IMHOP) has to be done?
(1) Lisp implementors need to provide compilers that produce standard
object files that can be placed in libraries (both shared and static)
and that can be manipulated by the standard system tools.
(2) The lisp "core" needs to be provided as a shared library so that
"C" programmars can use routines written in lisp by adding no more
than "-llisp" to their "cc" command lines. The lisp core also needs
to be a lot smaller than it currently is on most unix boxes.
(3) Tools need to be provided to at least partially automate the task
of generating "C" interfaces to lisp code, and lisp interfaces to "C"
code.
(4) A natural mechanism for working with typed "C" pointers in lisp and
lisp pointers in "C" needs to be developed.
*** Flame retardant ****
Please note that I am quite aware that some of the above issues are
technically difficult, especially given the semantics of Common Lisp.
I am explicitly not talking about hows, just about whats. Furthmore,
my dealings over the years with people at both Franz and Lucid have
been very pleasant and productive.
--
-- Jim Mayer
Phone: (716) 422-9407
Webster Research Center Intelnet phone: 8*222-9407
Xerox Corporation Internet Email: ·····@wrc.xerox.com
800 Phillips Road, 0128-29E XNS Email: James L Mayer:Wbst128:xerox
Webster, New York 14580 Facsimile: (716) 265-7133
In article <···················@fliff.wrc.xerox.com> ·····@wrc.xerox.com (Jim Mayer) writes:
(B) Shell out $6,000 to $8,000 dollars for a Lisp development
environment.
Since several people have now thrown out numbers in this range, I feel
obliged to point out that the price of Common Lisp has dropped in the
last several years. New options include CLISP and CMU CL, available
without charge, as well as a high-powered, user-friendly development
environment (LispWorks from Harlequin Inc.) for $2500.
Lawrence G. Mayka
AT&T Bell Laboratories
···@iexist.att.com
Standard disclaimer.
···@cbnewsc.ATT.COM (lawrence.g.mayka) writes:
>In article <···················@fliff.wrc.xerox.com> ·····@wrc.xerox.com (Jim Mayer) writes:
> (B) Shell out $6,000 to $8,000 dollars for a Lisp development
> environment.
>Since several people have now thrown out numbers in this range, I feel
>obliged to point out that the price of Common Lisp has dropped in the
>last several years. New options include CLISP and CMU CL, available
>without charge, as well as a high-powered, user-friendly development
>environment (LispWorks from Harlequin Inc.) for $2500.
That is still too much for many cases. CMU CL etc may be
as good as possible, *BUT* for a majority of potential LISP users like
me (BTW, I think that LISP is the best language ever! :-)
there should exist a reasonably priced CL development environments for
Intel-based machines. Such environment should be able to produce stand-alone
code because sometimes it would be nice to sell/give away/spread in-house
the developed code without paying more.
With OS/2 and Windows NT and the likes, the size of the system is not so
important now, but the price is. For a WPS aware SmallTalk/V 2.0 environment
you have to pay less than $1000, and you can distribute your application!
I would be very happy to buy a real Common Lisp development environment
for my PC (running OS/2) if it were at *most* as expensive as SmallTalk/v
(which is too expensive, by the way). As I said, I do not believe that
the size is not so important now,
I comfortably used Lucid Common Lisp on a Sun 4/110
with 16 MB of memory and 300 MB of disk. Now my home PC has 16MB of memory
and its disk is also about the same size and it is clearly much *faster* than
the 4/110. But is there any WPS aware Common Lisp environments for OS/2
which can produce stand-alone executables? At least I do not know...
And remember, most of the C or C++ code may be written under DOS/WINDOWS/
WINDOWS-NT/OS2, not UNIX. So the LISP system should be running under
those system.
In article <······················@cs.joensuu.fi>, ·······@cs.joensuu.fi
(Jarmo Ahonen) wrote:
>
> ···@cbnewsc.ATT.COM (lawrence.g.mayka) writes:
>
> >In article <···················@fliff.wrc.xerox.com> ·····@wrc.xerox.com (Jim Mayer) writes:
>
> there should exist a reasonably priced CL development environments for
> Intel-based machines. Such environment should be able to produce stand-alone
> code because sometimes it would be nice to sell/give away/spread in-house
> the developed code without paying more.
>
> With OS/2 and Windows NT and the likes, the size of the system is not so
> important now, but the price is. For a WPS aware SmallTalk/V 2.0 environment
> you have to pay less than $1000, and you can distribute your application!
>
> I would be very happy to buy a real Common Lisp development environment
> for my PC (running OS/2) if it were at *most* as expensive as SmallTalk/v
> (which is too expensive, by the way).
See the FAQ for Franz Allegro CL\PC for Windows 3.1, and Procyon CL for
OS/2.
Both include rich development environments and also facilities for creating
stand-alone applications.
John Carroll
------
Cambridge University Computer Laboratory
Pembroke Street, Cambridge CB2 3QG, UK
E-Mail: ···@cl.cam.ac.uk
Tel: +44 223 334600 / Fax: +44 223 334678
In article <·················@cbnewsc.ATT.COM> ···@cbnewsc.ATT.COM
(lawrence.g.mayka) writes:
>In article <···················@fliff.wrc.xerox.com> ·····@wrc.xerox.com
> (Jim Mayer) writes:
>
> (B) Shell out $6,000 to $8,000 dollars for a Lisp development
> environment.
>
>Since several people have now thrown out numbers in this range, I feel
>obliged to point out that the price of Common Lisp has dropped in the
>last several years. New options include CLISP and CMU CL, available
>without charge, as well as a high-powered, user-friendly development
>environment (LispWorks from Harlequin Inc.) for $2500.
Harlequin has especially good educational pricing. We got it for our
part-time MS program for a Sun for under $1K, I believe. I heard Franz now
has similar educational pricing. Lucid also has a University program for
site licenses. We got *unlimited* SPARC licenses for the Hopkins Applied
Physics Lab for $11K. This included Lisp, CLIM and XLT (their development
environment). And all these numbers are for UNIX workstations; PC and
Mac prices are lower.
- Marty
(proclaim '(inline skates))
--
In article <···················@fliff.wrc.xerox.com>, ·····@wrc.xerox.com (Jim Mayer) writes:
|>(1) The major Common Lisp implementations that run under Unix are all
|>monolithic systems. They are also HUGE. This means that, as a
|>practical issue, it is very difficult to write SMALL programs in
|>common lisp. Shared libraries, eval servers, and (perhaps) various
|>extensions to the ANSI block compilation stuff could help but are
|>either unavailable or surprise prone.
So get a better Lisp system. I run Macintosh Common Lisp on my PowerBook 100
(a stinking little 1/2 Spec processor) with no ill effects. I can move the code
simply to my bigger machines. I can also run MachTen 4.3 BSD Unix on it too
but not both at once.
|>(4) Common Lisp I/O is poorly designed for systems tasks and is
|>typically very slow. Common Lisp streams suffer from the PASCAL
|>design flaw that supposes that files can be productively modeled as
|>big arrays. Standard Common Lisp streams are not extensible and the
|>usual CLOSish fix requires a generic dispatch per character or byte.
|>For fun, compare the overhead of "getc" in "C" with the overhead of a
|>generic function dispatch and a couple of slot fetches.
You mean they aren't extensible? Ooops. Guess I better throw out those Comm
Toolbox stream objects I wrote. Gosh, thanks for letting me know.
As for fast, they're fast enough. By fast enough I mean that with proper coding
practices (the proper declarations in the proper places) I don't think "Gosh,
that's slow." If I find things "fast enough" on my PB100, then they're usually
fast enough on a faster machine.
|> (A) Buy a lot more memory ($1,000) and some more disk ($1,000).
|> (B) Shell out $6,000 to $8,000 dollars for a Lisp development
|> environment.
|>
|>So, having spent $10,000, my collegue gets to:
|>
|> (A) Run my code.
|> (B) Work in a very, very, inverior "C" development environment.
|>
|>This puts a real burden on me to write extraordinarily brilliant code.
|>
|>So.... what (IMHOP) has to be done?
Ummm, buy MCL? I mean, MCL is $500. It consumes about 6 meg of disk. The
aforementioned PowerBook cost me $1K. For $6K-$8K, you can get a *very* nice
Quadra to run it on. The critter is only about 20 MIPS, but as I said, the
code I write on my PowerBook while in a cafe works just fine. When I give it
to my friends with Quadras it works even better.
|>
|>(1) Lisp implementors need to provide compilers that produce standard
|>object files that can be placed in libraries (both shared and static)
|>and that can be manipulated by the standard system tools.
|>
|>(2) The lisp "core" needs to be provided as a shared library so that
|>"C" programmars can use routines written in lisp by adding no more
|>than "-llisp" to their "cc" command lines. The lisp core also needs
|>to be a lot smaller than it currently is on most unix boxes.
|>
|>(3) Tools need to be provided to at least partially automate the task
|>of generating "C" interfaces to lisp code, and lisp interfaces to "C"
|>code.
Hear, hear! Well spoken! Can't agree more.
|>
|>(4) A natural mechanism for working with typed "C" pointers in lisp and
|>lisp pointers in "C" needs to be developed.
MCL has a mechanism for dealing with "MacPtrs" pointers to Mac data structures.
They are objects like any other Lisp object, and you can pass them around.
They work like a charm. There are even undocumented hooks for gc-able macptrs.
|>
|>*** Flame retardant ****
|>
|>Please note that I am quite aware that some of the above issues are
|>technically difficult, especially given the semantics of Common Lisp.
|>I am explicitly not talking about hows, just about whats. Furthmore,
|>my dealings over the years with people at both Franz and Lucid have
|>been very pleasant and productive.
|>
Okay, so you want a well-integrated Lisp system. Have you considered getting
a Macintosh?
|>--
|>-- Jim Mayer
|> Phone: (716) 422-9407
|>Webster Research Center Intelnet phone: 8*222-9407
|>Xerox Corporation Internet Email: ·····@wrc.xerox.com
|>800 Phillips Road, 0128-29E XNS Email: James L Mayer:Wbst128:xerox
|>Webster, New York 14580 Facsimile: (716) 265-7133
|>
Jon
In article <·····················@nntpd.lkg.dec.com> ······@eris.enet.dec.com (Jon Callas) writes:
In article <···················@fliff.wrc.xerox.com>, ·····@wrc.xerox.com (Jim Mayer) writes:
|>(1) The major Common Lisp implementations that run under Unix are all
|>monolithic systems. They are also HUGE. This means that, as a
|>practical issue, it is very difficult to write SMALL programs in
|>common lisp. Shared libraries, eval servers, and (perhaps) various
|>extensions to the ANSI block compilation stuff could help but are
|>either unavailable or surprise prone.
So get a better Lisp system. I run Macintosh Common Lisp on
my PowerBook 100 (a stinking little 1/2 Spec processor) with
no ill effects. I can move the code simply to my bigger
machines. I can also run MachTen 4.3 BSD Unix on it too but
not both at once.
Alas, MCL doesn't run very well on my SPARCstation, and my code isn't
likely to run very well on even a large Macintosh right now. I've
thought of it, but that doesn't make it practical. Also please note the
phrase "The major Common Lisp implementations that run under Unix". I
am quite aware of MCL and the nice little Allegro system for PC's.
Another possibly interesting system is ELFIN, from the "Franz Custom
Software Services Group." To quote from Franz's newsletter:
Franz has turned its Common Lisp compiler expertise
to developing ELFIN, a min-Lisp system specifically
designed to be embedded in applications and used as
an extension language for customizing the software.
ELFIN is small (100 Kb), implements full CL
semantics, yet is scalable to include arbitrary Lisp
functionality. It is C-callable, multi-threaded, and
has extensive C and C++ integration. ELFIN is
designed for tommorow's technology, with machine code
compilation capability, generation scavenging garbage
collection, CLOS, and an interactive development
environment.
I haven't seen it, so I can't comment further.
|>(4) Common Lisp I/O is poorly designed for systems tasks and is
|>typically very slow. Common Lisp streams suffer from the PASCAL
|>design flaw that supposes that files can be productively modeled as
|>big arrays. Standard Common Lisp streams are not extensible and the
|>usual CLOSish fix requires a generic dispatch per character or byte.
|>For fun, compare the overhead of "getc" in "C" with the overhead of a
|>generic function dispatch and a couple of slot fetches.
You mean they aren't extensible? Ooops. Guess I better throw
out those Comm Toolbox stream objects I wrote. Gosh, thanks
for letting me know.
As for fast, they're fast enough. By fast enough I mean that
with proper coding practices (the proper declarations in the
proper places) I don't think "Gosh, that's slow." If I find
things "fast enough" on my PB100, then they're usually fast
enough on a faster machine.
COMMON LISP streams are NOT extensible. MCL may very well provide a
hook to let you add extensions, certainly both Lucid and Allegro do.
The most commonly talked about extension was proposed to the X3J13
committee by David N. Gray, then of Texas Instruments. The Allegro
Common Lisp stream system is based on Gray's work. They are very
flexible and work very well. They also involve a generic function
dispatch per operation and do not compare well, performance wise, with
I/O in C or C++.
One alternative would be to have non-extensible stream protocol
coupled with an extensible fill/flush mechanism. Characters and/or
bytes would be placed in (removed from) a buffer (perhaps via inline
function calls). When the buffer filled up (emptied) the underlying,
CLOS based, mechanism would be invoked. This is, essentially, what
the extensible streams package in C++ does.
|> (A) Buy a lot more memory ($1,000) and some more disk ($1,000).
|> (B) Shell out $6,000 to $8,000 dollars for a Lisp development
|> environment.
|>
|>So, having spent $10,000, my collegue gets to:
|>
|> (A) Run my code.
|> (B) Work in a very, very, inverior "C" development environment.
|>
|>This puts a real burden on me to write extraordinarily brilliant code.
|>
|>So.... what (IMHOP) has to be done?
Ummm, buy MCL? I mean, MCL is $500. It consumes about 6 meg of disk. The
aforementioned PowerBook cost me $1K. For $6K-$8K, you can get a *very* nice
Quadra to run it on. The critter is only about 20 MIPS, but as I said, the
code I write on my PowerBook while in a cafe works just fine. When I give it
to my friends with Quadras it works even better.
Macs are very nice machines. Part of the reason they are good at what
they do is that they don't try to do everything. I could probably be
very happy working on a big Macintosh, but then I would be unable to
communicate with my co-workers or my (internal) customers. This is
part of the reason that Common Lisp is not a mainstream language.
Anyway, for $600,000 to $800,000 my hundred or so collegues get *very*
nice Quadras (they really are very nice) that run their code slower
than molasses in November and require them to learn a new development
environment, redesign their custom hardware, and rewrite their device
drivers and user interface code. Then they still have to program
using "foreign" functions from a common lisp environment that they
don't want to know about.
|>
|>(1) Lisp implementors need to provide compilers that produce standard
|>object files that can be placed in libraries (both shared and static)
|>and that can be manipulated by the standard system tools.
|>
|>(2) The lisp "core" needs to be provided as a shared library so that
|>"C" programmars can use routines written in lisp by adding no more
|>than "-llisp" to their "cc" command lines. The lisp core also needs
|>to be a lot smaller than it currently is on most unix boxes.
|>
|>(3) Tools need to be provided to at least partially automate the task
|>of generating "C" interfaces to lisp code, and lisp interfaces to "C"
|>code.
Hear, hear! Well spoken! Can't agree more.
|>
|>(4) A natural mechanism for working with typed "C" pointers in lisp and
|>lisp pointers in "C" needs to be developed.
MCL has a mechanism for dealing with "MacPtrs" pointers to Mac data structures.
They are objects like any other Lisp object, and you can pass them around.
They work like a charm. There are even undocumented hooks for gc-able macptrs.
To they understand the type of the object to which they point?
Foreign pointers in Allegro are implemented as integers without any typing
information. They did this, I believe, because adding typing
information would have meant "boxing" all foreign pointers which
would have slowed down their foreign function interface. Since the
foreign function interface tends to be used at a very low level, this
would be a bad thing.
Again, part of the problem is that every vendor has their own
mechanism for supporting "foreign" objects.
|>
|>*** Flame retardant ****
|>
|>Please note that I am quite aware that some of the above issues are
|>technically difficult, especially given the semantics of Common Lisp.
|>I am explicitly not talking about hows, just about whats. Furthmore,
|>my dealings over the years with people at both Franz and Lucid have
|>been very pleasant and productive.
|>
Okay, so you want a well-integrated Lisp system. Have you considered getting
a Macintosh?
Yes. It isn't practical, and it doesn't solve the problems I talked
about. I'm glad you are happy with Macintosh Common Lisp. I am
generally very happy programming in Allegro Common Lisp.
Unfortunately, the fact that lisp is NOT a "Mainstream" language puts
a considerable burden on a lot of people that wish it was.
|>--
|>-- Jim Mayer
|> Phone: (716) 422-9407
|>Webster Research Center Intelnet phone: 8*222-9407
|>Xerox Corporation Internet Email: ·····@wrc.xerox.com
|>800 Phillips Road, 0128-29E XNS Email: James L Mayer:Wbst128:xerox
|>Webster, New York 14580 Facsimile: (716) 265-7133
|>
Jon
-- Jim
--
-- Jim Mayer
Phone: (716) 422-9407
Webster Research Center Intelnet phone: 8*222-9407
Xerox Corporation Internet Email: ·····@wrc.xerox.com
800 Phillips Road, 0128-29E XNS Email: James L Mayer:Wbst128:xerox
Webster, New York 14580 Facsimile: (716) 265-7133
In article <··················@fliff.wrc.xerox.com> ·····@wrc.xerox.com (Jim Mayer) writes:
>Alas, MCL doesn't run very well on my SPARCstation
Hmm, I wonder if anyone has run MCL under Liken (the Mac emulator that runs
on SPARCstations and HP's).
--
Barry Margolin
System Manager, Thinking Machines Corp.
······@think.com {uunet,harvard}!think!barmar
From: Jeff Dalton
Subject: Re: Why Isn't Lisp a Mainstream Language?
Date:
Message-ID: <8314@skye.ed.ac.uk>
In article <·····················@nntpd.lkg.dec.com> ······@eris.enet.dec.com (Jon Callas) writes:
>
>In article <···················@fliff.wrc.xerox.com>, ·····@wrc.xerox.com (Jim Mayer) writes:
>|>(4) Common Lisp I/O is poorly designed for systems tasks and is
>|>typically very slow. Common Lisp streams suffer from the PASCAL
>|>design flaw that supposes that files can be productively modeled as
>|>big arrays.
I'm not sure what you mean by this.
>|> Standard Common Lisp streams are not extensible and the
>|>usual CLOSish fix requires a generic dispatch per character or byte.
>|>For fun, compare the overhead of "getc" in "C" with the overhead of a
>|>generic function dispatch and a couple of slot fetches.
>
>You mean they aren't extensible? Ooops. Guess I better throw out those Comm
>Toolbox stream objects I wrote. Gosh, thanks for letting me know.
They're not extensible in standard, portable CL.
I would agree that CL I/O is sometimes noticeably slower than C I/O.
However, it should be possible for a reasonable, extensible
implementation to avoid any generic function overhead for
individual characters.
>|>(1) Lisp implementors need to provide compilers that produce standard
>|>object files that can be placed in libraries (both shared and static)
>|>and that can be manipulated by the standard system tools.
The standard tools aren't really prepared to handle Lisp's needs for
data initialization. It's possible to work around this to a large
extent, but it's a pain.
>|>(2) The lisp "core" needs to be provided as a shared library so that
>|>"C" programmars can use routines written in lisp by adding no more
>|>than "-llisp" to their "cc" command lines. The lisp core also needs
>|>to be a lot smaller than it currently is on most unix boxes.
Exactly!
-- jd
In article <····@skye.ed.ac.uk> ····@aiai.ed.ac.uk (Jeff Dalton) writes:
In article <·····················@nntpd.lkg.dec.com> ······@eris.enet.dec.com (Jon Callas) writes:
>
>In article <···················@fliff.wrc.xerox.com>, ·····@wrc.xerox.com (Jim Mayer) writes:
>|>(4) Common Lisp I/O is poorly designed for systems tasks and is
>|>typically very slow. Common Lisp streams suffer from the PASCAL
>|>design flaw that supposes that files can be productively modeled as
>|>big arrays.
I'm not sure what you mean by this.
Mayer's statement could be even stronger: Common Lisp I/O is NOT
designed for systems tasks.
>|> Standard Common Lisp streams are not extensible and the
>|>usual CLOSish fix requires a generic dispatch per character or byte.
>|>For fun, compare the overhead of "getc" in "C" with the overhead of a
>|>generic function dispatch and a couple of slot fetches.
>
>You mean they aren't extensible? Ooops. Guess I better throw out those Comm
>Toolbox stream objects I wrote. Gosh, thanks for letting me know.
They're not extensible in standard, portable CL.
I would agree that CL I/O is sometimes noticeably slower than C I/O.
This is a little misleading. No disagreement that Common Lisp I/O is
expensive; it's powerful, and there's a price to pay for that. Similar
functionality in an I/O system for C would be similarly expensive.
The essential difference between C and Common Lisp wrt I/O is that
C doesn't have it, so C programmers (usually) have no problem choosing
the appropriate level for their I/O code (generally erring in the
direction of using too low-level functionality). Common Lisp biases
people towards its own portable I/O system, which apparently makes it
difficult to see the alternatives.
On the other hand, every CL implementation I've used has allowed system
level I/O with little trouble. It's not portable, but it's simple, and a
couple of lines of non-portable code isn't so objectionable (system-level
C code isn't portable either). It would be useful if vendors advertised
their low-level I/O interfaces, but lacking this it's still easy to
figure out.
However, it should be possible for a reasonable, extensible
implementation to avoid any generic function overhead for
individual characters.
>|>(1) Lisp implementors need to provide compilers that produce standard
>|>object files that can be placed in libraries (both shared and static)
>|>and that can be manipulated by the standard system tools.
The standard tools aren't really prepared to handle Lisp's needs for
data initialization. It's possible to work around this to a large
extent, but it's a pain.
>|>(2) The lisp "core" needs to be provided as a shared library so that
>|>"C" programmars can use routines written in lisp by adding no more
>|>than "-llisp" to their "cc" command lines. The lisp core also needs
>|>to be a lot smaller than it currently is on most unix boxes.
Exactly!
-- jd
In article <····@skye.ed.ac.uk> ····@aiai.ed.ac.uk (Jeff Dalton) writes:
In article <·····················@nntpd.lkg.dec.com> ······@eris.enet.dec.com (Jon Callas) writes:
>In article <···················@fliff.wrc.xerox.com>, ·····@wrc.xerox.com (Jim Mayer) writes:
>|>(4) Common Lisp I/O is poorly designed for systems tasks and is
>|>typically very slow. Common Lisp streams suffer from the PASCAL
>|>design flaw that supposes that files can be productively modeled as
>|>big arrays.
I'm not sure what you mean by this.
Streams are associated with a single underlying type, such as
"character", "base-character", or "(signed-byte 16)". There is no
easy way to mix different representations on a single output stream.
One cannot, for example, mix formatted and binary output on a single
stream, or, for that matter, (signed-byte 8) and (unsigned-byte 16)
output on a single binary stream. If one wants to mix different
types, then one is constrained to use a least common denominator type,
such as (unsigned-byte 8) and use "write-byte" for all output.
>|> Standard Common Lisp streams are not extensible and the
>|>usual CLOSish fix requires a generic dispatch per character or byte.
>|>For fun, compare the overhead of "getc" in "C" with the overhead of a
>|>generic function dispatch and a couple of slot fetches.
>
>You mean they aren't extensible? Ooops. Guess I better throw out those Comm
>Toolbox stream objects I wrote. Gosh, thanks for letting me know.
They're not extensible in standard, portable CL.
I would agree that CL I/O is sometimes noticeably slower than C I/O.
However, it should be possible for a reasonable, extensible
implementation to avoid any generic function overhead for
individual characters.
I agree. I think that the right solution is probably similar to what
C++ does with its stream classes. In C++ generic operations are
invoked on a "per-buffer" basis instead of a "per-token" basis.
>|>(1) Lisp implementors need to provide compilers that produce standard
>|>object files that can be placed in libraries (both shared and static)
>|>and that can be manipulated by the standard system tools.
The standard tools aren't really prepared to handle Lisp's needs for
data initialization. It's possible to work around this to a large
extent, but it's a pain.
I agree for "C" only linkers. I think, though, that a "C++" capable
linker ought to be able to handle Common Lisp's needs relatively well.
In "C++" class instances are put together by "constructors" that
can perform arbitrary computations. Statically allocated objects are
initialized before the main program is invoked.
>|>(2) The lisp "core" needs to be provided as a shared library so that
>|>"C" programmars can use routines written in lisp by adding no more
>|>than "-llisp" to their "cc" command lines. The lisp core also needs
>|>to be a lot smaller than it currently is on most unix boxes.
Exactly!
-- jd
--
-- Jim Mayer
Phone: (716) 422-9407
Webster Research Center Intelnet phone: 8*222-9407
Xerox Corporation Internet Email: ·····@wrc.xerox.com
800 Phillips Road, 0128-29E XNS Email: James L Mayer:Wbst128:xerox
Webster, New York 14580 Facsimile: (716) 265-7133
From: Thomas M. Breuel
Subject: Re: Why Isn't Lisp a Mainstream Language?
Date:
Message-ID: <1kehs1INN15g@life.ai.mit.edu>
In article <···················@fliff.wrc.xerox.com>, ·····@wrc.xerox.com (Jim Mayer) writes:
|> (D) Direct mappings of "C" library calls into foreign calls
|> usually yields an interface that is inferior to the native
|> interface and "weird" from a Lisp perspective.
|>
|> (E) At least until multi-threaded "C" libraries are the norm,
|> using non-reentrant libraries from a multi-threaded
|> environment is trouble prone.
|>
|> (F) Even without threads, a GC that moves objects can cause a lot
|> of trouble.
This is primarily a problem with C, not with Lisp: C interface
definitions leave too much unspecified, and C runtime representations
usually lack some important information (like array bounds).
The kind of mess you get into when you try to do remote function calls,
find pointer bugs, or send data structures over the network are an
indication that even in C itself, this creates problems.
Thomas.