In article <···················@sacral.cis.ohio-state.edu>
·····@sacral.cis.ohio-state.edu (Arun Welch) writes:
> I think an associated question we should be asking is "How can we
> increase Lisp's popularity"? Knowing why it isn't popular is a good
> thing to discuss, but it would also be good to know where to go from
> here. Another question is "Should Lisp be a mainstream language?" I'm
> not sure the answer to that is yes. A lot of neat ideas have risen out
> of Lisp not having been standardised to death early on. CLOS is a case
> in point. If we'd standardised on Interlisp and LOOPS or Zetalisp and
> Flavors I think we'd be a lot poorer today.
Yes "Where to go from here?" I am disappointed that the Lisp leadership is
not addressing this question. This begs for something like the Common Lisp
project but aimed at making Lisp smaller and faster in an organized way. I
was reading about a KERNEL lisp specification in Lisp and Symbolic
Computation. Perhaps something along these lines should be hit with force.
Lisp leadership where are you? Give us something to be hopeful for.
As far as Lisp's popularity. When Arabic numerals were first introduced to
people using Roman numerals it took them 400 years to convert to Arabic.
What's new? Forget the Lisp haters. Dwelling on why Lisp is not popular can
lead to no useful activity. If Lisp is a good idea it will still be here
after C++ is gone. Even if Lisp was "perfect" the Lisp haters would not want
to use it, so why try to make them happy. Let's make the people who like
Lisp happy for now, the rest will take its course.
If this thread is going to lead to anything useful I would hope it be to
expose Lisp's weak points and instigate a new Lisp direction to fix them.
For sure, most of those that worked on the Common Lisp project would delight
in an opportunity for another major refinement. Perhaps Clinton's new
technology direction will provide the money to do it.
--
Bill Vrotney
BAH/Advanced Decision Systems
In article <······················@ads.com> ········@ADS.COM (Bill Vrotney) writes:
>
>In article <···················@sacral.cis.ohio-state.edu>
>·····@sacral.cis.ohio-state.edu (Arun Welch) writes:
>
>> I think an associated question we should be asking is "How can we
>> increase Lisp's popularity"? Knowing why it isn't popular is a good
>> thing to discuss, but it would also be good to know where to go from
>> [...]
>Yes "Where to go from here?" I am disappointed that the Lisp leadership is
>not addressing this question. This begs for something like the Common Lisp
>project but aimed at making Lisp smaller and faster in an organized way. I
>[...]
Every once in a while this thread pops up, with people lamenting over the
size of Common Lisp. Usually, someone (me, in this instance) will point out
that there is a small, standardized (IEEE) lisp around: Scheme.
I am crossposting this to comp.lang.scheme because I feel the point made above
applies to some extent to scheme as well.
Although the technical side of scheme has been very well handled, I find the
lack of scheme in the marketplace quite disturbing. According to the FAQ,
there is only _one_ commercial implementation of scheme running on UNIX
workstations (Chez Scheme).
There are several free implementations around, but all are either toy
implementations or are concerned with being an "extestion language" for
applications written in C. As a result they have no compilers and no
development environments. Even MIT Scheme is not suited for serious,
production quality development (IMHO). No foreign-function interface, for
one.
It can be argued that academia has done its job in presenting us with
extremely elegant standards (R4RS and IEEE), but the commercial sector has
dropped the ball. Why, for example, do none of the CL vendors also have
scheme systems for sale?
Do we have to wait around for Dylan to appear? Scheme offers, to a large
extent, what Dylan promises at some uncertain time in the future.
Kaveh
--
------------
Kaveh Kardan ·····@taarna.UUCP
Systeme Taarna ·······@eole.umontreal.qc.ca
Montreal Quebec Canada (514)844-8448
In article <······················@cc.umontreal.ca> ·······@ERE.UMontreal.CA (Kardan Kaveh) writes:
In article <······················@ads.com> ········@ADS.COM (Bill Vrotney) writes:
...
Every once in a while this thread pops up, with people lamenting over the
size of Common Lisp. Usually, someone (me, in this instance) will point out
that there is a small, standardized (IEEE) lisp around: Scheme.
I am crossposting this to comp.lang.scheme because I feel the point made above
applies to some extent to scheme as well.
Although the technical side of scheme has been very well handled, I find the
lack of scheme in the marketplace quite disturbing. According to the FAQ,
there is only _one_ commercial implementation of scheme running on UNIX
workstations (Chez Scheme).
I sell SCM, which runs on UNIX workstations, on MSDOS floppy disks.
This is as portable a medium as you are likely to find for UNIX
workstations. However, I am willing to put it on another format. The
FAQ probably does not mention me as a commercial vendor because SCM is
also availble via FTP.
There are several free implementations around, but all are either toy
implementations or are concerned with being an "extestion language" for
applications written in C.
SCM was written to be the base of a symbolic algebra program written
in R4RS Scheme.
As a result they have no compilers and no development environments.
If you are working on Unix workstations then there is no problem.
Emacs + psd1.0 provides source code single stepping and breakpointing,
code formatting and send-defun. SCM (through SLIB) provides trace and
untrace. I find this a potent combination.
The Hobbit Compiler (by Tanel Tammet) for SCM is in alpha test
and should be ready soon. However, as SCM runs only 15 times slower
than hand crafted C code (on most machines) and loads very quickly,
the lack of the compiler has not hampered my development efforts.
No foreign-function interface, for one.
There are directions for adding foreign-functions to SCM in code.doc
in the distribution. Many people have done so. So I think it is not
too difficult.
It can be argued that academia has done its job in presenting us with
extremely elegant standards (R4RS and IEEE), but the commercial sector has
dropped the ball.
Perhaps if I charged more, I would be taken more seriously. But
consider this: for the price of a "commercial" implementation
(n x $1000) you could hire me or someone else to add a substantial
amount of stuff to SCM.
Some things which could be added to SCM are:
Profiling (how much time spent in each routine)
Dynamic Linking (There is a GNU package which does this on Unix
systems and Carrette has also suggested a fairly portable method)
Editor (buffers + GNU search + curses)
String Ports (someone has sent me code for this but I haven't had
time to integrate it)
In article <····················@camelot.ai.mit.edu>
······@zurich.ai.mit.edu (Aubrey Jaffer) writes:
>Some things which could be added to SCM are:
> Profiling (how much time spent in each routine)
> Dynamic Linking (There is a GNU package which does this on Unix
> systems and Carrette has also suggested a fairly portable method)
> Editor (buffers + GNU search + curses)
> String Ports (someone has sent me code for this but I haven't had
> time to integrate it)
I vote for weak-cons so that Thomas (DEC's almost-Dylan) can be ported to it.
(BTW, SCM is very nice. Thanks Aubrey!)
Barry Shelton
·····@ute.columbiasc.ncr.com
> ······@zurich.ai.mit.edu (Aubrey Jaffer) writes:
> Some things which could be added to SCM are:
Some other things that might speed its adoption by the rest of us:
* a textbook on software engineering which uses Scheme as a language for its examples
* " " " how to implement Scheme using C (good intro to systems programming)
* " " " operating systems
* " " " computer networks
* " " " graphics
* " " " databases
* " " " physical science
* " " " discrete event simulation
* " " " numerical methods
* " " " computational science (not the same as numerical methods)
My point is that most people who care a lot about language design don't care
(as much) about other aspects of computing. As a result, language designers
spend their time refining languages, instead of showing the rest of us how
useful they are. I don't want to be shown how to write a Scheme interpreter
in Scheme; I want to be shown how to implement Runge-Kutta, or an irregular
oct-tree for making my ray-tracing program go faster, or a traffic flow
simulator, or...
I think that C and Pascal (the only two new languages to have gained a
general following since the 1960s) have succeeded precisely because such
books have been, or become, available. "Give me the child to the age of
seven, and I will give you the man," and all that --- I believe that Scheme
(or ML, or any other language) will not be adopted outside a relatively
narrow segment of academia until (or unless) enough curricular material is
available for it to be the primary language of instruction throughout an
entire undergraduate degree.
Looking forward to the responses,
========================================================================
Gregory V. Wilson || Work as though you lived
Dept. of Computing and Information Science || in the early days
University of Oregon || of a better nation.
·······@cs.uoregon.edu || - Alasdair Gray
========================================================================
I find that the development environment is just as important
as the language itself. I want a windowed browsing/control
environment written in Scheme; there are several free universal
window system libraries that could support a portable environment.
--
Lance Norskog
·······@netcom.com
Data is not information is not knowledge is not wisdom.
·······@netcom.com (Technically Sweet) writes:
>I find that the development environment is just as important
>as the language itself. I want a windowed browsing/control
>environment written in Scheme; there are several free universal
>window system libraries that could support a portable environment.
Hear, hear. I have just begun to look at scheme, and that blank screen,
and knowing I have to somehow generate a whole load of parenthses all in
the right place and order, and if I make a mistake, I get some totally
cryptic error message, without even a hint as to what to do next is
totally daunting. I'm impressed and interested reading Abelson and
Sussman, and frankly scared looking at one of those >. (or that totally
cryptic [Inspect] in PCscheme. I think I could maybe do more in Scheme,
but it sends me running back to C.
In article <············@iskut.ucs.ubc.ca>, ·····@physics.ubc.ca
(William Unruh) writes:
|>Relay-Version: VMS News - V6.0-3 14/03/90 VAX/VMS V5.5; site
|>titan.ksc.nasa.gov
|>Path:
|
titan.ksc.nasa.gov!ames!elroy.jpl.nasa.gov!usc!sdd.hp.com!caen!batcomput
ter!cornell!uw-beaver!cs.ubc.ca!unixg.ubc.ca!unruh
|>Newsgroups: comp.lang.lisp,comp.lang.scheme
|>Subject: Re: SCM Wishlist
|>Message-ID: <············@iskut.ucs.ubc.ca>
|>From: ·····@physics.ubc.ca (William Unruh)
|>Date: Fri, 29 Jan 93 00:22:05 EST
|>References: <······················@cc.umontreal.ca>
|> <····················@camelot.ai.mit.edu>
|> <······················@ncrcae.ColumbiaSC.NCR.COM>
|><······················@cs.uoregon.edu>
|><·····················@netcom.com>
|>Distribution: world
|>Organization: The University of British Columbia
|>Lines: 14
|>Xref: kscp00 comp.lang.lisp:4347 comp.lang.scheme:3670
|>
|>·······@netcom.com (Technically Sweet) writes:
|>
|>>I find that the development environment is just as important
|>>as the language itself. I want a windowed browsing/control
|>>environment written in Scheme; there are several free universal
|>>window system libraries that could support a portable environment.
|>Hear, hear. I have just begun to look at scheme, and that blank
|>screen,
|>and knowing I have to somehow generate a whole load of parenthses all
|>in
|>the right place and order, and if I make a mistake, I get some
|>totally
|>cryptic error message, without even a hint as to what to do next is
|>totally daunting. I'm impressed and interested reading Abelson and
|>Sussman, and frankly scared looking at one of those >. (or that
|>totally
|>cryptic [Inspect] in PCscheme. I think I could maybe do more in
|>Scheme,
|>but it sends me running back to C.
|>
Oh yes! I love when my C program craps out because of a segmentation
violation or unaligned access. Nothing cryptic about that! Did you
learn to use a C-flavor debugger? Why not read your documentation for your
Scheme one as well? I do agree a windowed browser/debugger is nice, but it
seems you are implying that Scheme has LESS of a degugging enviroment than
C.
--
**
David Kuznick
·······@meglos.mdcorp.ksc.nasa.gov
MUTLEY! Do something! - D.D.
From: Jeff Dalton
Subject: Re: SCM Wishlist
Date:
Message-ID: <8313@skye.ed.ac.uk>
In article <·····················@titan.ksc.nasa.gov> ·······@meglos.mdcorp.ksc.nasa.gov (david kuznick) writes:
>|>Hear, hear. I have just begun to look at scheme, and that blank
>|>screen, and knowing I have to somehow generate a whole load of
>|>parenthses all in the right place and order, and if I make a
>|>mistake, I get some totally cryptic error message, without even
>|>a hint as to what to do next is totally daunting. I'm impressed
>|>and interested reading Abelson and Sussman, and frankly scared
>|>looking at one of those >. (or that totally cryptic [Inspect] in
>|>PCscheme. I think I could maybe do more in Scheme,
>|>but it sends me running back to C.
>|>
>Oh yes! I love when my C program craps out because of a segmentation
>violation or unaligned access. Nothing cryptic about that! Did you
>learn to use a C-flavor debugger? Why not read your documentation for your
>Scheme one as well? I do agree a windowed browser/debugger is nice, but it
>seems you are implying that Scheme has LESS of a degugging enviroment than
>C.
Actually, Scheme (and Lisp generally) often does have a worse
debugging environment -- in certain respects -- than C. (I'm
thinking of things like dbxtool; but there are also C interpreters.)
PC Scheme puts you into a debugger (or something) when an error
occurs. Other Lisps tend to be more "modeless" so that you can
(for instance) still type in Lisp expressions in the usual way.
Moreover, Lisp still has the following advantages in most cases:
* It's possible to redefine a single function and retest without
having to relink the whole application and start over from zero.
* There are few limitations on what kinds of data can be printed,
described, inspected, or read.
* The full language is available when writing expressions whose
value is an object to print, inspect, etc. (Compare with
debuggers that understand only a subset.)
* Type information is available at run-time so that you can
see what things are.
* Trace and advise allow you to attach debugging output and other
actions to functions w/o having to start over, change the source,
recompile, or relink.
* Timing and test frameworks can be written in Lisp.
BUT -- this stuff has been around for AGES. Lisp had a HUGE lead
in this area, and in window-based environments. But how big is this
lead now? In some cases, Lisp debugging isn't even a clear win any
more.
-- jd
In article <·····@cup.portal.com> ·····@cup.portal.com (Paul Frederick Snively) writes:
>·······@majestix.cs.uoregon.edu (Gregory Vance Wilson) writes:
>> > ······@zurich.ai.mit.edu (Aubrey Jaffer) writes:
>> > Some things which could be added to SCM are:
>>
>> Some other things that might speed its adoption by the rest of us:
>>
>> * a textbook on software engineering which uses Scheme as a
>> language for its examples
>
>Probably the single best software engineering textbook extant uses
>Scheme as its delivery vehicle: `Structure and Interpretation of
>Computer Programs,` from The MIT Press.
I'm afraid I disagree --- SICP is a wonderful book about how to program, and
think about programs, but it isn't really about managing program development
(which is what I mean by "software engineering"). It's been a while since I
read it, so forgive me if I'm off base, but I don't recall any discussion of
planning program development, managing revision control, developing test
suites and schedules, black box vs. glass box testing, negotiating and
validating interfaces, etc. If there is a book about such things which uses
Scheme as its core language, I'd be very grateful for a pointer to it.
========================================================================
Gregory V. Wilson || Work as though you lived
Dept. of Computing and Information Science || in the early days
University of Oregon || of a better nation.
·······@cs.uoregon.edu || - Alasdair Gray
========================================================================
From: Paul Frederick Snively
Subject: Re: SCM Wishlist
Date:
Message-ID: <74587@cup.portal.com>
> I'm afraid I disagree --- SICP is a wonderful book about how to program, and
> think about programs, but it isn't really about managing program development
> (which is what I mean by "software engineering").
Thanks for the clarification; my definition of "software engineering"
is apparently a proper subset of yours. I also see the need for the type of
book that you mention, but I don't think I personally would find it of
interest.
Any `software engineering management' types out there have any input?
Paul Snively
·····@cup.portal.com
From: Jeff Dalton
Subject: Re: SCM Wishlist
Date:
Message-ID: <8309@skye.ed.ac.uk>
In article <·····················@cs.uoregon.edu> ·······@majestix.cs.uoregon.edu (Gregory Vance Wilson) writes:
>In article <·····@cup.portal.com> ·····@cup.portal.com (Paul Frederick Snively) writes:
>>·······@majestix.cs.uoregon.edu (Gregory Vance Wilson) writes:
>>>
>>> Some other things that might speed its adoption by the rest of us:
>>>
>>> * a textbook on software engineering which uses Scheme as a
>>> language for its examples
>>
>>Probably the single best software engineering textbook extant uses
>>Scheme as its delivery vehicle: `Structure and Interpretation of
>>Computer Programs,` from The MIT Press.
>
>I'm afraid I disagree --- SICP is a wonderful book about how to program, and
>think about programs, but it isn't really about managing program development
>(which is what I mean by "software engineering"). It's been a while since I
>read it, so forgive me if I'm off base, but I don't recall any discussion of
>planning program development, managing revision control, developing test
>suites and schedules, black box vs. glass box testing, negotiating and
>validating interfaces, etc.
This is true. In addition, all the programs in the book are fairly
small. The techniques for managing complexity in large systems are
there, but it's not necessarily clear how to apply them. So,
excellent though this book is, other books are needed.
Or consider Common Lisp. There are several excellent books available,
but do any of them tell you how to organize a large program that
involves a large number of classes and at least several packages?
I haven't found one. There isn't even much information on how to
deal with multiple, interacting packages, let alone combining this
with CLOS.
-- jd
From: Jeff Dalton
Subject: Re: SCM Wishlist
Date:
Message-ID: <8308@skye.ed.ac.uk>
In article <······················@cs.uoregon.edu> ·······@majestix.cs.uoregon.edu (Gregory Vance Wilson) writes:
>My point is that most people who care a lot about language design don't care
>(as much) about other aspects of computing. As a result, language designers
>spend their time refining languages, instead of showing the rest of us how
>useful they are. I don't want to be shown how to write a Scheme interpreter
>in Scheme; I want to be shown how to implement Runge-Kutta, or an irregular
>oct-tree for making my ray-tracing program go faster, or a traffic flow
>simulator, or...
>
>I think that C and Pascal (the only two new languages to have gained a
>general following since the 1960s) have succeeded precisely because such
>books have been, or become, available.
There's a definite need for such books. Algorithm texts (for example)
seldom present algorithms in the way that is best suited for Lisp.
There are even a number of algorithms that are easier to express in
a language with built-in lists processing, but we hardly ever see
them presented that way.
Moreover, I think that one way to see whether a language is important
is to see if there's an edition of Sedgewick's (?sp) Algorithms text
for it :-)
-- jd
In article <······················@ncrcae.ColumbiaSC.NCR.COM>
····@ute.Columbia.NCR.COM () writes:
I vote for weak-cons so that Thomas (DEC's almost-Dylan) can be
ported to it.
so *do* it.
scm is easy to modify. if you want it, then just make it happen.
LISP had its shot at becoming a mainstream language in the mid 1980s,
during the AI boom, and it didn't make it then. It's unlikely to make
it now. Smalltalk occupies the market niche for a dynamic language for
"exploratory programming" at this point in time.
Scheme is nice, but probably isn't going to take over the world.
John Nagle
From: George J. Carrette
Subject: Re: Why Isn't Lisp a Mainstream Language?
Date:
Message-ID: <4744@mitech.com>
In article <······················@netcom.com>, ·····@netcom.com (John Nagle) writes:
> LISP had its shot at becoming a mainstream language in the mid 1980s,
> during the AI boom, and it didn't make it then. It's unlikely to make
> it now. Smalltalk occupies the market niche for a dynamic language for
> "exploratory programming" at this point in time.
>
> Scheme is nice, but probably isn't going to take over the world.
>
> John Nagle
What about GNU EMACS lisp? I bet there are more users of that than
users of Smalltalk. Also there are many commercial packages that
have lisp *hidden* in the core someplace.
In article <············@nz12.rz.uni-karlsruhe.de> Bruno Haible,
······@ma2s2.uucp writes:
>The only remaining run-time burden from Lisp
>(vs. C or Pascal) is garbage collection.
What about run-time type checking?
Tim Larkin
Federal Nutrition Laboratory
Tower Road
Ithaca, New York
····@cornell.edu
607-255-7008
Tim Larkin <····@cornell.edu> writes:
>> The only remaining run-time burden from Lisp
>> (vs. C or Pascal) is garbage collection.
>
> What about run-time type checking?
ISO Lisp implementations may omit type checking from library functions.
(The consequences of type violations are "undefined": error message or
core dump or anything else, depending on the implementation.)
Type checking is enforced when the user writes (ASSURE type form).
And, of course, generic functions have to do type dispatch as in any other
OO language.
Bruno Haible
······@ma2s2.mathematik.uni-karlsruhe.de
From: Jeff Dalton
Subject: Re: Why Isn't Lisp a Mainstream Language?
Date:
Message-ID: <8327@skye.ed.ac.uk>
In article <············@newsstand.cit.cornell.edu> ····@cornell.edu (Tim Larkin) writes:
>In article <············@nz12.rz.uni-karlsruhe.de> Bruno Haible,
>······@ma2s2.uucp writes:
>>The only remaining run-time burden from Lisp
>>(vs. C or Pascal) is garbage collection.
GC isn't necessarily a burden. For instance, there must be cases
where the overheads of explicitly keeping track of storage in C
are greater than the overheads of a good garbage collector. And
using malloc to allocate lists (in a naive way such as one malloc
per cons) is almost certainly more expensive than the Lisp allocator.
I can imagine that allocating a cons could be reduced to one
instruction in Lisp (add 2 to the "next cons" pointer and rely
on a reference to unmapped memory to detect the need for a GC.)
Of course, there are more sophisticated ways of using malloc.
But the problem with Lisp is usually that you have to do more
work than in C in order to be efficient. My point here is that
there are cases where you have to do a lot more work in C, and
even then you may not be quite as fast as Lisp.
>What about run-time type checking?
Lisp implementations have often takes the "unsafe but fast" approach.
For instance, car and cdr might not do any checking. You'd think that
programs would fall apart all the time because of this, but I very
seldom have much trouble with it. Nowadays, some compilers can do
a bit of type inference so that you can have safer code without much
loss in efficiency.
However, there's no doubt that run-time checking is a problem, which
is why Common Lisp has it's somewhat ugly declaration mechanism.
Here's an amusing fact: on VAX 750s (at least -- but that's the only
kind of VAX I checked) it was almost trivial to write Franz Lisp
programs that were faster than equivalent C. The reason was that C
procedure calls used the (slow) "calls" instruction while Franz used
"calls" only for non-local calls. (You could declare functions as
local, and then all calls w/in the file of definition used a faster
mechanism.)) (I've mentioned this before, but it's worth repeating.)
-- jd
In article <··········@news.cso.uiuc.edu> ·······@ehsn11.cen.uiuc.edu (Joshua M Yelon) writes:
The real cost of a GC, though, isn't the time it takes to allocate and
deallocate memory. It's the fact that every other part of the system
must try very hard not to confuse the GC.
<lots of examples deleted>
A conservative garbage collector such as the one in Scheme->C or WCL
does not have most of the problems you describe. In fact, Joel
Bartlett has modified his conservative Scheme->C GC to work with a C++
compiler which has no knowledge about the GC at all. -wade
p.s - For more info about Joel's GC work, send the msg "help" to
···············@decwrl.dec.com
From: Joshua M Yelon
Subject: Re: Why Isn't Lisp a Mainstream Language?
Date:
Message-ID: <C20HHE.HqD@news.cso.uiuc.edu>
····@kobold.stanford.edu (Wade Hennessey) writes:
>A conservative garbage collector such as the one in Scheme->C or WCL
>does not have most of the problems you describe. In fact, Joel
>Bartlett has modified his conservative Scheme->C GC to work with a C++
>compiler which has no knowledge about the GC at all. -wade
This is true, but conservative garbage collectors are (of necessity) all
mark and sweep. That's very slow for large programs.
- Josh
From: Scott Nettles
Subject: Re: Why Isn't Lisp a Mainstream Language?
Date:
Message-ID: <C21EtI.AFx.1@cs.cmu.edu>
In article <··········@news.cso.uiuc.edu> ·······@ehsn11.cen.uiuc.edu (Joshua M Yelon) writes:
>····@kobold.stanford.edu (Wade Hennessey) writes:
>
>>A conservative garbage collector such as the one in Scheme->C or WCL
>>does not have most of the problems you describe. In fact, Joel
>>Bartlett has modified his conservative Scheme->C GC to work with a C++
>>compiler which has no knowledge about the GC at all. -wade
>
>This is true, but conservative garbage collectors are (of necessity) all
>mark and sweep. That's very slow for large programs.
>
Actually Joel's scheme is (mostly) copying. In fact it's called a
mostly-copying collector. Also there is plenty of evidence that
mark-and-sweep isn't "very slow for large programs".
In general many of the comments you've made about problems with GC have
been solved. Not that all (or even most) collectors include the solutions.
Still solutions are known and feasible and given that I don't think one
should call these things problems with GC. Maybe ten years ago, but not now.
Scott
·······@cs.cmu.edu
From: Joshua M Yelon
Subject: Re: Why Isn't Lisp a Mainstream Language?
Date:
Message-ID: <C21ICn.46C@news.cso.uiuc.edu>
Wade:
>>>A conservative garbage collector such as the one in Scheme->C or WCL
>>>does not have most of the problems you describe. In fact, Joel
>>>Bartlett has modified his conservative Scheme->C GC to work with a C++
>>>compiler which has no knowledge about the GC at all.
Josh:
>>This is true, but conservative garbage collectors are (of necessity) all
>>mark and sweep. That's very slow for large programs.
Scott:
>Actually Joel's scheme is (mostly) copying. In fact it's called a
>mostly-copying collector.
Josh:
Now you've got my interest! How does the "mostly-copying" collector work?
And most importantly, does it support generational scavenging?
- Josh
In article <··········@news.cso.uiuc.edu> ·······@ehsn11.cen.uiuc.edu (Joshua M Yelon) writes:
Wade:
>>>A conservative garbage collector such as the one in Scheme->C or WCL
>>>does not have most of the problems you describe. In fact, Joel
>>>Bartlett has modified his conservative Scheme->C GC to work with a C++
>>>compiler which has no knowledge about the GC at all.
Josh:
>>This is true, but conservative garbage collectors are (of necessity) all
>>mark and sweep. That's very slow for large programs.
Scott:
>Actually Joel's scheme is (mostly) copying. In fact it's called a
>mostly-copying collector.
Josh:
Now you've got my interest! How does the "mostly-copying" collector work?
And most importantly, does it support generational scavenging?
- Josh
The mostly copying collector has been modified to be both generational
and incremental. You can get several papers about these collectors by
sending a message with the subject "help" to
···············@decwrl.dec.com. -wade
[ the perennial thread about garbage collection ]:
See ftp.inria.fr:pub/INRIA/icsla/gcp.ps[.Z] for a fully incremental
collector that "marks DURING sweep". It is intended for real-time
applications. That directory has some other interesting papers as
well, and the MEROON object system for Scheme (my development base).
--
Lance Norskog
·······@netcom.com
Data is not information is not knowledge is not wisdom.
In article <··········@news.cso.uiuc.edu> ·······@ehsn11.cen.uiuc.edu (Joshua M Yelon) writes:
The real cost of a GC, though, isn't the time it takes to allocate and
deallocate memory. It's the fact that every other part of the system
must try very hard not to confuse the GC.
Here is a random smattering of the things you typically have to do to
keep the GC unconfused:
* when you allocate an activation record, you must typically
initialize all the local variables, even if the optimizer says
that the user isn't going to read them before he writes them,
so that the GC doesn't find nonsense data and get confused.
* you must typically statically partition the machine registers
into those that contain lisp-objects, and those that contain other
data, so that the GC knows which values to attempt to traverse.
* you must often put tags in your stack activation records, so that
the GC can recognize and understand the format of the stack.
SCM and SIOD have none of the above problems. See code.doc in SCM to
read how this works.
* it is generally impossible to maintain pointers to the middle of
objects, because the GC cannot find the header. For example,
In C, one can scan an array very rapidly by pointing to the
first element, then incrementing the pointer (it doesn't matter
whether the programmer or the optimizer wrote the code that does
this). In most lisps, scanning an array takes more operations.
*foo++ versus foo[i++] is faster on some machines and slower on
others. For the great majority of machines the difference is not
worth worrying about.
In article <··········@news.cso.uiuc.edu> ·······@ehsn11.cen.uiuc.edu (Joshua M Yelon) writes:
····@aiai.ed.ac.uk (Jeff Dalton) replies:
>GC isn't necessarily a burden. For instance, there must be cases
>where the overheads of explicitly keeping track of storage in C
>are greater than the overheads of a good garbage collector. And
>using malloc to allocate lists (in a naive way such as one malloc
>per cons) is almost certainly more expensive than the Lisp allocator.
>I can imagine that allocating a cons could be reduced to one
>(add 2 to the "next cons" pointer and rely
>on a reference to unmapped memory to detect the need for a GC.)
The real cost of a GC, though, isn't the time it takes to allocate and
deallocate memory. It's the fact that every other part of the system
must try very hard not to confuse the GC.
[List of problems with old-fashioned GCs]
Of course, conservative GCs don't have these problems.
-- Harley Davis
--
------------------------------------------------------------------------------
nom: Harley Davis ILOG S.A.
net: ·····@ilog.fr 2 Avenue Gallie'ni, BP 85
tel: (33 1) 46 63 66 66 94253 Gentilly Cedex, France
··@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>If you use mapping functions like map and reduce, and the compiler knows
>enough about the types, it can generate any code it likes for "inner
>loops". Note that for high speed linear algebra, good Fortran programmers
>use the BLAS. No reason why Lisp programmers can't use the BLAS...
In English, please?
--
Lance Norskog
·······@netcom.com
Data is not information is not knowledge is not wisdom.
From: Jeff Dalton
Subject: Re: Why Isn't Lisp a Mainstream Language?
Date:
Message-ID: <8301@skye.ed.ac.uk>
In article <····················@camelot.ai.mit.edu> ······@zurich.ai.mit.edu (Aubrey Jaffer) writes:
>The Hobbit Compiler (by Tanel Tammet) for SCM is in alpha test
>and should be ready soon. However, as SCM runs only 15 times slower
>than hand crafted C code (on most machines) and loads very quickly,
>the lack of the compiler has not hampered my development efforts.
The main speed problem I've had with systems like SCM in the past
is that they repeatedly re-expand macros. Having a trivial "compiler"
that expanded macros and figured out offsets for lexical variables
would usually be good enough for me.
In article <····@skye.ed.ac.uk> ····@aiai.ed.ac.uk (Jeff Dalton) writes:
The main speed problem I've had with systems like SCM in the past
is that they repeatedly re-expand macros.
This is not a problem with SCM. SCM has a procedure
PROCEDURE->MEMOIZING-MACRO:
(procedure->macro <proc>) procedure
(procedure->memoizing-macro <proc>) procedure
Returns a "macro" which, when a symbol defined to this value appears
as the first symbol in an expression, evaluates the result of applying
<proc> to the expression and the environment. The value returned from
<proc> which has been passed to PROCEDURE->MEMOIZING-MACRO must return
a pair; the CAR and CDR of that pair replace the CAR and CDR of the
forms passed to <proc>.
Having a trivial "compiler"
that expanded macros and figured out offsets for lexical variables
would usually be good enough for me.
You are in luck! SCM already does this. In fact, not only does it
memoize offsets for lexical variables, it also memoizes the locations
of global variables. These changes are done to the code the first
time it is evaluated and so constitutes a type of incremental
compilation. This facility has been in SCM for more than a year.
Perhaps you should try a recent version.
·······@ERE.UMontreal.CA (Kardan Kaveh) writes:
> There are several free implementations around, but all are either toy
> implementations or are concerned with being an "extestion language" for
> applications written in C. As a result they have no compilers and no
> development environments.
Actually, Gambit (as of v1.9.2) has what I would consider a production-
quality compiler and a quite reasonable development environment. The only
reason I have not used it for commercial work is that the author does not
allow it (all programs developed with Gambit must be redistributable on the
same terms as Gambit itself, according to the notice that comes with the
package). The same goes for other heavy-duty Scheme systems, such as
Oaklisp (which I would *love* to use in commercial work).
The reason I, at least, don't use Scheme for "real work" is simply that it
isn't available for doing "real work" with. When someone provides a compiler
that can be used for commercial work, or when I end up with enough free time
to write one myself, I will happily use it. Until then, however, I write in
C, despite the fact that Scheme is my language of choice by a quite wide
margin.
Amanda Walker
InterCon Systems Corporation
>>>>> On Mon, 1 Feb 1993 18:36:10 -0500, ······@intercon.com (Amanda Walker) said:
> Actually, Gambit (as of v1.9.2) has what I would consider a production-
> quality compiler and a quite reasonable development environment.
As far as I know, it has not been ported to Sparcs. That is a major
hindrance to me (having a Sun SLC in front of me). I would just love
to compile my programs with one of those lightning-fast Scheme
compilers, but it seems that I am currently out of luck. Even if I did
not care about speed, it is a pain not being able to produce
standalone applications without a shell script and a bunch of source
files.
--
Pertti Kellom\"aki (TeX format) # These opinions are mine,
Tampere Univ. of TeXnology # ALL MINE !
Software Systems Lab # (but go ahead and use them, if you like)
··@cs.tut.fi (Kellom{ki Pertti) writes:
> As far as I know, it has not been ported to Sparcs. That is a major
> hindrance to me (having a Sun SLC in front of me).
Hmm. Yeah, I could see that :). At first glance, it doesn't look like it
would be *too* hard to write a SPARC code generator for it, but I don't have
enough intimate knowledge of the SPARC architecture to give it a try.
Maybe that's the problem--none of us has enough free time :)...
Amanda Walker
InterCon Systems Corporation
>>>>> On 2 Feb 93 11:25:39, ··@cs.tut.fi (Kellom{ki Pertti) said:
pk> I would just love
pk> to compile my programs with one of those lightning-fast Scheme
pk> compilers, but it seems that I am currently out of luck.
As Lance Norskog kindly pointed out to me, Digital's Scheme->C works
on Sparcs. The only problem with that is that the resulting binaries
are a bit large (at least with the version I have used).
Would it be technically feasible to write a tree shaker for C, and
apply it to the C files produced by Scheme->C ? I don't recall scc
doing any sort of tree shaking itself.
--
Pertti Kellom\"aki (TeX format) # These opinions are mine,
Tampere Univ. of TeXnology # ALL MINE !
Software Systems Lab # (but go ahead and use them, if you like)
··@cs.tut.fi (Kellom{ki Pertti) writes:
>Would it be technically feasible to write a tree shaker for C, and
>apply it to the C files produced by Scheme->C ? I don't recall scc
>doing any sort of tree shaking itself.
Unclear what "tree-shaker" means, but there is a partial evaluator
for Scheme called 'Specialix'. It's on diku.dk, I think.
--
Lance Norskog
·······@netcom.com
Data is not information is not knowledge is not wisdom.
In article <··················@chaos.intercon.com> ······@intercon.com (Amanda Walker) writes:
The reason I, at least, don't use Scheme for "real work" is simply
that it isn't available for doing "real work" with. When someone
provides a compiler that can be used for commercial work, or when I
end up with enough free time to write one myself, I will happily
use it. Until then, however, I write in C, despite the fact that
Scheme is my language of choice by a quite wide margin.
The hobbit compiler for SCM (which was just announced in these
Newsgroups), is available for commercial work. The only thing missing
now is a dynamic linker. You do not need to disclose code which is
dynamically linked with SCM. SCM has hooks for defining new types,
macros, and procedures so you should not normally need to modify the
code in the SCM distribution.
SCM runs on practically any system with a C compiler. Many systems
already have dynamic linking ability. There is a GNU package called
dld which can be used with unix systems. So stop waiting and start
porting!
······@zurich.ai.mit.edu (Aubrey Jaffer) writes:
>SCM runs on practically any system with a C compiler. Many systems
>already have dynamic linking ability. There is a GNU package called
>dld which can be used with unix systems. So stop waiting and start
>porting!
DLD runs on bsd-ish systems. There's an equivalent for at&t COFF
systems called CDL. The author (Mauro De Palma) is off the net;
it's freeware and I have a copy for anyone who wants it.
--
Lance Norskog
·······@netcom.com
Data is not information is not knowledge is not wisdom.
·······@netcom.com (Technically Sweet) writes:
>DLD runs on bsd-ish systems. There's an equivalent for at&t COFF
>systems called CDL. The author (Mauro De Palma) is off the net;
>it's freeware and I have a copy for anyone who wants it.
Turns out it is in comp.sources.unix, volume 18.
--
Lance Norskog
·······@netcom.com
Data is not information is not knowledge is not wisdom.
I write:
>Turns out it is in comp.sources.unix, volume 18.
This is all about CDL, a dynamic overlay loader for COFF .o binaries.
I remember now that it has a bug in resolving array references:
static references are set to the beginning of the array instead
of the middle. For example, references to stderr in the .o will
be resolved to stdin.
--
Lance Norskog
·······@netcom.com
Data is not information is not knowledge is not wisdom.
Hello,
I'm looking to find out the state of Software Engineering
education and Lisp education in the world today. If you have a moment
could you please answer the following questions and return them to me
at ····@evb.com
Thanks in advance.
I will post the results of this poll in a month or so when
I'm sure I've gotten all the responses I'm going to get, and have
had time to collate the answers.
(1) How many years experience do you have developing
Lisp based software ? In which Lisp dialects ?
(2) How many years experience do you have teaching Lisp ? In
which dialects ?
(3) How many years experience do you have developing
software ?
(4) How many years experience do you have teaching programming
or related subjects (related meaning either software engineering
or computer science courses that explicitly address _producing_
software systems)
(5) When and where were you first exposed to Lisp ? (please be as
specific as you can, name names and places, ex: I took a junior
level college course in Common Lisp at so-and-so University taught
by Prof. so-and-so in 1987)
(6) How many years of training do you have in developing Lisp
based systems ? In which dialects ?
(7) How many years of training do you have in developing software
systems ?
(8) If you have the time, please give me a few comments about
how you feel about:
Software engineering education:
Lisp education:
Software engineering as a discipline:
Using Lisp in software engineering:
--
Thomas Pole
In article <······················@ads.com> ········@ADS.COM (Bill Vrotney) writes:
(Arun Welch) writes:
> I think an associated question we should be asking is "How can we
> increase Lisp's popularity"? Knowing why it isn't popular is a good
> thing to discuss, but it would also be good to know where to go from
> here. Another question is "Should Lisp be a mainstream language?" I'm
> not sure the answer to that is yes. A lot of neat ideas have risen out
> of Lisp not having been standardised to death early on. CLOS is a case
> in point. If we'd standardised on Interlisp and LOOPS or Zetalisp and
> Flavors I think we'd be a lot poorer today.
Yes "Where to go from here?" I am disappointed that the Lisp leadership is
not addressing this question. This begs for something like the Common Lisp
project but aimed at making Lisp smaller and faster in an organized way. I
was reading about a KERNEL lisp specification in Lisp and Symbolic
Computation. Perhaps something along these lines should be hit with force.
Lisp leadership where are you? Give us something to be hopeful for.
I suggest you look at EuLisp and Dylan as steps in this direction. I
would also like to humbly offer Ilog's Le-Lisp version 16 as another
member of this set of modern Lisps which attempt to address the
deficiencies and excesses of previous Lisps, although I have a certain
commercial stake in it. Also, the emerging ISO Lisp standard is much
smaller than Common Lisp while retaining the most useful features such
as a small, CLOS-like object system.
-- Harley Davis
--
------------------------------------------------------------------------------
nom: Harley Davis ILOG S.A.
net: ·····@ilog.fr 2 Avenue Gallie'ni, BP 85
tel: (33 1) 46 63 66 66 94253 Gentilly Cedex, France
·····@ilog.fr (Harley Davis) writes:
> Also, the emerging ISO Lisp standard is much
> smaller than Common Lisp while retaining the most useful features such
> as a small, CLOS-like object system.
ISO Lisp promises to allow for small executables: it has no EVAL, and
packages are not first class objects. Thus unneeded functions need not be
linked into an executable.
Furthermore the object system has been designed in such a way that type/class
inferences can easily be drawn by a compiler. This will reduce the class
system overhead to nearly zero. And unneeded classes may also be fully
eliminated from an executable. The only remaining run-time burden from Lisp
(vs. C or Pascal) is garbage collection.
The current ISO Lisp draft is publicly available. It can be retrieved by
anonymous FTP, for example from ma2s2.mathematik.uni-karlsruhe.de
[129.13.115.2], file /pub/lisp/islisp/islisp-84.dvi.
Bruno Haible
······@ma2s2.mathematik.uni-karlsruhe.de
In article <············@nz12.rz.uni-karlsruhe.de> ······@ma2s2.uucp (Bruno Haible) writes:
(Harley Davis) writes:
> Also, the emerging ISO Lisp standard is much
> smaller than Common Lisp while retaining the most useful features such
> as a small, CLOS-like object system.
ISO Lisp promises to allow for small executables: it has no EVAL, and
packages are not first class objects. Thus unneeded functions need not be
linked into an executable.
Furthermore the object system has been designed in such a way that
type/class inferences can easily be drawn by a compiler. This will
reduce the class system overhead to nearly zero. And unneeded
classes may also be fully eliminated from an executable. The only
remaining run-time burden from Lisp (vs. C or Pascal) is garbage
collection.
I don't think you should make such extravagant claims without an
existence proof. I have read the ISO Lisp draft and I see nothing in
it which will permit very interesting type inference or the full
elimination of classes from an executable. For example, I see nothing
that can type the expression (CAR FOO) or that can statically compute
the applicable method list for generic function calls when untyped
expressions are passed. (I have also seen this type of wild claim
for Dylan without a corresponding existence proof -- but not by
anybody from Apple.)
ISO Lisp and other modern Lisps should be touted on their real
benefits, and not on some unrealistic dream.
-- Harley Davis
--
------------------------------------------------------------------------------
nom: Harley Davis ILOG S.A.
net: ·····@ilog.fr 2 Avenue Gallie'ni, BP 85
tel: (33 1) 46 63 66 66 94253 Gentilly Cedex, France
From: Jeff Dalton
Subject: Re: Why Isn't Lisp a Mainstream Language?
Date:
Message-ID: <8305@skye.ed.ac.uk>
In article <······················@ads.com> ········@ADS.COM (Bill Vrotney) writes:
>
>In article <···················@sacral.cis.ohio-state.edu>
>·····@sacral.cis.ohio-state.edu (Arun Welch) writes:
>
>> I think an associated question we should be asking is "How can we
>> increase Lisp's popularity"? Knowing why it isn't popular is a good
>> thing to discuss, but it would also be good to know where to go from
>> here. Another question is "Should Lisp be a mainstream language?" I'm
>> not sure the answer to that is yes. A lot of neat ideas have risen out
>> of Lisp not having been standardised to death early on. CLOS is a case
>> in point. If we'd standardised on Interlisp and LOOPS or Zetalisp and
>> Flavors I think we'd be a lot poorer today.
>
>Yes "Where to go from here?" I am disappointed that the Lisp leadership is
>not addressing this question. This begs for something like the Common Lisp
>project but aimed at making Lisp smaller and faster in an organized way. I
>was reading about a KERNEL lisp specification in Lisp and Symbolic
>Computation. Perhaps something along these lines should be hit with force.
>Lisp leadership where are you? Give us something to be hopeful for.
There is a trend these days towards smaller Lisps. EuLisp Level 0,
ISLisp (the dialect being discussed for ISO standardization), and
Dylan are all very similar in size and functionality to Scheme +
a subset of CLOS. So there are people out there already working
in this direction.
Several interesting, more or less free, CL implementations are now
available. The ones I've used are CMU CL, WCL, and [A]KCL. There
are many free Scheme's, of varying characteristics. So reasonably
good implementations of Lisp are widely available.
There are some excellent textbooks (Abelson & Sussman, Norvig).
On the other hand, C has some important advanatges.
1. The technology for building small, efficient applications is
further advanced. (How many Lisp systems do whole-program
optimization at "link" time or provide minimal overhead
calls to leaf procedures?)
2. Object and library files have a fairly standard format. I can,
for instance, compile some things with gcc, some other with Sun's
cc, and use them together.
3. A substantial lead in windowing and graphics applications.
Lisp ought to have a big lead here, but it doesn't. Much of
the time we're just trying to get in Lisp things we already
have in C.
-- jd