In article <··········@pulitzer.eng.sematech.org> ······@swim1.eng.sematech.org (Bill Gooch on SWIM project x7140) writes:
-->
--> I wouldn't choose C or C++ to write anything. I would happily use Lisp
--> for any programming task, other factors being reasonably equivalent.
-->
if you could compile the Lisp equivalent of "Hello world" into roughly
the same number of executable bytes and the C version, Lisp would kick
butt all over.
my experience with Allegro is that the Lisp "Hello world" would be about
2 megabytes for the executable, and take WAY longer to load than to run.
who wants a 2 megabyte device driver? suppose you have to run 10-12 of
them? yikes!
lisp device drivers were only feasible on lisp machines, because all the
"runtime support" was already part of the OS.
suppose all that stuff could exist as a shared library...maybe your
executable COULD be microscopic, and the shared stuff would only be
called when used.
-- clint
hmm. SWIM project, eh? seems ripe for a variety of jokes, like POOL
(Programmer's Object-Oriented Library) and so on...
In article <··········@info-server.bbn.com> chyde writes:
In article <··········@pulitzer.eng.sematech.org> ······@swim1.eng.sematech.org (Bill Gooch on SWIM project x7140) writes:
-->
--> I wouldn't choose C or C++ to write anything. I would happily use Lisp
--> for any programming task, other factors being reasonably equivalent.
-->
if you could compile the Lisp equivalent of "Hello world" into roughly
the same number of executable bytes and the C version, Lisp would kick
butt all over.
my experience with Allegro is that the Lisp "Hello world" would be about
2 megabytes for the executable, and take WAY longer to load than to run.
who wants a 2 megabyte device driver? suppose you have to run 10-12 of
them? yikes!
lisp device drivers were only feasible on lisp machines, because all the
"runtime support" was already part of the OS.
suppose all that stuff could exist as a shared library...maybe your
executable COULD be microscopic, and the shared stuff would only be
called when used.
Ilog Talk is one commercial Lisp which systematically generates shared
libraries from modules. This can reduce executable size to almost
nothing (if you don't save a memory image), but the code is still
lurking about. The big win is that the shared libraries share code
among different processes and dynamic loading is extremely fast.
The basic problem with any Lisp where you want small executables is
somehow leaving behind the basic Lisp runtime, which is probably going
to be bigger than libC since you have the garbage collector and the
basic datatypes. While the Ilog Talk libraries are fairly small, our
philosophy is rather to say that certain programs are simply better
done in other languages, and to have a high-quality, complete, and
automatic FFI so you can use them in Lisp without aggaravation. We
are against the monolithic, one language for everyone idea that seems
to dominate the CommonLisp mind frame. Co-operation is better than
competition.
For more information on Ilog Talk, please write to ····@ilog.com.
-- Harley Davis
--
------------------------------------------------------------------------------
nom: Harley Davis ILOG S.A.
net: ·····@ilog.fr 2 Avenue Galli�ni, BP 85
tel: +33 1 46 63 66 66 94253 Gentilly Cedex, France
* chyde wrote:
> (Bill Gooch on SWIM project x7140) writes:
> if you could compile the Lisp equivalent of "Hello world" into roughly
> the same number of executable bytes and the C version, Lisp would kick
> butt all over.
Just how relevant is the code size of the average 5-line program to
the sort of things people actually write? Sure, if you're writing
programs that are (a) small and (b) such that the run time is likely
dominated by the time to get them off the disk, then you probably
don't want to do that by saving Lisp images.
I do (have done) this sort of thing by having a server lisp around and
a little library which just calls functions in it via RPC see for
instance the `gnudoit' library for an example of this sort of stuff
but for elisp). Shared libraries would be even better of course,
although that's practically what my stuff was.
--tim
···@cogsci.ed.ac.uk (Tim Bradshaw) writes:
Just how relevant is the code size of the average 5-line program to
the sort of things people actually write? Sure, if you're writing
programs that are (a) small and (b) such that the run time is likely
dominated by the time to get them off the disk, then you probably
don't want to do that by saving Lisp images.
It's very relevent. Small programs are very common. Given a high level
language with good libraries, even a small program can do significant
useful work. But people have to write them in C or Perl in leiu of a
suitable lisp or scheme compiler. In either case, parsing the input
each time can be far too slow, hence the desire to generate a (small!)
a.out.
Beyond that, the argument that you pay a fixed 2M overhead, but after
that size grows slowly is specious. That's too big in every case, but
experience with software bloat proves that it doesn't grow slowly. You
have to attack this problem on every level, with no excuses.
The argument here about the size of "Hello, World" is glossing over the issue
of where you draw the line between the application and the operating system.
Back in the days of Interlisp-D on Xerox D-machines, the *entire* system was
written in Lisp, except for 10K or so of microcode; *everything* from
low-level Ethernet drivers and virtual memory paging to the window system...
... and it all fit in 4 Meg of address space! "Hello, World" in that
system was under 100 *bytes*, compiled! It was routine in that system for
compiled code to be smaller than its source, due to byte-compilation.
I would say that C applications running on top of operating systems written
in C have a similar advantage; by and large they're reaching down directly
to hooks made for them to grab onto.
The merits of big, slow and safe Lisp vs. small, fast, and unsafe C can be
argued by hackers; however the marketplace has chosen the C model, and we
have to adapt or be even more marginalized than we are now.
--
Internet: ····@tove.cs.umd.edu
UUCP:...uunet!mimsy!bane
Voice: 301-552-4860
In-reply-to: ····@cs.umd.edu's message of 8 Jun 1994 17:57:58 -0400
>>>>> "JohnBane" == John R Bane <····@cs.umd.edu> writes:
In article <··········@tove.cs.umd.edu> ····@cs.umd.edu (John R. Bane) writes:
JohnBane> The merits of big, slow and safe Lisp vs. small, fast, and
JohnBane> unsafe C can be argued by hackers; however the marketplace
JohnBane> has chosen the C model, and we have to adapt or be even more
JohnBane> marginalized than we are now.
If an implementation has shared libraries and the operating system it
ran on had an loader format with sections (anything as good or better
than COFF), then there executable size would be just like C, would it
not?
What other adaptations? I'm comfortable with the O.S.'s that I use
and don't see any reason to label them `unsafe' just by virtue of the
fact they weren't implemented in LISP.
In article <···················@tdb.ee.pdx.edu> ······@ee.pdx.edu writes:
>
>What other adaptations? I'm comfortable with the O.S.'s that I use
>and don't see any reason to label them `unsafe' just by virtue of the
>fact they weren't implemented in LISP.
>
>
The O.S.'s are pretty safe because they do simple memory management, mostly
at a per-process level. It's the applications that do complex memory
management, and do it without sophisticated automation like generation
scavenging, that are unsafe.
Most Lisp garbage collectors are safe, because the garbage collector is one
of the most heavily exercised parts of the system. Claims of program
proof-of-correctness people aside, programs get debugged when they get a lot
of use. Lisp programmers use storage management systems that have run
correctly for months without dropping a byte; the typical C application does
its own storage management, and often does it poorly because of that lack of
long run-time experience to beat the bugs out.
--
Internet: ····@tove.cs.umd.edu
UUCP:...uunet!mimsy!bane
Voice: 301-552-4860
In article <··········@tove.cs.umd.edu> ····@cs.umd.edu "John R. Bane" writes:
> Most Lisp garbage collectors are safe, because the garbage collector is one
> of the most heavily exercised parts of the system. Claims of program
> proof-of-correctness people aside, programs get debugged when they get a lot
> of use. Lisp programmers use storage management systems that have run
> correctly for months without dropping a byte; the typical C application does
> its own storage management, and often does it poorly because of that lack of
> long run-time experience to beat the bugs out.
Yep. When I wrote my 2nd Lisp in C (the first was in assembly), the
first thing I wrote was the paser, and the 2nd thing was the GC. After
debugging that, I knew I could continue with the rest of the system.
The mistake I made with my 1st Lisp was to leave the GC until last.
Still, it wasn't bad, running in only 64K for code and data.
--
Martin Rodgers, WKBBG, London UK AKA "Cyber Surfer"
Assuming that Clipper will need to be global to be effective, write
to ················@cpsr.org and tell them you oppose Clipper. Now.
This is a shareware .signature -- please pass it on!
In article <··········@info-server.bbn.com> ·····@bbn.com writes:
> if you could compile the Lisp equivalent of "Hello world" into roughly
> the same number of executable bytes and the C version, Lisp would kick
> butt all over.
So what? I get an enormouse image if I use C, compared to using an
assembler. Take the image size argument far enough, and you'll have
a great compiler for "Hello, world" apps (if "app" is the right word),
but it'll be useless for anything else.
> my experience with Allegro is that the Lisp "Hello world" would be about
> 2 megabytes for the executable, and take WAY longer to load than to run.
You could write a "Hello, World" compiler in Allegro that produce an
image smaller than 100 bytes. Try it.
> who wants a 2 megabyte device driver? suppose you have to run 10-12 of
> them? yikes!
Why use C when you could use hex switches?
> lisp device drivers were only feasible on lisp machines, because all the
> "runtime support" was already part of the OS.
Who writes device drivers in C? ISTR a time (only a few years ago) when
everything like that had to be in assembly. Some programmers will never
be happy with anything high level than that. So what? Should we all suffer
just so we can get a device drivers? I've yet to write one, so I'll not
miss using C, C++, or an assember.
> suppose all that stuff could exist as a shared library...maybe your
> executable COULD be microscopic, and the shared stuff would only be
> called when used.
Just write a custom compiler for a custom language that writes device
drivers. If you try hard enough, you can do anything. You don't have to
avoid Lisp simply coz you (or someone) might want to write device drivers.
Most Lisps don't stop you using other languages with it. Maybe platforms
or vendors stop you, but that's someone else's problem as long as you
can chose the right platform or vendor.
That could be why so many programmers choose VC++. It's cheap and it
works with everything else. Plus, they don't know about Lisp.
--
Martin Rodgers, WKBBG, London UK AKA "Cyber Surfer"
Assuming that Clipper will need to be global to be effective, write
to ················@cpsr.org and tell them you oppose Clipper. Now.
This is a shareware .signature -- please pass it on!
············@wildcard.demon.co.uk (Martin Rodgers) writes:
So what? I get an enormouse image if I use C, compared to using an
assembler.
So the cost associated with C is usually reasonable while the
cost associated with lisp is usually not. Details count.
At the risk of being sysetms-programming-centric, here's a test of
viability for a programming language: Rewrite the stuff in /bin in lisp
or scheme. /bin/ls is a good place to start, since it's not very
complicated. Any takers?
In article <·····················@roke.cse.psu.edu>,
Scott Schwartz <········@roke.cse.psu.edu> wrote:
>············@wildcard.demon.co.uk (Martin Rodgers) writes:
> So what? I get an enormouse image if I use C, compared to using an
> assembler.
>
>So the cost associated with C is usually reasonable while the
>cost associated with lisp is usually not. Details count.
>
>At the risk of being sysetms-programming-centric, here's a test of
>viability for a programming language: Rewrite the stuff in /bin in lisp
>or scheme. /bin/ls is a good place to start, since it's not very
>complicated. Any takers?
Given a Scheme-friendly operating system (with a fast Scheme runtime system
analogous to the C libraries in today's unix-style systems), such a task
would not be unreasonable, especially if the same amount of time is allowed
to develop the programs that C-centric systems have had. I would certainly
be willing to write a few of the programs in /bin if enough other people
would contribute and make it worth while. I don't see any reason that a
package similar to the GNU utilities used by the free unices couldn't be
developed.
There is nothing inherently inefficient about Scheme programs; in fact I
would argue that the largest obstacles to Scheme compilers being commonplace
are that the language allows incremental loading of code via EVAL and would
require an incremental compiler/linker, and Scheme programs can have a level
of non-determinism not present in C (via CALL/CC). I have high hopes that
C/C++ will continue in the direction of runtime support though, allowing
fast Scheme systems to, perhaps, one day be commonplace. As much as I'd like
it, nobody wants to write new libraries for every hardware platform that
would provide portability via a lisp instead of C.
Having hacked around an X Windows display driver in C and assembler with
Linux, I personally would like to try my hand at writing device drivers in
Scheme!
My comments are tilted towards Scheme rather than lisps in gerneral simply
because I have had more experience with Scheme in particular.
karl c.
---
Karl Czajkowski
······@uclink.berkeley.edu
In article <··········@agate.berkeley.edu>, Karl Frederick Czajkowski writes:
> Given a Scheme-friendly operating system (with a fast Scheme runtime system
> analogous to the C libraries in today's unix-style systems), such a task
> would not be unreasonable, especially if the same amount of time is allowed
> to develop the programs that C-centric systems have had. I would certainly
> be willing to write a few of the programs in /bin if enough other people
> would contribute and make it worth while. I don't see any reason that a
> package similar to the GNU utilities used by the free unices couldn't be
> developed.
Here's an idea: We've got all these "project" operating systems now (like a
couple of microkernels, Linux, etc. -- I mean OSes that were written not for
some altruistic goals like GNU's but for fun); why not write a new Lisp-OS or
Scheme-OS. Something that would run as close to the hardware as possible and
grow up from there. I had an idea once to try something like this on top of
Mach, but I don't have the necessary skill. Some of you might, though, and
maybe I can pique your interest...
TTFN,
Chris
In article <·················@mtlookitthat.chi.il.us>, Chris Hanson <·······@mtlookitthat.chi.il.us> writes:
|>
|> Here's an idea: We've got all these "project" operating systems now (like a
|> couple of microkernels, Linux, etc. -- I mean OSes that were written not for
|> some altruistic goals like GNU's but for fun); why not write a new Lisp-OS or
|> Scheme-OS. Something that would run as close to the hardware as possible and
|> grow up from there. I had an idea once to try something like this on top of
|> Mach, but I don't have the necessary skill. Some of you might, though, and
|> maybe I can pique your interest...
|>
|> TTFN,
|> Chris
There was a discussion about doing this for PC platforms a year or so ago. My
question is, do you really want to duplicate all the effort that the Linux and
NetBSD groups have put into an OS? Look at the number of different disk drivers,
video drivers, network drivers, ... that these people have to support. That alone
is no small task! On top of that, you'll need a windowing system, probably X,
that'll need to be written in lisp along with all the assorted utilities like ls,
more, emacs, ... Oh, ya. Don't forget to write the lisp too. It'll need to
support multiple processes (threads), access to hardware, ... It wouldn't hurt if
it was fast too.
I would think a better approach might be to build a lisp that was tightly
integrated to one of the free Unixes. That way you can keep the X server, the
device drivers, etc that have all ready been written. You'll still want to add
processes to lisp. It probably still be nice if emacs ran inside lisp. If you
could come up with a gnuemacs elisp compatibility module then you could use all
of the existing elisp code instead of writing it from scratch.
I guess another approach would be to model the underlying architecture of a
Lisp Machine and then pilfer (i.e. STEAL) the Symbolics code. With their current
financial problems, I'd guess they'd love to find someone they could sue for
really big bucks.
Mike McDonald Advanced Technology Dept.
Harris Corp.
Email: ···@trantor.harris-atd.com M.S. 16-1912
Voice: (407) 727-5060 P.O. Box 37
Fax: (407) 729-3363 Melbourne, Florida 32902
Mike McDonald (···@trantor.harris-atd.com) wrote:
: I would think a better approach might be to build a lisp that was
: tightly integrated to one of the free Unixes. That way you can keep
: the X server, the device drivers, etc that have all ready been
: written. You'll still want to add processes to lisp.
I read an interesting paper about interfacing garbage collection and
memory management once. Someone (sorry, forget the name) developed an
extremely efficient incremental copying GC that used memory protection
to detect access to non-copied pages. If you integrate the Scheme
system into the os, there are lots of interesting applications for
memory management.
I would have liked to implement that using Linux. But then, I have
no intention of learning intel assembler (yieks).
What would be the difference between a Scheme OS and e.g. Linux? Aside
from memory management support, is there anything we can't do with a
shared library?
--axe
-----------------------------------------------------------------------------
I lost my mind. Please mail me ·······@rzdspc2.informatik.uni-hamburg.de
if you should find it somewhere. * Axel Wienberg
From: Kelly Murray
Subject: New Lisp Machine (was Re: Writing a small Lisp)
Date:
Message-ID: <2ti77m$dtt@sand.cis.ufl.edu>
In article <··········@jabba.ess.harris.com>, ···@trantor.harris-atd.com (Mike McDonald) writes:
|> In article <·················@mtlookitthat.chi.il.us>, Chris Hanson <·······@mtlookitthat.chi.il.us> writes:
|> |>
|>
|> |> Here's an idea: We've got all these "project" operating systems now (like a
|> |> couple of microkernels, Linux, etc. -- I mean OSes that were written not for
|> |> some altruistic goals like GNU's but for fun); why not write a new Lisp-OS or
|> |> Scheme-OS. Something that would run as close to the hardware as possible and
|> |> grow up from there. I had an idea once to try something like this on top of
|> |> Mach, but I don't have the necessary skill. Some of you might, though, and
|> |> maybe I can pique your interest...
|> |> TTFN,
|> |> Chris
|>
|> There was a discussion about doing this for PC platforms a year or so ago. My
|> question is, do you really want to duplicate all the effort that the Linux and
|> NetBSD groups have put into an OS?
|> [...]
|> I would think a better approach might be to build a lisp that was tightly
|> integrated to one of the free Unixes. That way you can keep the X server, the
|> device drivers, etc that have all ready been written. You'll still want to add
|> processes to lisp. It probably still be nice if emacs ran inside lisp. If you
|> could come up with a gnuemacs elisp compatibility module then you could use all
|> of the existing elisp code instead of writing it from scratch.
|>
|> I guess another approach would be to model the underlying architecture of a
|> Lisp Machine and then pilfer (i.e. STEAL) the Symbolics code. With their current
|> financial problems, I'd guess they'd love to find someone they could sue for
|> really big bucks.
|> Mike McDonald Advanced Technology Dept.
Yes, I proposed this quite a while ago, and I do have the necessary skill
since I've just about done it already. There just wasn't enough interest
by others to help with all the work it would take to make it useable.
But most importantly it seemed like very few people would use it anyway.
As a research project by a professor where it
could serve as a vehicle for real-world engineering and teaching for
their students, it would be a great idea.
I'm no professor, but just a hacker trying to make a living.
Getting a fast CL to run tightly integrated w/Linux or FreeBSD would be easier
and even better, but it would still be a lot of work.
And still few people would use it. Because it would have to offer
a major, significant improvement in some capability.
Not just better, two orders of magnitude better.
People are slow to adopt UNIX over DOS, and surely UNIX is that much better
in a technical sense.
What could a LISP system do that much better?
- Kelly Murray (···@prl.ufl.edu) <a href="http://www.prl.ufl.edu">
-University of Florida Parallel Research Lab </a> 96-node KSR1, 64-node nCUBE
From: Fernando Mato Mira
Subject: Re: New Lisp Machine (was Re: Writing a small Lisp)
Date:
Message-ID: <2tiibf$5ek@disuns2.epfl.ch>
In article <··········@sand.cis.ufl.edu>, ···@prl.ufl.edu (Kelly Murray) writes:
> What could a LISP system do that much better?
What's wrong with all new OSes?
They eat up TONS of memory.
An object-oriented system in any language might be less of a memory hog
(if it is "OO" in C++ they still lose with templates).
Garbage collection for everything means no memory leaks at all.
If a copying garbage collector is used, fragmentation is reduced,
and locality of reference could be improved.
A compact MOP-based language as the basis for implementation might
achieve yet-to-be-discovered advantages (simplicity ?, optimizable
generality ?, even more code reuse and memory savings ?).
IRIX 5.2 - 20+ Mb and counting (up, usually).
--
F.D. Mato Mira
Computer Graphics Lab ········@epfl.ch
EPFL FAX: +41 (21) 693-5328
In article <·········@disuns2.epfl.ch> ········@di.epfl.ch (Fernando Mato Mira) writes:
Regarding GC, a really cool thing would be a reflective
garbage collector, so that different data structures
of a program (user or system-level) can be collected in
different ways (no collection of certain GC data structures,
"real-time" GC for time-critical program sections, copying
GC in other, etc.).
If you expand this to general memory management, there are even more
possibilities, such as cooperating with persistent backup. It all has
to be done, so better to put it in a coherent framework.
This alone is an interesting subject for a Ph.D. thesis.
Somebody else's. I'm too close to finishing mine to change subject.
Matthew Fuchs
·····@cs.nyu.ed
In article <·················@mtlookitthat.chi.il.us>
·······@mtlookitthat.chi.il.us "Chris Hanson" writes:
> Here's an idea: We've got all these "project" operating systems now (like a
> couple of microkernels, Linux, etc. -- I mean OSes that were written not for
> some altruistic goals like GNU's but for fun); why not write a new Lisp-OS or
> Scheme-OS. Something that would run as close to the hardware as possible and
> grow up from there. I had an idea once to try something like this on top of
> Mach, but I don't have the necessary skill. Some of you might, though, and
> maybe I can pique your interest...
I'd certainly love to use a system like that!
--
Martin Rodgers, WKBBG, London UK AKA "Cyber Surfer"
Assuming that Clipper will need to be global to be effective, write
to ················@cpsr.org and tell them you oppose Clipper. Now.
This is a shareware .signature -- please pass it on!
In article <··········@agate.berkeley.edu>
······@uclink.berkeley.edu "Karl Frederick Czajkowski" writes:
> Given a Scheme-friendly operating system (with a fast Scheme runtime system
> analogous to the C libraries in today's unix-style systems), such a task
> would not be unreasonable, especially if the same amount of time is allowed
> to develop the programs that C-centric systems have had. I would certainly
> be willing to write a few of the programs in /bin if enough other people
> would contribute and make it worth while. I don't see any reason that a
> package similar to the GNU utilities used by the free unices couldn't be
> developed.
Would anyone like to try it for MS Windows? It's a perfect platform,
as long as you use the Win32 version. You can even use the Hamilton
C-Shell. :-) Well, I'm still using Win16, but I'll upgrade when I can.
Meanwhile, I'm still looking for a serious Lisp substitute for C, and
wondering if I'll have to write it myself. As I have a Scheme interprester
already, what I'll need will be a compiler that creates the code for a
small image, perhaps by compiling into assembly language and linking
with runtime code written in C.
> My comments are tilted towards Scheme rather than lisps in gerneral simply
> because I have had more experience with Scheme in particular.
I'd choose Scheme simply coz it's small and unambitious. It took me
6 months to write a subset of CL no larger than XLISP, tho it was a
very _different_ subset. I'm no expert on writer compilers, esp for
Lisp, but if it could give me stand-alone code, it _could_ be worth
a try, even if the quality of the code is poor.
--
Martin Rodgers, WKBBG, London UK AKA "Cyber Surfer"
Assuming that Clipper will need to be global to be effective, write
to ················@cpsr.org and tell them you oppose Clipper. Now.
This is a shareware .signature -- please pass it on!
Scott Schwartz <········@roke.cse.psu.edu> wrote:
> At the risk of being sysetms-programming-centric, here's a test of
> viability for a programming language: Rewrite the stuff in /bin in lisp
> or scheme. /bin/ls is a good place to start, since it's not very
> complicated. Any takers?
No problem. Here is a BSD-style /bin/ls for Elk 2.2. There are a few
limitations with respect to the real /bin/ls. All of these are minor
and could be removed easily; I just didn't have the time to write an
*exact* clone of /bin/ls.
o There are no options; it always uses -l (long listing).
o The sticky bit isn't recognized (this is trivial to implement).
o The year isn't shown in the modification time if the file hasn't
been modified during the last year.
o The listing isn't sorted. I don't have an efficient sort function
for Elk.
o Error handling isn't optimal.
o You can only list the current directory.
o The `total' header displayed by /bin/ls -l is missing.
o It assumes that symbolic links are supported (easy to fix).
It has been tested under SunOS 4.1.3, SunOS 5.3, Ultrix 4.2, SGI Irix
5.1 and HP-UX 9.0 and should work on all platforms where Elk 2.2 is
available. The code is somewhat slow, but that's because Elk isn't
one of the fastest Scheme implementations around (it has been designed
primarily as an extension language to be linked into applications
rather than as a fast standalone implementation of Scheme).
To use the code, just load ls.scm into Elk 2.2, either interactively
from within the top level or by supplying the file in the command line:
% scheme -l ls.scm
[Autoloading unix.scm]
[Autoloading record.scm]
[Autoloading record.o]
[Autoloading recordutil.scm]
[Autoloading unix.o]
-rw-r--r-- 1 net 48059 Apr 21 17:44 patch-dec-alpha
-rw-r--r-- 1 net 6126 Feb 8 12:52 MIGRATE
-rw-r--r-- 1 net 14828 Feb 6 18:45 MACHINES
-rw-r--r-- 1 net 7656 Feb 6 18:03 INSTALL
-rw-r--r-- 1 net 1564 Apr 13 15:20 COPYRIGHT
-rw-r--r-- 1 net 5110 Feb 6 18:26 README
-rw-r--r-- 1 net 809146 Feb 8 14:23 elk-2.2.tar.gz
-rw-r--r-- 1 net 16784 Feb 8 10:45 CHANGES
-rw-r--r-- 1 net 5698 Apr 11 10:11 ANNOUNCE
-rw-r--r-- 1 net 2707 Mar 17 11:50 RELEASE
drwxr-sr-x 3 net 512 Jan 26 15:50 misc
lrwxrwxrwx 1 root 512 Feb 8 13:50 util -> ../../util
drwxr-sr-x 5 net 1024 Mar 20 18:16 config
drwxr-xr-x 4 net 512 Mar 20 18:18 scripts
drwxr-xr-x 7 net 512 Feb 6 17:42 contrib
drwxr-xr-x 8 net 512 Jan 18 14:56 examples
drwxr-xr-x 3 net 2048 Apr 21 16:16 src
drwxr-xr-x 3 net 512 Mar 20 18:18 include
drwxr-xr-x 3 net 1024 Mar 20 18:21 scm
drwxr-xr-x 8 net 512 Oct 18 10:20 lib
drwxr-xr-x 14 net 512 Feb 8 13:19 doc
%
Here is the code:
-----------------------------------------------------------------------------
(require 'unix)
;; Map file type to letter
(define type-char-map
'((regular . #\-) (directory . #\d) (symlink . #\l) (socket . #\=)
(fifo . #\p) (character-special . #\c) (block-special . #\b)
(unknown . #\?)))
;; Map file mode to /bin/ls-style mode string without/with taking
;; setuid/setgid bit into account
(define perm-tab '#("---" "--x" "-w-" "-wx" "r--" "r-x" "rw-" "rwx"))
(define perm-tab1 '#("--S" "--s" "-wS" "-ws" "r-S" "r-s" "rwS" "rws"))
;; Right justify string within field of `n' spaces
(define (rjust str n)
(let* ((y (string-append (make-string n #\space) str))
(l (string-length y)))
(substring y (- l n) l)))
;; Left justify string within field of `n' spaces
(define (ljust str n)
(let* ((y (string-append str (make-string n #\space)))
(l (string-length y)))
(substring y 0 n)))
(define (print-type type)
(display (cdr (assq type type-char-map))))
(define (print-perm perm setid?)
(let ((bits (vector-ref (if setid? perm-tab1 perm-tab) perm)))
(display bits)))
;; This could probably be made more efficient by using Elk's bitstring
;; extension
(define (print-mode mode)
(let ((owner 0) (group 0) (world (modulo mode 8)))
(set! mode (quotient mode 8)) (set! group (modulo mode 8))
(set! mode (quotient mode 8)) (set! owner (modulo mode 8))
(set! mode (quotient mode 8))
(print-perm owner (>= mode 4))
(print-perm group (odd? (quotient mode 2)))
(print-perm world #f)))
(define (print-nlink nlink)
(display (rjust (number->string nlink) 3))
(display #\space))
(define (print-owner uid)
(display (ljust (passwd-name (unix-get-passwd uid)) 8)))
(define (print-size size)
(display (rjust (number->string size) 9)))
(define (print-mtime mtime)
(display (substring (unix-time->string mtime) 3 16))
(display #\space))
(define (print-name name)
(display name))
(define (print-link name)
(display " -> ")
(display (unix-readlink name)))
(define (list-entry name)
(if (not (char=? (string-ref name 0) #\.))
(let ((s (unix-lstat name)))
(print-type (stat-type s))
(print-mode (stat-mode s))
(print-nlink (stat-nlink s))
(print-owner (stat-uid s))
(print-size (stat-size s))
(print-mtime (stat-mtime s))
(print-name name)
(if (eq? (stat-type s) 'symlink)
(print-link name))
(newline))))
(define (ls)
(for-each list-entry (unix-read-directory ".")))
(ls)
···@cs.tu-berlin.de (Oliver Laumann) writes:
The code is somewhat slow, but that's because Elk isn't
one of the fastest Scheme implementations around
But that was one of my complaints! The ones that are small are too slow
to really replace the stuff in /bin, and the ones that are fast are too
large. Sigh.
That said, as an extension language, I think Elk is very nice.
In article <·····················@roke.cse.psu.edu> ········@roke.cse.psu.edu (Scott Schwartz) writes:
From: ········@roke.cse.psu.edu (Scott Schwartz)
Date: 08 Jun 1994 22:42:28 GMT
/bin/ls is a good place to start, since it's not very complicated.
Surely you jest! When I first started playing with Unix (1983) one of
the first comments that was made to about learning Unix was that it
was mentally twisted. The example offered was `Just look at how
screwy ls is'
Anyway, I don't think that it works as an example unless you are
allowing it to be in portable Common Lisp, i. e. it only needs to
support information that the CL language provides in the file system
interface. Otherwise, yes, you're exposing a system bias. ls would
be a lot easier to write in lisp on an Explorer than on a Sun.
I'll propose another example. Write sort(1) in CL :-)
--
Rick Busdiecker <···@lehman.com> Please do not send electronic junk mail!
Lehman Brothers
388 Greenwich Street "One never notices what has been done; one can only
New York, NY 10013 see what remains to be done." -- Marie Curie
In article <·····················@roke.cse.psu.edu>
········@roke.cse.psu.edu "Scott Schwartz" writes:
> ············@wildcard.demon.co.uk (Martin Rodgers) writes:
> So what? I get an enormouse image if I use C, compared to using an
> assembler.
>
> So the cost associated with C is usually reasonable while the
> cost associated with lisp is usually not. Details count.
No. What I meant was that C programmers (usually) don't think that
the "overhead" is significant. There's a minority of C programmers
who would disagree, and resort to using assembly for such a trivial
program. I'd be tempted too, if I had to write a lot of programs like
that, but fortunately, real apps require a lot more code than you need
to just display a finite sequence of characters.
> At the risk of being sysetms-programming-centric, here's a test of
> viability for a programming language: Rewrite the stuff in /bin in lisp
> or scheme. /bin/ls is a good place to start, since it's not very
> complicated. Any takers?
I don't use Unix (yet). It's a good idea, tho. I'd start by writing
a Scheme compiler that generates assembly code (so I can examine it).
I'm tempted to try that for DOS, and then maybe Windows, but I keep
finding time for other projects.
Writing compilers doesn't have the same appeal that it once had,
perhaps because I can now choose to use languages other than C or
assembly. I don't need to write my own Forth, tho I once did, and
after porting it to DOS, I can still use it. I don't need to write
my own Lisp, tho I once did, and I can still use that, too.
So I have Lisp already, but not in a form that I'd like, as I can't
produce a stand alone image. It's time I wrote that compiler...
--
Martin Rodgers, WKBBG, London UK AKA "Cyber Surfer"
Assuming that Clipper will need to be global to be effective, write
to ················@cpsr.org and tell them you oppose Clipper. Now.
This is a shareware .signature -- please pass it on!
In-reply-to: chyde's message of 7 Jun 1994 16:16:24 GMT
In article <··········@info-server.bbn.com> chyde writes:
chyde> my experience with Allegro is that the Lisp "Hello world" would
chyde> be about 2 megabytes for the executable, and take WAY longer to
chyde> load than to run.
Things aren't *that* bad.
A few other data points from freely available packages.
Byte compiler:
CLISP: 1 meg image, 700K executable.
Makes small, fast-loading (but not native code) compiled modules.
Implemented in C, with some inline assembly.
Embedded LISPs with C backends:
CLICC: 240K standalone executable for `Hello World'.
Plain compile-link. I made no attempt to
inventory the functions, combine source files for inlining, etc..
Caveat: CLICC is a subset of Common LISP which prevents you from
using reflection (eval). CLICC intended to be used with a normal
LISP implementation.
ECL: 700K system library (with code from KCL).
chyde> lisp device drivers were only feasible on lisp machines,
chyde> because all the "runtime support" was already part of the OS.
In article <·················@netcom.com>
·······@netcom.com "james brister" writes:
brister>I'd no sooner choose
brister>C++ to write a symbolic math package than I'd use LISP to write a
brister>network transport package.
The opposite would be more useful, though. That is, a C++ library
implementation of Pari, and a software like ILU for LISP.
LISP isn't necessarily wrong for systems programming. For instance,
using a Mach and LISP process as custom memory manager could be
slick, efficient way to implement and manage an OODB.
chyde> suppose all that stuff could exist as a shared library...maybe
chyde> your executable COULD be microscopic, and the shared stuff
chyde> would only be called when used.
(Linux has tools for making this process less painful. )
Weren't the MIT scheme people working on a shared library for Scheme48?
Marcus Daniels (······@ee.pdx.edu) wrote:
: [...]
: CLISP: 1 meg image, 700K executable.
: Makes small, fast-loading (but not native code) compiled modules.
: Implemented in C, with some inline assembly.
Writing a lisp interpreter is a nice example of a high-speed
application. If we can do that in Lisp, then C would really be
superfluous. Have you ever wondered why it is implemented in C?
Some ideas:
In order to implement the memory management required by Lisp (or
Scheme or any other dynamic language), you need pointer
arithmetics. But memory management doesn't make much sense if the user
program is allowed to shoot your management information. Ergo, Lisp
should not include pointer arithmetics. Ergo, Lisp is not the right
language for implementing memory management. Ergo, Lisp is not the right
language for implementing Lisp.
Some people might argue that we need pointers in Lisp so it can do
everything C can. I say: Leave this unpleasant area to C programs!
May it damage their reputation :-) In Lisp, we have memory management
already, so we don't have to simulate it. Ergo: no pointer arithmetics
please.
Another thing: I believe Lisp programs run inherently slower because
Lisp makes it so easy to ignore hardware issues (e.g. word size ints
vs. bignums). But since I usually *want* to ignore hardware issues, I
have no problem with sacrificing these few percent of speed.
So: Lisp can't do everything C can, and it is not as fast as C is,
and that's okay with me whenever I don't want to pay the price I have
to pay in C. (it's just the same with C and Assembler, btw.)
Hope this wasn't too off-topic.
--axe
-----------------------------------------------------------------------------
I lost my mind. Please mail me ·······@rzdspc2.informatik.uni-hamburg.de
if you should find it somewhere. * Axel Wienberg
In article <··········@rzsun02.rrz.uni-hamburg.de>
·······@rzdspc19.informatik.uni-hamburg.de "Axel Wienberg" writes:
> Another thing: I believe Lisp programs run inherently slower because
> Lisp makes it so easy to ignore hardware issues (e.g. word size ints
> vs. bignums). But since I usually *want* to ignore hardware issues, I
> have no problem with sacrificing these few percent of speed.
Exactly! How much time do we lose just to get a few percent less runtime?
Life is too short, and anyway, if time is money...
> So: Lisp can't do everything C can, and it is not as fast as C is,
> and that's okay with me whenever I don't want to pay the price I have
> to pay in C. (it's just the same with C and Assembler, btw.)
I think of it like this:
I remember a time when Forth programmers would do their number crunching
with fixed point, and claim it was faster. I still have some SIN and COS
code in Forth. It's very elegant, but I've never used it. I would never
have written it myself. Many Forth systems now provide floating point,
and it gets used.
Think of coding in C/C++ like using fixed point, and using Lisp, Dylan,
Smalltalk, Modular-3, etc like using floating point. How many C hackers
insist on using fixed point? Like Forth programmers, I bet they now use
floating point. We're winning, but slowly.
--
Martin Rodgers, WKBBG, London UK AKA "Cyber Surfer"
Assuming that Clipper will need to be global to be effective, write
to ················@cpsr.org and tell them you oppose Clipper. Now.
This is a shareware .signature -- please pass it on!
In-reply-to: ············@wildcard.demon.co.uk's message of Thu, 9 Jun 1994 18:16:06 +0000
>>>>> "cyber" == Martin Rodgers <············@wildcard.demon.co.uk> writes:
In article <············@wildcard.demon.co.uk> ············@wildcard.demon.co.uk (Martin Rodgers) writes:
cyber> Think of coding in C/C++ like using fixed point, and using
cyber> Lisp, Dylan, Smalltalk, Modular-3, etc like using floating
cyber> point. How many C hackers insist on using fixed point? Like
cyber> Forth programmers, I bet they now use floating point. We're
cyber> winning, but slowly.
With C, arbitrary precision integer arithmetic is a hassle, that's why
floating point is so common.
I like exact arithmetic in any language, but at least with LISP you
can easily examine the speed/accuracy tradeoffs of number
representation for a particular platform/implementation.
I say no bignums, no rationals, no options, no deal.
Obligatory anecdote:
Ever had the misfortune of using one of today's small database/4GL packages?
I once worked at a telephone data processing company where
they joyfully relied on a 4GL's floating point.
I'd periodically run across their little ad-hoc rounding workarounds here
and there (with corrective if-thens!) in matching rules, report
generation, all over. But who was I to complain, just a lowly
college student. I set them up with a revision control system, I figured
it would be good to document all their accomplishments.
When they *really* needed speed for their gigabytes
of data they used compiled VAX Basic. This, of course, was their
`upgrade' from the old COBOL system.
Questions (anyone suggest papers?)
- Have top down software metrics/engineering people ever studied Common LISP
environments (especially regarding its supposed overly large size)
What did they conclude vs. C++, Smalltalk, etc.?
Did the researchers do a realistic job of capturing the evolution of
programming expertise?
- Is wide variance in programming competence for a particular language a
bad thing (especially if that language brings out especially high
productivity in some individuals)?
- Why does it (not) say more to employers to have and C++/CLOS experience vs
C++/Smalltalk experience? How about C++/Scheme vs C++/Smalltalk?
Merely express obedience to the latest language fashion, and your o.k.,
is that it?
- Why does the Earth spin around every 24 hours? Near as I can tell, it
seems to be the pretty much the same all the time.
From: Martin Rodgers
Subject: Re: What's wrong a big language? Was: Writing a small Lisp
Date:
Message-ID: <771343083snz@wildcard.demon.co.uk>
In article <····················@tdb.ee.pdx.edu>
······@ee.pdx.edu "Marcus Daniels" writes:
> cyber> Think of coding in C/C++ like using fixed point, and using
> cyber> Lisp, Dylan, Smalltalk, Modular-3, etc like using floating
> cyber> point. How many C hackers insist on using fixed point? Like
> cyber> Forth programmers, I bet they now use floating point. We're
> cyber> winning, but slowly.
>
> With C, arbitrary precision integer arithmetic is a hassle, that's why
> floating point is so common.
That's never stopped Forth programmers from using fixed point. It's just
that these days, with hardware FP, it hardly seems worth it.
> I like exact arithmetic in any language, but at least with LISP you
> can easily examine the speed/accuracy tradeoffs of number
> representation for a particular platform/implementation.
Do you mean no floating point? There's no standard library for doing
infinite precision arithmetic in C.
> I say no bignums, no rationals, no options, no deal.
Could I use that as as reason for not using C? Sadly, no.
> - Why does it (not) say more to employers to have and C++/CLOS experience vs
> C++/Smalltalk experience? How about C++/Scheme vs C++/Smalltalk?
> Merely express obedience to the latest language fashion, and your o.k.,
> is that it?
Fashion seems to dictate a lot. Most C++ programmers I know of use
VC++, mainly coz it is what Microsoft support. Microsoft don't do
a Smalltalk or a Lisp.
They do a Basic, tho. That's got very strong support. You can read
about it in comp.lang.visual...
--
Martin Rodgers, WKBBG, London UK AKA "Cyber Surfer"
Assuming that Clipper will need to be global to be effective, write
to ················@cpsr.org and tell them you oppose Clipper. Now.
This is a shareware .signature -- please pass it on!
From: Martin Rodgers
Subject: Re: What's wrong a big language? Was: Writing a small Lisp
Date:
Message-ID: <771855233snz@wildcard.demon.co.uk>
In article <······················@cc.ic.ac.uk>
······@ic.ac.uk "Dr S.J. Zara" writes:
> Just started reading this news group, and I have found the languages debate
> very interesting. I *had* to comment when I saw the word 'Microsoft'-
> I purchased their C++, just to take a look at it - it is apalling....
> Firstly, it requires 6 MB of memory to run sensibly, takes *ages* to
> compile *anything*, abd the class library is very obscure.
I agree about the compile time being too slow, but I've read that the
memory needed is more like 12 MB. The people using VC++ claim Smalltalk
and Lisp is too big ans slow, but they don't name the vendor, which
is critical.
One person even refered to a VC++ compile as taking only seconds. How
many seconds, I wonder? :-)
> As for Visual Basic - its a disaster for serious application development-
> Microsoft seem to have forgotten to include object-orientation in the
> language.
They have a limited view of OOP. It doesn't include class or inheritance.
You have to create VBX objects (widgets), or use OLE (smart files). Is
there a Lisp for MS Windows that supports these API sets?
> Stick with lisp is my advice... *anything* but C++
I wish that were possible.
--
Martin Rodgers, WKBBG, London UK AKA "Cyber Surfer"
Assuming that Clipper will need to be global to be effective, write
to ················@cpsr.org and tell them you oppose Clipper. Now.
This is a shareware .signature -- please pass it on!
In article <············@wildcard.demon.co.uk> ············@wildcard.demon.co.uk (Martin Rodgers) writes:
>[Visual Basic has] a limited view of OOP. It doesn't include class or
> inheritance. You have to create VBX objects (widgets), or use OLE (smart
>files). Is there a Lisp for MS Windows that supports these API sets?
Franz's CL for Windows has an easy to use FFI. No support for OLE directly (in
release 1.0).
···············@ccm.jf.intel.com
(503) 696-9309
Intel / ProShare Conferencing
In article <··········@rzsun02.rrz.uni-hamburg.de> ·······@rzdspc19.informatik.uni-hamburg.de (Axel Wienberg) writes:
In order to implement the memory management required by Lisp (or
Scheme or any other dynamic language), you need pointer
arithmetics. But memory management doesn't make much sense if the user
program is allowed to shoot your management information. Ergo, Lisp
should not include pointer arithmetics. Ergo, Lisp is not the right
language for implementing memory management. Ergo, Lisp is not the right
language for implementing Lisp.
You could use this same logic to say that operating systems shouldn't
be implemented in C. But people do, isolating the more unsafe and
nonportable code (e.g., process switching) into modules or libraries
of some kind. Similarly, a vendor could certainly implement a Lisp
library or package to do pointer arithmetic for internal purposes
(like GC); the vendor could even publish the interfaces, so that brave
users with urgent need could increment their pointers without leaving
the Lisp environment.
So: Lisp can't do everything C can, and it is not as fast as C is,
and that's okay with me whenever I don't want to pay the price I have
to pay in C. (it's just the same with C and Assembler, btw.)
The difficulty with this approach is that both developers and managers
like to deal with a single, common language and development
environment for most of their work; other languages and environments
are tolerated only as niche players. Niches are typically unstable;
they either shrink down to near-nothingness or grow into at least
local dominance (i.e., at least within some clearly identifiable class
of developers or applications). Lisp needs to continually demonstrate
some type of dominance in order to flourish long-term.
--
Lawrence G. Mayka
AT&T Bell Laboratories
···@ieain.att.com
Standard disclaimer.
In article <·················@polaris.ih.att.com>,
Lawrence G. Mayka <···@polaris.ih.att.com> wrote:
> You could use this same logic to say that operating systems shouldn't
> be implemented in C. But people do, isolating the more unsafe and
> nonportable code (e.g., process switching) into modules or libraries
> of some kind. Similarly, a vendor could certainly implement a Lisp
> library or package to do pointer arithmetic for internal purposes
> (like GC); the vendor could even publish the interfaces, so that brave
> users with urgent need could increment their pointers without leaving
> the Lisp environment.
Yup. This is how it's done in Oberon.
Oberon is a totally safe language (like any reasonable language)
but it has a SYSTEM module which gives you operations like pointer
arithmetics, casting and other fun stuff.
The Oberon system is single user, so access to SYSTEM isn't too bad
(since you can only crash your machine). But in a 'real' multiuser
distributed system, the SYSTEM module would probably not be publically
available.
Stefan
The Oberon system is single user, so access to SYSTEM isn't too bad
(since you can only crash your machine). But in a 'real' multiuser
distributed system, the SYSTEM module would probably not be publically
available.
That would be an extremely bad design decision! We can always use an
extra layer of interpretation, like in the IBM VM/CMS operating system
in which the operating shields the underlying machine from the user, by
means of a simulation. Each user gets his own virtual machine with
a virtual address space which is mapped to real address space by the OS.
This way the programmer can only mess up his own virtual machine. It
turns out that the loss in performance doesn't have to be as
tremendous as one might expect.
Dirk
In article <···················@triton.cs.kuleuven.ac.be>,
Dirk Dussart <·····@triton.cs.kuleuven.ac.be> wrote:
> That would be an extremely bad design decision! We can always use an
> extra layer of interpretation, like in the IBM VM/CMS operating system
> in which the operating shields the underlying machine from the user, by
> means of a simulation. Each user gets his own virtual machine with
> a virtual address space which is mapped to real address space by the OS.
> This way the programmer can only mess up his own virtual machine. It
> turns out that the loss in performance doesn't have to be as
> tremendous as one might expect.
What about communication between processes ?
Shared memory is a very nice way to communicate. Your scheme goes the
same route as unix: let the user totally free to do whatever he wishes
and just check for the few points where security might be an
issue. But this is not always a good choice. If you want a
single address space shared among multiple (heterogenous) machines,
you'll probably want to have more control over what the user can
do. Replacing the file system by a persisitent structure in the global
address space is also something you might want to do.
The few limitations imposed by a system where only safe languages can
be used offer a lot more freedom to the OS to do all kinds of fancy
tricks. As long as the main language is a dog like C there's not much
hope to see any big improvement in the OS world.
Stefan
What about communication between processes ?
I don't see any difficulty with the scheme I propose. IBM runs AIX
(Unix) on top of VM and AIX does communication and more. The Unix
system runs on top of a virtual machine. This means that the Unix
system can co-exist with other Operating Systems, all running on their
own virtual machines. And a Unix system crash doesn't mean the other
operating systems going down with it. An interesting applications is
debugging operating systems.
Shared memory is a very nice way to communicate.
Who says that one can't simulate shared memory access within the VM-scheme.
Your scheme goes the
same route as unix: let the user totally free to do whatever he wishes
and just check for the few points where security might be an
issue.
No, the system I propose and which is used in practice can basically
check for everything. Think of a computer emulating itself in
software. The emulation is complete and does include emulation of devices
as printers, disks, ... The Meta-Operating System (implementing the
virtual machines) takes care of mapping the virtual world to real
world (from virtual devices to real devices).
But this is not always a good choice. If you want a
single address space shared among multiple (heterogenous) machines,
you'll probably want to have more control over what the user can
do. Replacing the file system by a persisitent structure in the global
address space is also something you might want to do.
I can extend the VM-scheme to multiple machines if you like: a network of
computers emulating a network of computers (in which the number
virtual workstations can be much higher than the number of real
workstations :-) ) We can even start talking about virtual topology if
you like ;-)
I simply considered this as a mental exercise, and didn't think about
performance. But I imagine researchers have already implemented those
beasts.
The few limitations imposed by a system where only safe languages can
be used offer a lot more freedom to the OS to do all kinds of fancy
tricks.
I don't consider the Virtual Machine concept a fancy trick but mere
elegance.
As long as the main language is a dog like C there's not much
hope to see any big improvement in the OS world.
I'm strongly in favor of using languages that impose a lot more
restrictions (e.g. a good type system). [Personally I do most of my
programming in Haskell (so I can even live with state
restrictions)]. I'm definitely in favor of using these languages for
writing system software. But even in programming languages, in which
one has to explicitly ask for pointer arithmetic, systems programmers
will make programming mistakes.
-- Dirk
In article <·················@netcom.com> ·······@netcom.com "james brister"
writes:
> brister>I'd no sooner choose
> brister>C++ to write a symbolic math package than I'd use LISP to write a
> brister>network transport package.
Peter Lee and his group at CMU have had considerable success writing an TCP/IP
stack in ML. ML is non-reflective, but still requires a garbage collector,
etc. See:
http://www.cs.cmu.edu:8001/afs/cs.cmu.edu/project/fox/mosaic/HomePage.html
--Mitch
Mitchell Wand Internet: ····@ccs.neu.edu
College of Computer Science, Northeastern University
360 Huntington Avenue #161CN, Boston, MA 02115 Phone: (617) 373 2072
World Wide Web: http://www.ccs.neu.edu/home/wand Fax: (617) 373 5121
In article <··········@info-server.bbn.com> ·····@bbn.com writes:
>suppose all that stuff could exist as a shared library...maybe your
>executable COULD be microscopic, and the shared stuff would only be
>called when used.
Like WCL? Here's the FAQ entry:
WCL is an implementation of Common Lisp for Sparc based workstations.
It is available free by anonymous ftp from
gummo.stanford.edu:/pub/miscellany/wcl/ [36.93.0.31]
The file wcl-2.14.tar.Z contains the WCL distribution, including CLX
and PCL; wgdb-4.2.tar.Z contains a version of the GDB debugger which
has been modified to grok WCL's Lisp; and gcc-2.1.tar.Z contains the
GNU C compiler (2.2.2 does not work!). WCL provides a large subset of
Common Lisp as a Unix shared library that can be linked with Lisp and
C code to produce efficient and small applications. For example, the
executable for a Lisp version of the canonical ``Hello World!''
program requires only 40k bytes under SunOS 4.1 for SPARC. WCL
provides CLX R5 as a shared library, and comes with PCL and a few
other utilities. For further information on WCL, see the paper
published in the proceedings of the 1992 Lisp and Functional
Programming Conference, a copy of which appears in the wcl directory
as lfp-paper.ps, or look in the documentation directory of the WCL
distribution. Written by Wade Hennessey <····@sunrise.stanford.edu>.
Please direct any questions to ···@sunrise.stanford.edu. If you would
like to be added to a mailing list for information about new releases,
send email to ···········@sunrise.stanford.edu.
--
Barry Margolin
System Manager, Thinking Machines Corp.
······@think.com {uunet,harvard}!think!barmar
In article <············@early-bird.think.com>, ······@think.com (Barry Margolin) writes:
|> In article <··········@info-server.bbn.com> ·····@bbn.com writes:
|> >suppose all that stuff could exist as a shared library...maybe your
|> >executable COULD be microscopic, and the shared stuff would only be
|> >called when used.
|>
|> Like WCL? Here's the FAQ entry:
|>
|> WCL is an implementation of Common Lisp for Sparc based workstations.
|> It is available free by anonymous ftp from
|> gummo.stanford.edu:/pub/miscellany/wcl/ [36.93.0.31]
|> The file wcl-2.14.tar.Z contains the WCL distribution, including CLX
|> and PCL; wgdb-4.2.tar.Z contains a version of the GDB debugger which
|> has been modified to grok WCL's Lisp; and gcc-2.1.tar.Z contains the
|> GNU C compiler (2.2.2 does not work!).
Everytime I've tried WCL, the CLX and PCL parts have been missing. All the docs
claim they should be there with the rest of the distribution but I've never been
able to find them.
Mike McDonald Advanced Technology Dept.
Harris Corp.
Email: ···@trantor.harris-atd.com M.S. 16-1912
Voice: (407) 727-5060 P.O. Box 37
Fax: (407) 729-3363 Melbourne, Florida 32902
In article <··········@jabba.ess.harris.com> ···@trantor.harris-atd.com (Mike McDonald) writes:
From: ···@trantor.harris-atd.com (Mike McDonald)
Organization: Advanced Technology Dept, Harris Corp, Melbourne, FL
Date: Fri, 10 Jun 1994 14:25:00 GMT
Everytime I've tried WCL, the CLX and PCL parts have been missing.
All the docs claim they should be there with the rest of the
distribution but I've never been able to find them.
Mike McDonald Advanced Technology Dept.
The doc is a bit misleading, because only the shared libraries for the
CL runtime and the compiler are provided in the distribution, along
with the sources for CLX and PCL. You have to "make install" wcl to
build the CLX shared library and to build the PCL binaries. A full
install also provides versions of the libraries that contain full
debugging information usuable by wgdb.
It seems that most people skip the "make install" and just run the
supplied binaries, hence the confusion. -wade
In article <··········@info-server.bbn.com> ·····@bbn.com writes:
>suppose all that stuff could exist as a shared library...maybe your
>executable COULD be microscopic, and the shared stuff would only be
>called when used.
Like WCL? Here's the FAQ entry:
WCL is an implementation of Common Lisp for Sparc based workstations.
It is available free by anonymous ftp from
gummo.stanford.edu:/pub/miscellany/wcl/ [36.93.0.31]
The file wcl-2.14.tar.Z contains the WCL distribution, including CLX
and PCL; wgdb-4.2.tar.Z contains a version of the GDB debugger which
has been modified to grok WCL's Lisp; and gcc-2.1.tar.Z contains the
GNU C compiler (2.2.2 does not work!). WCL provides a large subset of
Common Lisp as a Unix shared library that can be linked with Lisp and
C code to produce efficient and small applications. For example, the
executable for a Lisp version of the canonical ``Hello World!''
program requires only 40k bytes under SunOS 4.1 for SPARC. WCL
provides CLX R5 as a shared library, and comes with PCL and a few
other utilities. For further information on WCL, see the paper
published in the proceedings of the 1992 Lisp and Functional
Programming Conference, a copy of which appears in the wcl directory
as lfp-paper.ps, or look in the documentation directory of the WCL
distribution. Written by Wade Hennessey <····@sunrise.stanford.edu>.
Please direct any questions to ···@sunrise.stanford.edu. If you would
like to be added to a mailing list for information about new releases,
send email to ···········@sunrise.stanford.edu.
--
Barry Margolin
System Manager, Thinking Machines Corp.
······@think.com {uunet,harvard}!think!barmar
In article <··········@info-server.bbn.com> ·····@bbn.com writes:
>lisp device drivers were only feasible on lisp machines, because all the
>"runtime support" was already part of the OS.
Just thought I'd point out that Thinking Machines wrote its device driver
for the CM1/CM2 in Lisp. This was because it was originally written for
the Lisp Machine, but it was then ported to Lucid CL for the Sun and Vax.
The Unix version used the system device driver to map the bus into the Lisp
address space, but then did everything else in native Lisp code (using
subprimitives to read and write addresses).
When we needed to implement a C library to interface to the CM, we wrote a
Lisp-subset->C translator.
--
Barry Margolin
System Manager, Thinking Machines Corp.
······@think.com {uunet,harvard}!think!barmar