Thanx in advance.

It has some extensions such as regular expresion, object oriented system
CLOS based, timer, profile file, console text interface with simple
OO widget.
OpenScheme will be extended with a full OO GUI in the next release

Sincerely.

% geeez Justin too bad your so busy, one of the best time savers there is in
% lisp programming (unless maybe you are a pro already)  is reading this news
% group.  Reading a few postings can often save hours and hours of booking it
% tring to figure out what UNWIND-PROTECT does (for example), when you would
% use it and why you never used it in the past.   Lots of examples like
% this.....t'is time well spent.

It's also a shame he couldn't just go to dejanews and search on the
key phrase, "I'm so lazy that I will just go ahead and post a message
asking what people ask about five times a week.

--
David Steuber (ver 1.31.3a)
http://www.david-steuber.com
To reply by e-mail, replace trashcan with david.

One possible exception is Siskind's "Stalin", which allegedly
compiles Scheme very well indeed; but my understanding is that
(1) it's not entirely stable and (2) it's very slow when
compiling large programs (because its efficiency is achieved
by doing some impressive whole-program analysis).

* Gareth McCaughan <gj...@dpmms.cam.ac.uk>
| I like Scheme a lot, but "Scheme is an efficient Lisp dialect" seems to
| me like a really bogus thing to say.

  it's always interesting to see how something really bogus could be true,
  perhaps especially if it obviously isn't.  so consider "Scheme is an
  efficient Lisp dialect".  since the author of that statement, like most
  other Scheme adherents, is behind yet another Scheme implementation, I
  guess he's very happy that his implementation of Scheme is efficient.
  and since he, like most other Scheme adherents, have a chip on their
  shoulders the size of the Common Lisp specification against Common Lisp,
  it's only fair to assume that he meant that it would take him hundreds of
  years to implement Common Lisp and that he, as an implementer, rather
  than a user, prefers really tiny languages.

  I must say that I have found Kent Pitman's argument that small languages
  require big programs, whereas large languages enable small programs, to
  be very compelling.

The following was published on this list on Nov 2, 1998:

Subject: new Common Lisp for Windows 95/98/NT on the web
Date: 2 Nov 1998 08:57:24 GMT
From: Roger Corman <ro...@corman.net>
Organization: Corman Tools
Newsgroups: comp.lang.lisp

Dear lisp users,

On Lisp's 40th birthday, I am pleased to announce a new Common Lisp
compiler and development environment for Windows 95/98/NT. This is a
full
featured system with very fast performance (competitive with the fastest
Windows
Common Lisps) and full support for using Win32 to build applications.
It compiles to machine code (no interpreter is included), supports
OS-level threads (minimal support now, more under development)
save-image, save-application, etc.

The compiler is free, and I am distributing the source code along
with it (in Common Lisp). A free console app may be used to interact
with the compiler (a listener) but the included IDE application provides
a much richer lisp-enhanced editor and development environment.
I plan to ask a modest license fee for the IDE, although details are
not finished. The included evaluation copy of the IDE is fully
functional for 30 days, after which it will add a nag dialog (and
I hope to have licensing details finalized by then).

I know many of you in this newsgroup will be both interested and
possibly skeptical of this system, and I encourage you to please
download a copy and try it out. I have included some documentation
(in the form of a Word 97 format manual) but have not had time to
document it extensively. Any of you who get back to me with helpful
feedback I will be happy to repay you with a free registration code
for the IDE.

I am the developer of PowerLisp for the Macintosh, which has
been useful for many years for a large number of people.
This new product, called Corman Lisp, is far superior, however, and has
been written from the ground up for the Win32 environment. I have
been working on it for over 2 years, and am eager to get some
feedback. I believe it will fill an important niche and make Common
Lisp a more viable development platform.

You may download the latest version at the following site:
http://corman.net/lisp

The download is about 2.5 megs, and is a self-extracting installer
program, which installs the compiler, IDE, console (which you don't
need if you use the IDE) and source code.

Thanks,

Roger Corman

And there are a few places where Scheme manages to be simpler
in theory at the cost of being harder in practice. The usual
example is a good one: Continuations are a really clever idea,
and make for a powerful language with few primitives; but they
aren't often what you actually want when writing a program.
And Scheme itself doesn't provide any of the useful things
that could be based on continuations (throw/catch being an
obvious example), so you have to write it yourself. And since
continuations are confusing to many people, this is a pain.

Another standard example. In Scheme, you can do iteration with
DO, MAP, FOR-EACH, or tail recursion. In Common Lisp, you have
a whole family of MAPxxx functions; an equivalent of FOR-EACH;
DO and DO*; the hairy but very powerful LOOP; the ability to
write horrible things with GO; special iterators for things like
hash tables and packages; and (sort of) tail recursion. (And
probably a few other things I've forgotten.) This is certainly
harder to learn, but it's much easier to program with once you've
learned it.

All these things can, of course, by added by good libraries of
macros and procedures. But once you do that, what you have is
no longer just Scheme; it's Scheme plus a bunch of libraries.
You lose the small size that makes Scheme elegant and easy to
learn; you probably also lose the consistency that comes from
the very conservative attitude of the RnRS authors. And what you
have maybe no longer works in all Scheme implementations.

This all sounds very negative, which is a shame because I think
Scheme is *for some purposes* a great language. But I really
can't think of any useful sense in which it's more "efficient"
than Common Lisp in practice.

Now, Scheme is certainly basically a much more elegant design
than CL. I bet it could be used as the *basis* for a more
"efficient" Lisp dialect, for almost any sensible meaning
of "efficient". But it isn't one yet, and I don't see much
sign of its becoming one very soon.

  there really isn't much to designing small things elegantly.  small is
  almost inherently beautiful.  the challenge is making things scale well.
  e.g., I'd argue that an ant is more elegantly built than an elephant.
  now, scale the ant up so it can handle as big a load as the elephant.
  surprisingly to some, its support structure collapses and it cannot
  handle any load at all.

Have you tried CLISP? FWIW, I was bored two weeks ago or so and
decided to compare load times (just load and immediate "(exit)"
or "(quit)") of different Scheme and Common Lisp
implementations. I can't remember all the details, but after
trying few Schemes (at least MzScheme, Guile, scsh, Bigloo,
Gambit) and CLs (CLISP, ECL (not sure), ACL5, CMUCL), CLISP
seemed to be the fastest of all. IIRC, I finally found one
implementation that was marginally faster: sci, the Scheme
interpreter written in Scheme and compiled with Scheme-to-C.
Anyway, the difference between those two was barely noticeable
and timing on a server machine is not too accurate, so one can't
really make any conclusions on that. The machine I used was
P5/120 running Debian GNU/Linux (libc6).

We think that a language is powerful when it is specified very shortly, and
if with this specification, it can be adaptable to the most part of problems.
Scheme has shown its efficient to write processor simulators, language
compilers, objet oriented systems, graphical application, and so on.

OpenScheme contain 90000 line of code, mainly in Scheme itself. Writing new
special forms to extend the language is a piece of cake that we reserve
for the Scheme users (They like cakes). OpenScheme includes a
compiler/interpreter/debugger, regular expressions,
timers, console interface, object oriented system, profile file. The next release

will include primitive graphic interface, OO GUI, threads, postgress interface
and a native database engine. If you want to consider these library interface
as specification, you can. But in fact, Scheme is entirely specified in the
RxRS reports with less than 10 pages!

Sincerely,

Guilhem de Wailly

 I must say that I have found Kent Pitman's argument that small languages

Guilhem de WAILLY <g...@linux-kheops.com> writes:

< OpenScheme contain 90000 line of code, mainly in Scheme itself.
< Writing new special forms to extend the language is a piece of cake
< that we reserve for the Scheme users (They like cakes). OpenScheme
< includes a compiler/interpreter/debugger, regular expressions,
< timers, console interface, object oriented system, profile file. The
< next release

Does it have a native code compiler? Just curious, as I only know of a
few schemes which go this route. Most try to re-write the code into
some other language, which is nice, but doesn't really add value to
the scheme system. If anything, it just trys to show how flexible
`simpler' languages can be, but fails to reinforce the one of the most
powerful aspects of the language. That is, the system seems less
extensible (even with an object code loaded).

Here are the Common Lisp compilers I've used that go directly to machine
code, there are many others I won't name because I know them only by
reputation:

  Macintosh Common Lisp
  CMU Common Lisp
  Allegro Common Lisp (PC and Unix)
  Harlequin Lispworks (Windows and Unix)
  Lucid/Liquid Common Lisp
  PowerLisp (Roger Corman's shareware Mac compiler)

In fact, the only compiler I've used that took the compile-to-C approach is:

  Kyoto Common Lisp (irrelevant today because of CMUCL)

There are a few variations of KCL (AKCL, GCL, others?) and some academic
projects (CLiCC, ECL) that also took the compile-to-C approach.  The main
thing they all seemed to have in common is that they were written by one or
two people and had intensions toward portability -- both seem to weight
design decisions in favor of compiling to a portable low-level language
rather than direct to machine code.

BTW, Eclipse Common Lisp compiles to C as a _feature_, touted by the vendor
because it allows seamless integration of Lisp in C code (without FFI):

One current almost-Common Lisp implementations (CLISP) compiles to byte-code
rather than to machine code or C.  One other (XLISP) is -- I think -- a pure
intepreter.

I'm less familiar with Scheme systems, but _of the ones I've noticed_ only
Gambit-C and Scheme->C use the compile-to-C approach.  The rest seem to be
native or byte-code compilers, or (rarely) a pure interpreter.

[snip]

  on my dual 400MHz Pentium II machine with 512M RAM, Emacs and Allegro
  Common Lisp start in 0.04 real-time seconds, mostly because Emacs has to
  talk the X protocol with the slower 50MHz SPARCstation 2 that is still my
  X server, while bash starts in 0.001 seconds.  I tend to start Emacs and
  Allegro CL once every week or so, while there have been more than 8000
  invocations of bash since my system last booted 5 days ago.  speaking of
  which, it took several _minutes_ to boot after a prolonged power failure
  (I love the cold of winter -- NOT!), with all the disks it has to check
  and all the other silly things it has to do, but I still don't count the
  boot time when I measure the running time of my programs.  isn't that odd?

  oh, by the way, I have tried scsh.  it took 0.7 seconds to load while in
  the disk cache on this system.  I think I'll fault Scheme for that today.

  I hope this was almost as silly as your conjecture, but illuminating.

  there was this group of men who had grown up together and went to school
  together and worked together for their whole life, and now they had been
  placed in a home for the elderly together.  they knew each other so well
  they had decided to number their stories instead of just retelling them
  over and over, which had gotten to be quite tedious.  so they were
  sitting in the living room of this place and telling stories.  "342!",
  said one, and all of them laughed.  "916!", said another, and they
  snickered and looked at one of them who didn't smile at all.  "426!", he
  retorted, and they all laughed out aloud.  another elderly gentleman
  enters the living room and he overhears one of them say "720!".  he
  bursts out laughing, much to the surprise of the other guys.  "what are
  _you_ laughing at?", one asked, almost scornfully.  "it wasn't _that_
  funny!"  "oh, I'm sorry," said the intruder humbly, "it's just that I
  hadn't heard that one before."

  seriously, I have three great sources on Lambda Calculus, all by H. P.
  Barendregt.  one is his seminal work, The Lambda Calculus, Its Syntax and
  Semantics¹, a 622-page book.  another is his chapter on Lambda Calculi
  with Types in the amazingly compact Handbook of Logic in Computer
  Science², a 193-page condensed exposition.  (it ends with a sentence that
  had me laughing real hard when I first encountered it: "Glancing over the
  next few pages, the attentive reader that has worked through the proofs
  in this subsection may experience a free association of the whirling
  details."  the following pages (296-298) are absolutely hilarious.)  the
  third is a 12-page section in his article on Functional Languages and the
  Lambda Calculus in the truly fantastic work Handbook of Theoretical
  Computer Science³.  I'd argue that these decrease in complexity in the
  order I listed them, but now only three lines, huh?

  I'm reminded of one guy who seriously believes that all of Ayn Rand's
  works can be expressed as "A is A", too.  you all know that's Aristotle.

How would you do this? I've seen a couple of libraries that
dynamically compile code and do something with it so that it can be
run without restarting - but the code was _way_ out of my league of
understanding.

< Lisp is not C, after all, and so there are often better ways of
< generating code rather than having to reformulate Lisp into C.

When I hear of a scheme outputting C code, I am almost reminded of a
virus (except maybe without the command line options). That is, if you
compiled the scheme compiler, wrote something with it; you'd have to
recompile most of the scheme compiler to get the program to work
wouldn't you? Would a shared system library make it easier?

Maybe some people feel more comfortable using a C compiler (which is
probably reasonable; I've heard good things about the Intel and MS
compiler/assembler duo). I think compiling to C is a rather difficult
task though (scheme and C don't seem to share many commonalities).

Implementation          fresh (s)       in-cache (s)
-----------------------------------------------------
ACL 5.0                 2.224           0.117
CMU CL CVS 2.4.7        3.593           0.081
CLISP 97-12-06          0.572           0.103
Guile 1.2               0.894           0.550
Elk 3.0                 0.182           0.018
Bash 2.01                ---            0.012
Bash 2.01 on AMD5x86     ---            0.064
-----------------------------------------------------
Notes:
  - All times are real-time in seconds obtained via
    the internal time command of bash 2.01
  - The last entry is for Bash 2.01 on an old AMD
    5x86-133 box, which has ca. P75-P90 general
    non-floating point performance.  Actually in
    mid-1996 this system achieved the performance of
    most entry-level Unix Workstations at the time
    under Linux 2.0.  So any scripting-engine with
    a reload-time in this range should be fast enough

Regs, Pierre, who'd like this newsgroup to return to more fruitful
topics than OS-wars and the fight on OSS...

PS: Here is the log-file for the timing sessions:

ACL 5.0 (not in cache and in cache):

bash-2.01$ time /opt/acl5/lisp -e '(excl:exit)'
Loading /opt/acl5/libacl503.so.
Mapping /opt/acl5/lisp.dxl...done.
Mapping /opt/acl5/acl503.epll.
Allegro CL Trial Edition 5.0 [Linux/X86] (8/29/98 10:57)
Copyright (C) 1985-1998, Franz Inc., Berkeley, CA, USA.  All Rights Reserved.
; Exiting Lisp

real    0m2.224s
user    0m0.040s
sys     0m0.040s
bash-2.01$ time /opt/acl5/lisp -e '(excl:exit)'
Loading /opt/acl5/libacl503.so.
Mapping /opt/acl5/lisp.dxl...done.
Mapping /opt/acl5/acl503.epll.
Allegro CL Trial Edition 5.0 [Linux/X86] (8/29/98 10:57)
Copyright (C) 1985-1998, Franz Inc., Berkeley, CA, USA.  All Rights Reserved.
; Exiting Lisp

real    0m0.117s
user    0m0.070s
sys     0m0.000s

CMU CL CVS-Version 2.4.7 (fresh and in cache):

bash-2.01$ time lisp -eval '(quit)'
;;; *** Don't forget to edit /var/lib/cmucl/site-init.lisp! ***

real    0m3.593s
user    0m0.010s
sys     0m0.060s
bash-2.01$ time lisp -eval '(quit)'
;;; *** Don't forget to edit /var/lib/cmucl/site-init.lisp! ***

real    0m0.081s
user    0m0.060s
sys     0m0.010s

CLISP 1997-12-06 (fresh and in cache):

bash-2.01$ time clisp -x '(quit)'
  i i i i i i i       ooooo    o        ooooooo   ooooo   ooooo  
  I I I I I I I      8     8   8           8     8     o  8    8  
  I I I I I I I      8         8           8     8        8    8  
  I I I I I I I      8         8           8      ooooo   8oooo  
  I  \ `+' /  I      8         8           8           8  8      
   \  `-+-'  /       8     o   8           8     o     8  8      
    `-__|__-'         ooooo    8oooooo  ooo8ooo   ooooo   8      
        |                                                        
  ------+------     Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
                    Copyright (c) Bruno Haible, Marcus Daniels 1994-1997

Bye.

real    0m0.572s
user    0m0.010s
sys     0m0.030s
bash-2.01$ time clisp -x '(quit)'
  i i i i i i i       ooooo    o        ooooooo   ooooo   ooooo  
  I I I I I I I      8     8   8           8     8     o  8    8  
  I I I I I I I      8         8           8     8        8    8  
  I I I I I I I      8         8           8      ooooo   8oooo  
  I  \ `+' /  I      8         8           8           8  8      
   \  `-+-'  /       8     o   8           8     o     8  8      
    `-__|__-'         ooooo    8oooooo  ooo8ooo   ooooo   8      
        |                                                        
  ------+------     Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
                    Copyright (c) Bruno Haible, Marcus Daniels 1994-1997

Bye.

real    0m0.103s
user    0m0.010s
sys     0m0.010s

Guile 1.2 (fresh and in cache):

bash-2.01$ time guile -c ''

real    0m0.894s
user    0m0.540s
sys     0m0.010s
bash-2.01$ time guile -c ''

real    0m0.550s
user    0m0.540s
sys     0m0.010s

Elk 3.0 (fresh and in cache):

bash-2.01$ time echo "(exit)" | scheme

Bash 2.01 (in cache):

bash-2.01$ time bash -c ''

real    0m0.012s
user    0m0.010s
sys     0m0.000s

The same on an old AMD5x86-133 (ca. P90 integer performance, in cache):

$ time bash -c ''

real    0m0.064s
user    0m0.040s
sys     0m0.020s

Not only that, but it is quite common [at least for some architectures
I'm familiar with (*cough*) (*cough*)] for the native C compiler and/or
assembler to contain bunches of "workarounds" for CPU chip bugs. So a
Lisp compiler that emits machine code directly needs to implement all
the same workarounds... (*ugh!*)  for every architecture you want it
to run on... (*ugh!*)  To me, that's another real advantage of using C
as the target.

-Rob

The nature of the bug was that if a jump instruction was on the last
word of the page (meaning that the delay instruction would be on
another page), and if the delay instruction's page was not yet
paged in, the page would not be properly faulted in and the execution
of that jump instruction would likely fail with a SEGV.

SGI's "fix" was to arrange for the linker to guarantee that none of
these jump instructions would fall on the last word of a page,
either by rearranging code or by inserting well-placed nop instructions.
Since the linker was not involved in lisp code linking, this guarantee
could not be made.  Other workarounds were possible, but most resulted in
code bloat and were unacceptable for a language that was always
blasted for being "too big".

The real solution would have been to purge all of the affected chips
from the customer base, but SGI (understandably) did not want to do
such a swapout when most of its customer based was fixed up with their
linker workaround.  So we worked out a compromise, where we (Franz)
identified our affected customers, and SGI swapped out those chips.
It was a good compromise and a win for all concerned.

Perhaps, if people are interested, I can put together a list of
design tradeoffs between native-compilation and compile-to-C
implementation.  It would, of course, be biased toward the
native-compilation side, because that is how we've gone, but
at least it might provide fodder for a good technical discussion.