Windows LISP Interpreter?
bambo...@hotmail.com
Hello all! My knowledge of LISP is practically zero, but I am very
interested in building a LISP interpreter for Windows. I heard that LISP
can be declared as a small (<40 operators) core and all the rest 900+
operators can be implemented in terms of that core. If that is true,
where can I get the description of that core and the sources/definitions
for the rest of the language? I need exact URLs, please. Currently i
plan to use Delphi for the core implementation but might change my mind
on the way. All results (if any) would be posted as public domain. Would
someone be interested in helping me with that?
Sincerely,
Syarzhuk Kazachehnka
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Hrvoje Niksic
bambo...@hotmail.com writes:
> Hello all! My knowledge of LISP is practically zero, but I am very
> interested in building a LISP interpreter for Windows. I heard that LISP
> can be declared as a small (<40 operators) core and all the rest 900+
> operators can be implemented in terms of that core.
This is true, if you want to create a toy lisp for fun or education.
Creating an ANSI-compliant Lisp interpreter is a sizeable endeavour.
--
Hrvoje Niksic <hni...@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"Silence!" cries Freydag. "I did not call thee in for a consultation!"
"They are my innards! I will not have them misread by a poseur!"
Hrvoje Niksic
vro...@netcom.com (William Paul Vrotney) writes:
> > This is true, if you want to create a toy lisp for fun or education.
> > Creating an ANSI-compliant Lisp interpreter is a sizeable endeavour.
>
> The part about ANSI-compliant is true. You can build an interpreter
> and small set of forms and functions that manipulates just a few
> data types: lists and atoms and a small set of atom subtypes. This
> small system is *not* just toy, you can get some real work done with
> it. In a computational sense it is complete, it is just not quit as
> efficient.
I should have been more careful with the word "toy." I agree with you
that one can get real work done with such a Lisp. However, the author
must at all times remember that he chose to disregard the existing
conventions in his Lisp -- and the only solid convention we currently
have are the ANSI specs. Because of inevitable interface differences,
lots of Lisp code written for various more or less conforming systems
will refuse to work on "toy" Lisps.
All of this doesn't render such Lisps unusable -- far from that! For
instance, Emacs Lisp can be labeled a toy Lisp in the same sense,
without any demeaning connotation -- one can certainly do lots of
useful (and "real") work with it.
> For example you do not need struct or class atoms, you can do most
> everything you can do with those by using association lists, which
> needs basically only lists and symbols. So for the atom subtypes
> you need at least symbols. And integers are easy atoms to add and
> useful.
>
> Do *not* worry about efficiency issues, that will come later. Using
> this bootstrapping technique you can build up your Lisp system later
> to include a compiler and other efficiency and convenience forms and
> functions.
Can you defend this position? I don't have much experience with
various Lisps, but the example of Emacs Lisp seems to show that:
1) it is *not* easy to avoid the implementation constraints (like
using only lists and symbols), especially if they are not followed
by a clean interface;
2) it is *not* easy to make an /ad hoc/ created system efficient
later. In spite of the byte-compiler, Emacs Lisp is still
astoundingly slow, and shows little hope of becoming significantly
faster in the future.
Both of these points can be discussed in more details, if there is
interest.
What I would like to know is specifically, how do you envision the
right path for bootstrapping a small, garden-variety Lisp into a
serious Lisp environment?
--
Hrvoje Niksic <hni...@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
4. Thou shalt not warlorde a sig if it bee the sig of Kibo, nor if
it bee the sig of the Inner Circle.
William Paul Vrotney
In article <kigbu04...@jagor.srce.hr> Hrvoje Niksic <hni...@srce.hr>
writes:
>
> Syarzhuk Kazachehnka:
> > Hello all! My knowledge of LISP is practically zero, but I am very
> > interested in building a LISP interpreter for Windows. I heard that LISP
> > can be declared as a small (<40 operators) core and all the rest 900+
> > operators can be implemented in terms of that core.
>
> This is true, if you want to create a toy lisp for fun or education.
> Creating an ANSI-compliant Lisp interpreter is a sizeable endeavour.
>
The part about ANSI-compliant is true. You can build an interpreter and
small set of forms and functions that manipulates just a few data types:
lists and atoms and a small set of atom subtypes. This small system is
*not* just toy, you can get some real work done with it. In a computational
sense it is complete, it is just not quit as efficient. For example you do
not need struct or class atoms, you can do most everything you can do with
those by using association lists, which needs basically only lists and
symbols. So for the atom subtypes you need at least symbols. And integers
are easy atoms to add and useful.
Do *not* worry about efficiency issues, that will come later. Using this
bootstrapping technique you can build up your Lisp system later to include a
compiler and other efficiency and convenience forms and functions.
If Syarzhuk or anyone has the desire to do this we should not discourage.
For a place to get started I recommend
Lisp (any edition) - Winston/Horn
in which there is a chapter called "Lisp in Lisp" which gives such a simple
interpreter in Lisp. Although you can use that program as a model to do the
same thing in most any other programming language such as C. The book is
also a good tutorial for learning Lisp.
Only at that point would I recommend borrowing Lisp functions from the
public domain of which there are many. See the Lisp FAQ. Many of the
public domain Lisps use a similar form of bootstrapping and you can steal
lots of "Lisp in Lisp" functionality from these functions. See for example
GCL and CMUCL.
If you get this simple interpreter system working then you may want to get
more serious about more advanced Lisp constructs in which case I would
recommend
Anatomy of Lisp - Allen
where you can learn about types of binding environments and more advanced
things like garbage collectors, funargs (closures) etc.
--
William P. Vrotney - vro...@netcom.com
Frank A. Adrian
William Paul Vrotney wrote in message ...
>If you get this simple interpreter system working then you may want to get
>more serious about more advanced Lisp constructs in which case I would
>recommend
>
> Anatomy of Lisp - Allen
>
>where you can learn about types of binding environments and more advanced
>things like garbage collectors, funargs (closures) etc.
Nowdays, I would tend to recommend LISP In Small Pieces by Christian
Queinnec. Allen used to be the standard, but Queinnec's new book blows it
away for implementation details...
--
Frank A. Adrian
First DataBank
frank_...@firstdatabank.com (W)
fra...@europa.com (H)
This message does not necessarily reflect those of my employer,
its parent company, or any of the co-subsidiaries of the parent
company.
Aaron Leung
There is a book called "Programming Languages: An Interpreter-Based
Approach" by Samuel Kamin, published by Addison-Wesley in 1990. It begins by
describing a Lisp interpreter written in Pascal and then builds upon that.
-Aaron
Barry Margolin
In article <vrotneyE...@netcom.com>,
William Paul Vrotney <vro...@netcom.com> wrote:
>Strongly disagree! Improving an existing Lisp system for a beginner is
>daunting to say the least. Why do think so many Lisp textbooks advocate
>building a simple Lisp interpreter such as Winston/Horn "Lisp in Lisp" as
It's intended as an academic exercise, not as a way to get a Lisp
implementation useful for serious work.
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
Support the anti-spam movement; see <http://www.cauce.org/>
Please don't send technical questions directly to me, post them to newsgroups.
William Paul Vrotney
In article <kigzpnn...@jagor.srce.hr> Hrvoje Niksic <hni...@srce.hr>
writes:
>
> vro...@netcom.com (William Paul Vrotney) writes:
> >
> > Do *not* worry about efficiency issues, that will come later. Using
> > this bootstrapping technique you can build up your Lisp system later
> > to include a compiler and other efficiency and convenience forms and
> > functions.
>
> Can you defend this position?
Sure. For example many Common Lisps implemented simple one dim arrays as a
primitive atom and then implement struct and class objects using those
primitive arrays.
Also, bootstrapping a language compiler and then writing more robust
compiler versions in the bootstrapped compiler is as old as the hills. In
Lisp this is even more "bootstrappy" in that you don't even need to start
with a primitive compiler, you can write your first compiler in your
primitive interpreter!
> I don't have much experience with
> various Lisps, but the example of Emacs Lisp seems to show that:
>
> 1) it is *not* easy to avoid the implementation constraints (like
> using only lists and symbols), especially if they are not followed
> by a clean interface;
>
> 2) it is *not* easy to make an /ad hoc/ created system efficient
> later. In spite of the byte-compiler, Emacs Lisp is still
> astoundingly slow, and shows little hope of becoming significantly
> faster in the future.
>
> Both of these points can be discussed in more details, if there is
> interest.
Well, the Emacs byte-compiler generates code that is still interpreted, much
like Java. However, I have to say that taking all into consideration Emacs
does pretty darn well. Frankly most of my entirely C coded word processors
feel like they are as slow or slower on many operations (eg. spelling
checking, search and replace, finds) than Emacs on similar operations. They
are certainly clunkier than Emacs. When you say that Emacs is slow could
you point to something more specific?
>
> What I would like to know is specifically, how do you envision the
> right path for bootstrapping a small, garden-variety Lisp into a
> serious Lisp environment?
>
1. Build a small primitive interpreter as was discussed previously and
outlined in many books on Lisp.
2. Add new functionality by either adding new primitives or new functions
written in your primitive interpreter language. Each new interpreter
generation is more robust.
3. When your interpreter generation is robust enough, write a compiler in
that interpreter language. You are allowed to borrow from public domain
Lisp compilers.
4. Using the compiler in (3.) go back and compile your current generation
interpreter and compiler.
5. Continue in this loop building more powerful interpreter and compiler
generations. You can accelerate this into a more serious Lisp environment by
stealing public domain higher level functions and algorithms as was
pointed out earlier.
In my opinion the biggest stumbling block to this approach is not the
approach itself but the implications of step (3), which is the decision to
go with a byte code interpreter as in Emacs or native code compiler
generator as in Allegro. The native code compiler will generate faster code
but the byte-code compiler/interpreter will be more portable and flexible.
CMUCL is an interesting technology to study here as an example of
intermediate virtual machine representation that gets translated into native
code. GCL is also quite ingenious in that it compiles to C code. You can
download and study these and others. CLISP and Elisp are examples of
byte-code compiler/interpreters.
Finally just a related aside:
Did you ever see the instruction cards for machine codes or various CPUs?
Most will use a semi-formal algorithmic language for for describing the
control flow of each instruction. I have often fantasized about the
following:
1. Develop a general CPU description language.
2. Develop a general OS interface description language.
3. Develop a compiler that translates directly to native code by
interpreting (1.) and (2.). Those interpreted results could be
compiled for faster compiler operations.
The idea is that after you are though you only need declare an instance of
(1.) and (2.) which should only be a few pages and then your compiler now
works on another platform. This could easily qualify as an "AI approach to
compilers" since this procedure is close to what an intelligent systems
programmer does to write a native code compiler.
Of course now that the Pentium and MSOS has monopolized the world [sarcasm]
this is useless. :-)
Rainer Joswig
In article <vrotneyE...@netcom.com>, vro...@netcom.com (William Paul
Vrotney) wrote:
The part about ANSI-compliant is true. You can build an interpreter and
> small set of forms and functions that manipulates just a few data types:
> lists and atoms and a small set of atom subtypes.
That I disagree about the importance of atoms, I probably don't
have to say. ;-)
> If Syarzhuk or anyone has the desire to do this we should not discourage.
How about using one of the myriads of Lisp implementations and
write real Lisp applications?
> If you get this simple interpreter system working then you may want to get
> more serious about more advanced Lisp constructs in which case I would
> recommend
>
> Anatomy of Lisp - Allen
>
> where you can learn about types of binding environments and more advanced
> things like garbage collectors, funargs (closures) etc.
Get "Lisp In Small Pieces". It has everything you want and more.
Kelly Murray
>>>>> Hrvoje Niksic <hni...@srce.hr> writes:
>>>>> Hello all! My knowledge of LISP is practically zero, but I am very
>>>>> interested in building a LISP interpreter for Windows. I heard that LISP
> > If Syarzhuk or anyone has the desire to do this we should not discourage.
> How about using one of the myriads of Lisp implementations and
> write real Lisp applications?
For sure.
Yet another "toy" LISP implementation would not help the LISP community.
That's not to say one shouldn't do what one finds interesting,
Trying to extend or improve an existing one would be more useful,
and actually a lot more challenging and educational.
Or best, as suggested, actually write some useful and needed applications.
Here is one of my MANY suggestions for needed public domain Lisp code:
write a GZIP utility in CL, that can compress/uncompress a stream
of bytes.
-Kelly Murray k...@franz.com
William Paul Vrotney
In article <63lkka$sje$1...@news2.franz.com> k...@franz.com (Kelly Murray)
writes:
>
> >>>>> Hrvoje Niksic <hni...@srce.hr> writes:
> >>>>> Hello all! My knowledge of LISP is practically zero, but I am very
> >>>>> interested in building a LISP interpreter for Windows. I heard that LISP
>
> > > If Syarzhuk or anyone has the desire to do this we should not discourage.
>
> > How about using one of the myriads of Lisp implementations and
> > write real Lisp applications?
>
> For sure.
> Yet another "toy" LISP implementation would not help the LISP community.
Yet another using the phrase, "toy lisp implementation" without giving
credit to small Lisp systems. Seems to me this kind of phasing could
discourage beginners from implementing their own Lisp interpreters. Who are
we to say that people desiring to do this are building a Lisp interpreter to
use seriously, to learn something or just as a "toy" to play with.
Furthermore many serious Lisp systems started out as a very simple
interpreter as described in this thread. And many of these systems did
indeed help the Lisp community and fueled new Lisp ideas. Was the first
Lisp interpreter a "toy" Lisp? Was MacLisp a "toy" lisp? Was the first
Scheme a "toy" Lisp? Was the first UCSD Lisp a "toy" Lisp? Was the first
Franz Lisp a "toy" Lisp? Was KCL a "toy" Lisp? Is CMUCL a "toy" Lisp?
Unfortunately, to some flamers from the C++ meme pool *any* Lisp is
expressed as a "toy".
> That's not to say one shouldn't do what one finds interesting,
>
Thanks.
> Trying to extend or improve an existing one would be more useful,
> and actually a lot more challenging and educational.
>
Strongly disagree! Improving an existing Lisp system for a beginner is
daunting to say the least. Why do think so many Lisp textbooks advocate
building a simple Lisp interpreter such as Winston/Horn "Lisp in Lisp" as
was cited in this thread? I believe that even Lisp experts, if they haven't
already, could benefit from taking the time to build their own small Lisp
system and experimenting.
> Or best, as suggested, actually write some useful and needed applications.
>
Please don't put down anyone developing their Lisp system as not doing
something useful or needed.
> Here is one of my MANY suggestions for needed public domain Lisp code:
> write a GZIP utility in CL, that can compress/uncompress a stream
> of bytes.
>
Thanks for the suggestion, but although you may not get no immediate benefit
from it, people building new Lisp systems are needed also.
> -Kelly Murray k...@franz.com
>
Someone at Franz should not feel threatened by new Lisp systems and ideas.
I would hope Franz's position on this would be to encourage not discourage
such activity.
Rainer Joswig
> Here is one of my MANY suggestions for needed public domain Lisp code:
> write a GZIP utility in CL, that can compress/uncompress a stream
> of bytes.
That would be handy.
Erik Naggum
* William Paul Vrotney
| Yet another using the phrase, "toy lisp implementation" without giving
| credit to small Lisp systems. Seems to me this kind of phasing could
| discourage beginners from implementing their own Lisp interpreters. Who
| are we to say that people desiring to do this are building a Lisp
| interpreter to use seriously, to learn something or just as a "toy" to
| play with.
I very much doubt that one can _learn_ to program in Lisp well (or at all)
by implementing a Lisp system from scratch with all the incredibly the
hairy stuff that one is supposed to remove from out of one's way in a
high-level language any more than you can learn to drive a car well in a
congested city by building a car by hand-tooling every nut and bolt.
| Furthermore many serious Lisp systems started out as a very simple
| interpreter as described in this thread. And many of these systems did
| indeed help the Lisp community and fueled new Lisp ideas. Was the first
| Lisp interpreter a "toy" Lisp? [etc]
I sincerely doubt that they were built by people who wanted to learn Lisp.
the evidence suggests that they were built by people who knew Lisp well,
even had major designs ready and a reason to build a new system that was
vastly different from starting out on the Lisp journey with ignorance of
the language as their biggest asset.
| Improving an existing Lisp system for a beginner is daunting to say the
| least.
so let's get past the "beginner" stage, then. frankly, I fail to see the
reason for the admiration you and many others display for beginners and
novices and ignorants. clearly, it's important to attract new people all
the time, but if we don't find ways to encourage people _beyond_ the
beginner stage, we're worse off than if we don't attract beginners at all,
because we're wasting energy on people who don't stay.
in my view, the catering to beginners and "dummies" in almost all areas of
computing has made the entire field look pathetically simple, and this
means that managers will believe the public impression of programming and
software as trivial tasks, which again means that smart people leave for
(greener) pastures without idiot managers. in a sense, I think this
fascination with _lack_ of expertise and experience is pathological: it
indicates a fear of either the process of learning or the result of
learning.
| Why do think so many Lisp textbooks advocate building a simple Lisp
| interpreter such as Winston/Horn "Lisp in Lisp" as was cited in this
| thread?
note that they do not suggest you go off to write a Lisp interpreter in C.
| Thanks for the suggestion, but although you may not get no immediate
| benefit from it, people building new Lisp systems are needed also.
sure, but people who want to _learn_ Lisp? I don't think so.
| Someone at Franz should not feel threatened by new Lisp systems and
| ideas.
geez! what's _wrong_ with you? why this incredibly cheap shot?
| I would hope Franz's position on this would be to encourage not
| discourage such activity.
_why_? if Franz, Inc, or any other Lisp vendor, has a position on this at
all, why would it or should it be that they want people to spend four to
ten years learning Lisp by hacking on their own Lisp interpreter when they
could learn it in three months to a year if they got their hands on a real
Lisp system?
even in journalism and at used car dealers, the least respected of all
trades according to some reports, they think experience is good. somehow,
they don't suggest that people start their own newspapers or dealerships to
"get experience", but encourage people to look at the results of other
successful operations. why is software so different?
one of the few things psychology theories seem to agree on is that people
need somebody to admire, look up to, some inspiration that others have, in
fact, managed what they would like to do, in some abstract or concrete
sense. so software people need somebody to admire, too, but what do you
get from visiting even good bookstores these days if not "they think any
random loser can learn to do my job in 21 days"?
my advice is to help people get _past_ the beginner stage and onto real
work. writing your own Lisp interpreter in anything other than a real Lisp
is to force people to deal with advanced (implementation) issues too early
as well as never getting them out of the _Lisp-beginner_ stage.
#\Erik
--
if you think this year is "97", _you_ are not "year 2000 compliant".
see http://sourcery.naggum.no/emacs/ for GNU Emacs 20-related material.
William Paul Vrotney
In article <63m9e0$n...@pasilla.bbnplanet.com> Barry Margolin
<bar...@bbnplanet.com> writes:
> In article <vrotneyE...@netcom.com>,
> William Paul Vrotney <vro...@netcom.com> wrote:
> >Strongly disagree! Improving an existing Lisp system for a beginner is
> >daunting to say the least. Why do think so many Lisp textbooks advocate
> >building a simple Lisp interpreter such as Winston/Horn "Lisp in Lisp" as
>
> It's intended as an academic exercise, not as a way to get a Lisp
> implementation useful for serious work.
Yes, that is why I also mentioned Allen's Anatomy of Lisp and referred to
working public domain Lisps for *after* he learned about basic Lisp
interpreters.
The original poster to this thread said that he was with practically zero
knowledge of Lisp. Winston/Horn Lisp might be a good place to start for
what he expressed that he is interested in. Even someone with an intent to
eventually do an interpreter for serious work has to start somewhere.
As an example, someone with practically zero knowledge of Lisp would be
daunted by taking CMUCL and trying to improve it.
Martin Rodgers
Rainer Joswig wheezed these wise words:
> Reinventing Lisp interpreters or
> reimplementing OOP systems won't help a bit. It's
> like intellectual masturbation. I have high respect for implementors
> of Lisp systems, but now it's about time to get more applications
> out of the door, since Lisp implementations are mature.
Should I give up on my Lisp to C++ compiler, then? I guess attempting
to integrate Lisp and C++/MFC is rather obscene, but one or two people
here _have_ advised me to write my own compiler.
While I'm not sure whather reinventing Lisp interpreters or
reimplementing OOP systems will help or not, it can still be a pretty
daunting task for a language the size of CL. Even a complete Scheme to
C++/MFC compiler could be challenging. (Consider structured exception
handling in the presence of continuations.)
A few years ago, I was happy to write my own compiler. Today, I'm more
interested in writing useful code. Integrating Lisps for Windows with
frameworks like MFC should be possible, but who has done it? I'm very
impressed by what the Python people have achieved in Pythonwin,
mapping MFC classes directly into Python classes. That could also be
done in Lisp, but some compromises would be needed. I've not yet found
a Lisp in which that compromise has been made.
As I said, this is a pretty obscene thing to do! I've only considered
it because of the utility that MFC provides, the huge amount of
support for MFC, and the many tools that use MFC. I'd love to use some
of these tools instead of reinventing them in Lisp.
Oh, there's one other reason for writing your own Lisp compiler. It's
a lot of fun! The first thing that excited me about Lisp was how easy
it was to write compilers for Lisp and Lisp-like variations of the
language. Some people call this meta-programming. However, I think we
now have enough Lisp _interpreters_. In my experience, even a simple
Lisp compiler can have great utility.
Please note that when I say "Lisp", I'm not refering to any specific
dialect. Once you start building on a Lisp, you're changing the
language anyway. This is what I think W&H were saying in their "Lisp
in Lisp" chapter - you can experiment very easily, and even create
your own languages. Some other Lisp books go a lot further, like SICP
and Lisp in Small Pieces.
Not that I'm the first to say any of this! I wouldn't be saying it at
all if I hadn't first read it in a book or posting to comp.lang.lisp
long before I began posting here myself. I'm still learning from the
masters, but this is what I _think_ they're saying.
Maybe a little "intellectual masturbation" can be a good thing? ;)
--
Please note: my email address is munged; You can never browse enough
"Oh knackers!" - Mark Radcliffe
Rainer Joswig
> Furthermore many serious Lisp systems started out as a very simple
> interpreter as described in this thread. And many of these systems did
> indeed help the Lisp community and fueled new Lisp ideas. Was the first
> Lisp interpreter a "toy" Lisp? Was MacLisp a "toy" lisp? Was the first
> Scheme a "toy" Lisp? Was the first UCSD Lisp a "toy" Lisp? Was the first
> Franz Lisp a "toy" Lisp? Was KCL a "toy" Lisp? Is CMUCL a "toy" Lisp?
Yeah, let's increase entropy.
> Strongly disagree! Improving an existing Lisp system for a beginner is
> daunting to say the least. Why do think so many Lisp textbooks advocate
> building a simple Lisp interpreter such as Winston/Horn "Lisp in Lisp" as
> was cited in this thread? I believe that even Lisp experts, if they haven't
> already, could benefit from taking the time to build their own small Lisp
> system and experimenting.
Get to learn writing real code (not you personal).
Reinventing Lisp interpreters or
reimplementing OOP systems won't help a bit. It's
like intellectual masturbation. I have high respect for implementors
of Lisp systems, but now it's about time to get more applications
out of the door, since Lisp implementations are mature.
William Paul Vrotney
In article <30876321...@naggum.no> Erik Naggum <cle...@naggum.no> writes:
>
> | Improving an existing Lisp system for a beginner is daunting to say the
> | least.
>
> so let's get past the "beginner" stage, then. frankly, I fail to see the
> reason for the admiration you and many others display for beginners and
> novices and ignorants. clearly, it's important to attract new people all
> the time, but if we don't find ways to encourage people _beyond_ the
> beginner stage, we're worse off than if we don't attract beginners at all,
> because we're wasting energy on people who don't stay.
>
Well your probably right, but I'm a sucker for anyone expressing an interest
in Lisp. I do hope some of the beginners stay and become experts. The
original poster to this thread for example is intrigued by an important
aspect of Lisp. Our best experts must have been beginners at some point and
possibly expressed similar intrigue.
>
> | Someone at Franz should not feel threatened by new Lisp systems and
> | ideas.
>
> geez! what's _wrong_ with you? why this incredibly cheap shot?
>
Sorry if it sounded that way.
> | I would hope Franz's position on this would be to encourage not
> | discourage such activity.
>
> _why_? if Franz, Inc, or any other Lisp vendor, has a position on this at
> all, why would it or should it be that they want people to spend four to
> ten years learning Lisp by hacking on their own Lisp interpreter when they
> could learn it in three months to a year if they got their hands on a real
> Lisp system?
>
The activity that I mentioned was not building a Lisp interpreter to learn
Lisp per se but to learn about Lisp system architectures. My hope is that
some of the people who do this will become some of the next generation Lisp
genius' who will move the science forward. If Lisp moves forward Lisp
vendors should benefit and hence I think they would support this kind of
activity.
Hrvoje Niksic
vro...@netcom.com (William Paul Vrotney) writes:
> > > Do *not* worry about efficiency issues, that will come later.
> > > Using this bootstrapping technique you can build up your Lisp
> > > system later to include a compiler and other efficiency and
> > > convenience forms and functions.
> >
> > Can you defend this position?
>
> Sure. For example many Common Lisps implemented simple one dim
> arrays as a primitive atom and then implement struct and class
> objects using those primitive arrays.
This works well only if noone but you uses your code during this
development. But if they do, and you are not *very* careful and wise,
problems are sure to crop up.
> Well, the Emacs byte-compiler generates code that is still
> interpreted, much like Java.
This is not only about byte-compiler, but about other issues, too.
Are you aware of all the controversy that has arisen from the single
point of making keymaps an opaque object in Lemacs? And that's only
keymaps! Try to consider "serious" stuff, like lexical scope and
structures, and suddenly you get a different and incompatible Emacs,
which frightens more people than it attracts.
My point is, when you have to maintain compatibility with the legacy
code, the bootstrapping technique has big problems.
> However, I have to say that taking all into consideration Emacs does
> pretty darn well. Frankly most of my entirely C coded word
> processors feel like they are as slow or slower on many operations
> (eg. spelling checking, search and replace, finds) than Emacs on
> similar operations. They are certainly clunkier than Emacs. When
> you say that Emacs is slow could you point to something more
> specific?
I meant not Emacs as an editor/word-processor, but Emacs Lisp as a
language. Try timing Lisp code in Elisp and in "real" Lisps, and the
speed difference should become apparent.
The cardinal sin of Emacs Lisp are the incredibly slow funcalls. It
makes recursion slow (a major sin in a Lisp implementation!). During
the XEmacs development, there have been many instances of rewriting
code that could rightfully be in Lisp to C, for the sole reason of
slow funcalls.
Then, it uses dynamical scoping, which makes LET incredibly slow -- it
is implemented by giving the symbol in the global obarray a value, and
using an internal unwind-form to return the old value.
There are no structures in Emacs Lisp, nor is there a sane, Lisp-level
type system (the XEmacs folks worked a lot on the internal type
system, but it is an implementation detail, invisible from Lisp.) It
is extremely hard to add these things afterwards, without breaking too
much.
> > What I would like to know is specifically, how do you envision the
> > right path for bootstrapping a small, garden-variety Lisp into a
> > serious Lisp environment?
>
> 1. Build a small primitive interpreter as was discussed previously and
> outlined in many books on Lisp.
>
> 2. Add new functionality by either adding new primitives or new
> functions written in your primitive interpreter language. Each new
> interpreter generation is more robust.
>
> 3. When your interpreter generation is robust enough, write a
> compiler in that interpreter language. You are allowed to borrow
> from public domain Lisp compilers.
>
> 4. Using the compiler in (3.) go back and compile your current
> generation interpreter and compiler.
>
> 5. Continue in this loop building more powerful interpreter and
> compiler generations. You can accelerate this into a more serious
> Lisp environment by stealing public domain higher level functions
> and algorithms as was pointed out earlier.
As I said before, this is fine unless thousands of people are writing
their code on your implementation during steps 2-5 -- as was the case
with Emacs.
> CMUCL is an interesting technology to study here as an example of
> intermediate virtual machine representation that gets translated
> into native code. GCL is also quite ingenious in that it compiles
> to C code. You can download and study these and others.
I know. I dislike CMUCL because it seems quite unstable on the
systems I use.
--
Hrvoje Niksic <hni...@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Speak softly and carry a +6 two-handed sword.
Martin Rodgers
Hrvoje Niksic wheezed these wise words:
> My point is, when you have to maintain compatibility with the legacy
> code, the bootstrapping technique has big problems.
I agree that this could create problems!
Isn't this the reason why bootstrapping compilers mainly get used for
bootstrapping, and little else? Or are there people who try to use
these rather specialised compilers on legacy code? I hope not.
Years ago, I used Cambridge Lisp, which had an interpreter and a
compiler. Unfotunately, the compiler used lexical scoping while the
interpreter used dynamic scoping. While this wasn't a bootstrapping
problem, I've sometimes wondered if Cambridge Lisp started life as an
interpreter only, and when the compiler was addded it was decided to
use lexical scoping to improve the performnce, regardless of the lack
of compatibility with the interpreter in the same system.
If this wasn't a case of bootstrapping gone wrong (keeping the
bootstrapping interpreter around after the compiler was working), then
perhaps it was just a result of using Standard Lisp. Ideally, the same
language would be used for both the bootstrap and the result. This
could be achieved by rewriting the "bootstrap" using the the compiler
that you've just bootstrapped.
Alternately, create your Lisp system by starting with a working - and
compatible - Lisp? I guess that would work. You could still have meta-
compiler difficulties, but CL has things like EVAL-WHEN to deal with
them.
Any beginners reading this shouldn't worry! As has been pointed out,
this isn't the kind of thing that a beginner should do. Learn the
language first, and only worry about this stuff when it becomes
relevant to you, if it ever does. I get the impression that Lisp books
explain the internals of Lisp in order to resolve some deep questions
about how Lisp works. This may eventually become relevant, as it could
in any language that can modify and extend itself, but certainly not
until some more immediate questions have been dealt with.
If Syarzhuk Kazachehnka really is interested in implementing Lisp,
then a good tutorial and some practical hands on experience with an
existing Lisp will be of more value that any reference document
defining Lisp behaviour. A deep understanding of Lisp should follow a
shallow ("practically zero") understanding, not the other way around!
Will Hartung
vro...@netcom.com (William Paul Vrotney) writes:
>In article <63lkka$sje$1...@news2.franz.com> k...@franz.com (Kelly Murray)
>writes:
>> For sure.
>> Yet another "toy" LISP implementation would not help the LISP community.
>Yet another using the phrase, "toy lisp implementation" without giving
>credit to small Lisp systems. Seems to me this kind of phasing could
>discourage beginners from implementing their own Lisp interpreters. Who are
>we to say that people desiring to do this are building a Lisp interpreter to
>use seriously, to learn something or just as a "toy" to play with.
>Furthermore many serious Lisp systems started out as a very simple
>interpreter as described in this thread. And many of these systems did
>indeed help the Lisp community and fueled new Lisp ideas. Was the first
>Lisp interpreter a "toy" Lisp? Was MacLisp a "toy" lisp? Was the first
>Scheme a "toy" Lisp? Was the first UCSD Lisp a "toy" Lisp? Was the first
>Franz Lisp a "toy" Lisp? Was KCL a "toy" Lisp? Is CMUCL a "toy" Lisp?
>Unfortunately, to some flamers from the C++ meme pool *any* Lisp is
>expressed as a "toy".
Every Lisp system was bootstrapped from something, and I imagine
that every Lisp system started, effectively, as a "toy". A toy
designed to learn and expand Lisp systems, until eventually the
orginal clay the toy was crafted in became to hard to mold to the
developers new image, at which point (probably using the current
implentation), the system was thrown out and written anew, with all of
the learning and experience from the previous implementations buried
into the new system. I thinks its safe to say that this process
afflicts most software projects.
If someone feels they can benefit from reimplementing the wheel by
crafting a new Lisp system, then feel free. If that is their goal,
even better.
But what I think is clear is that writing a Lisp system is a
non-trivial project. But, it doesn't SOUND like a non-trivial project.
It sounds easy: couple of base functions, and then write the rest in
Lisp itself. Simple. What's to know?
How long has XLISP been out, and evolving, in the world? It's probably
the most successful "toy" lisp, but it's had a good head start. How
many total man hours have been put into it?
Kelly is advocating that he'd like to see more applications in CL than
implementations of CL. He'd like to see a fraction of the energy folks
seem to have for implementing the language (usually as an exercise in
system programming rather than an excercise in Lisp programming), into
writing some more "mainstream" utilities and applications.
I would hope that if this person wants to want to write a Lisp system,
that rather than using Pascal and making an exercise of using Pascal,
he'd write it in and learn Lisp from the get go, and become a better,
more enlightened Lisp programmer.
Besides, Lisp is a better language to do this in anyway :-).
>> Trying to extend or improve an existing one would be more useful,
>> and actually a lot more challenging and educational.
>>
>Strongly disagree! Improving an existing Lisp system for a beginner is
>daunting to say the least. Why do think so many Lisp textbooks advocate
>building a simple Lisp interpreter such as Winston/Horn "Lisp in Lisp" as
>was cited in this thread? I believe that even Lisp experts, if they haven't
>already, could benefit from taking the time to build their own small Lisp
>system and experimenting.
Yes, but who says that whipping up a Lisp system from scratch is easy
for a beginner? It's a siren on the rocks. It LOOKS easy, it really
does! What I'm afraid of is that here is another person who may want
to learn Lisp, but sees his entry into it through writing his own
system. He doesn't even sound like he knows the language! He's sounds
like he wants to LEARN the language through implementing it in ANOTHER
language! And I fear that the initial step will get him to something
that is "cool" and that "works" and where he will stop. It'll be a
grand exercise in systems implementation, and it will sorta work
(except for bignums, exceptions, macros, and structs along with the REST of
the language that folks throw out of their implementations) and then
he'll be gone. He won't look back at Lisp because he'll focus on the most
trivial parts of it just trying to get it to work.
I'd rather have another energetic Lisp programmer than another
implementation.
>> Or best, as suggested, actually write some useful and needed applications.
>>
>Please don't put down anyone developing their Lisp system as not doing
>something useful or needed.
From a personal point of view, this system will advance the writers
knowledge of many things computeristic. Absolutely, and all the power
to him. From a "Lisp Community" point of view, it'll be a "Been There,
Done That" for quite awhile. It will take this person a LONG TIME to
advance the art in any meaningful way, as the art is pretty advanced
already. That's why people would rather see applications and extensions
to current implementations which are good, solid foundations for
expansion, than another house of cards.
>> Here is one of my MANY suggestions for needed public domain Lisp code:
>> write a GZIP utility in CL, that can compress/uncompress a stream
>> of bytes.
>>
>Thanks for the suggestion, but although you may not get no immediate benefit
>from it, people building new Lisp systems are needed also.
There is a system, Eclipse?, that is newly announced by a guy here.
His company went and re-did a new system from scratch (or with the
help of one of the releases on the net). It comes from a company that
is NOT a computer company. It seems clear to me that this company had
need for a Lisp system (specifically one that interfaced very well
with 'C') badly enough to take on the task of writing it from the get
go. And now they are selling it. I have to wonder how long it took
them to construct this system.
I haven't heard of anyone who has used the system yet, but it seems to
fill a hole in the Lisp spectrum of interopability with conventional
environments.
So, yes, technically there is a need for more people to building
foundations for Lisp systems, but I still think there is more of a need
for applications and utilities. As Lisp tries to expand out into the
world beyong mere AI, it would be nice to able to leverage off of all
of those tools and libraries one takes for granted in the Unix
community within the Lisp system itself.
>Someone at Franz should not feel threatened by new Lisp systems and ideas.
>I would hope Franz's position on this would be to encourage not discourage
>such activity.
Oh, he's not threatened, he just realizes like most other folks that
the money is in the apps, not the tools.
--
Will Hartung - Rancho Santa Margarita. It's a dry heat. vfr...@netcom.com
1990 VFR750 - VFR=Very Red "Ho, HaHa, Dodge, Parry, Spin, HA! THRUST!"
1993 Explorer - Cage? Hell, it's a prison. -D. Duck
Marco Antoniotti
mcr@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin Rodgers) writes:
>
> Rainer Joswig wheezed these wise words:
>
> > Reinventing Lisp interpreters or
> > reimplementing OOP systems won't help a bit. It's
> > like intellectual masturbation. I have high respect for implementors
> > of Lisp systems, but now it's about time to get more applications
> > out of the door, since Lisp implementations are mature.
>
> Should I give up on my Lisp to C++ compiler, then? I guess attempting
> to integrate Lisp and C++/MFC is rather obscene, but one or two people
> here _have_ advised me to write my own compiler.
No you shouldn't give up on it. What you should NOT do is to write a
Lisp which is neither Common Lisp nor Scheme (as a matter of fact,
IMHO, you should not write a Lisp system which is not a ANSI Common
Lisp).
As per new new applications, here is one. Let's write a JAR like
archiver.
--
Marco Antoniotti
==============================================================================
California Path Program - UC Berkeley
Richmond Field Station
tel. +1 - 510 - 231 9472
Barry Margolin
In article <MPG.ec94b29d...@news.demon.co.uk>,
Martin Rodgers <mcr@this_email_address_intentionally_left_crap_wildcard.demon.co.uk> wrote:
>Years ago, I used Cambridge Lisp, which had an interpreter and a
>compiler. Unfotunately, the compiler used lexical scoping while the
>interpreter used dynamic scoping. While this wasn't a bootstrapping
>problem, I've sometimes wondered if Cambridge Lisp started life as an
>interpreter only, and when the compiler was addded it was decided to
>use lexical scoping to improve the performnce, regardless of the lack
>of compatibility with the interpreter in the same system.
This was the same approach used in Maclisp. My impression is that it was
done this way because dynamic scoping is a simpler way to implement
interpreters, it simplifies explaining the language (a LAMBDA binding can
be explained as "it saves away the old value, assigns the variable, and
restores the value when the function returns"), and performance isn't
generally an issue when interpreting; lexical scoping in an interpreter
requires indirecting through environment objects. However, a compiler can
perform the necessary analysis to translate lexical references into fast
stack references. Since Maclisp didn't have lexical closures, none of the
complexity required for Scheme and Common Lisp variables was necessary;
variable references in the Maclisp compiler worked very much like in any
other lexically-scoped language (e.g. Algol).
The Maclisp compiler then introduced the "SPECIAL" declaration to indicate
variables that should be accessed and bound dynamically.
Bryant Brandon
[...]
>Furthermore many serious Lisp systems started out as a very simple
>interpreter as described in this thread. And many of these systems did
>indeed help the Lisp community and fueled new Lisp ideas. Was the first
>Lisp interpreter a "toy" Lisp? Was MacLisp a "toy" lisp? Was the first
>Scheme a "toy" Lisp? Was the first UCSD Lisp a "toy" Lisp? Was the first
>Franz Lisp a "toy" Lisp? Was KCL a "toy" Lisp? Is CMUCL a "toy" Lisp?
>Unfortunately, to some flamers from the C++ meme pool *any* Lisp is
>expressed as a "toy".
This is funny. I'm building my own "toy" lisp. It's core is
implimented entirely in C++. I'm finding the language quite inadiquate at
times. For example, it took two days to come up with a way to pass off a
valid reference to a member which happened to be a pointer. Not only
that, but C++'s "wonderful" standard library bloats the little critter up
quite a bit. So far, I've written what abounts to about 15k of code, but
the executable is over 200k and growing!
If anything, maybe I should be trying to impliment a "toy" C++ in
Lisp. But who wants that? (:
BTW, this Lisp (which I like to call Lithp) isn't a wimp. I plan to
use it for scripting my Mac--something that's a real bitch to do. Ever
try AppleScript? Now that's something worth calling a "toy"!
B.B. --I am not a goat!
Bryant Brandon
In article <MPG.ec91f4e1...@news.demon.co.uk>,
mcr@this_email_address_intentionally_left_crap_wildcard.demon.co.uk
(Martin Rodgers) wrote:
[...]
>Maybe a little "intellectual masturbation" can be a good thing? ;)
A wise man once told me, "Masturbation of any kind is never bad, even
in public." He has since been arrested, but that's beside the point.
>--
>Please note: my email address is munged; You can never browse enough
> "Oh knackers!" - Mark Radcliffe
B.B. --Going off on a tangent with a bullwhip in search of a dead horse.
John Arley Burns
Question: are some of the problems you mentioned alleviated by the
common lisp package (cl.el) in emacs?
Raymond Toy
Hrvoje Niksic <hni...@srce.hr> writes:
> vro...@netcom.com (William Paul Vrotney) writes:
[snip]
> > CMUCL is an interesting technology to study here as an example of
> > intermediate virtual machine representation that gets translated
> > into native code. GCL is also quite ingenious in that it compiles
> > to C code. You can download and study these and others.
>
> I know. I dislike CMUCL because it seems quite unstable on the
> systems I use.
Which systems would those be? What are the symptoms?
Ray
Marco Antoniotti
jos...@lavielle.com (Rainer Joswig) writes:
>
> In article <63lkka$sje$1...@news2.franz.com>, k...@franz.com wrote:
>
> > Here is one of my MANY suggestions for needed public domain Lisp code:
> > write a GZIP utility in CL, that can compress/uncompress a stream
> > of bytes.
>
> That would be handy.
>
As I said elsewhere, A JAR like utility would seem nowadays even more
appealing.
Bill Birch
bambo...@hotmail.com wrote:
>
> Hello all! My knowledge of LISP is practically zero, but I am very
> interested in building a LISP interpreter for Windows. I heard that LISP
> where can I get the description of that core and the sources/definitions
> for the rest of the language? I need exact URLs, please. Currently i
> plan to use Delphi for the core implementation but might change my mind
> on the way. All results (if any) would be posted as public domain. Would
> someone be interested in helping me with that?
>
> Sincerely,
>
> Syarzhuk Kazachehnka
>
> bambo...@hotmail.com
>
So far no-one has asked you why do you want to write a LISP interpreter?
LISP comes in many shapes and sizes according to the goals of the
creators. I wrote my own interpreter, for reasons of my own. One thing I
can say is that unless you are very clear on the goals of your project
at the start, it is very easy to get lost in LISP, and in the arguments
about LISP. This is because there are so many flavours of LISP around
and so many opinions about what it is for. LISP is a many splendoured
thing.
My own experience has been that writing my own tiny LISP interpreter has
been very rewarding indeed. Some experiences:
* One mistake I made was to be too ambitious, I added a lot of functions
for interesting things like MIDI, even if amazing. I should have stuck
to my goals. [I strongly doubt if a CLOS/Common LISP implementation is
within the reach of a single programmer. ]
* Having compatibiltiy with Common LISP is a boon, since you can rip off
loads of programs to run on the interpreter. This means you have access
to ready-made test cases!
* People on comp.lang.lisp are truly helpful and interested. They are
sooo good about the details.
Bill Birch
Hrvoje Niksic
John Arley Burns <abu...@earthling.mesas.com> writes:
> Question: are some of the problems you mentioned alleviated by the
> common lisp package (cl.el) in emacs?
As the interface goes, cl*.el package gives an Elisp programmers many
useful features, and *does* make life more bearable. In fact, the
XEmacs developers deemed the features so useful that they decided to
preload the package (except for the macros).
But it still uses the Emacs data structures, which means that in terms
of efficiency it buys you nothing -- on the contrary, it can probably
make things slower, if used carelessly. For instance, the cl.el
make-foo, where foo was derived from DEFSTRUCT, really returns a Lisp
vector, with the appropriate tags.
The type system, lexical scoping and loads of other stuff that cl.el
tries to at least touch, are impossible to implement without changing
the Emacs base.
Furthermore, Stallman has refused to preload CL with GNU Emacs, and
many people don't want to use the features in their packages, because
they are afraid of loading cl*.el.
--
Hrvoje Niksic <hni...@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
`VI' - An editor used by those heretics that don't subscribe to
the Emacs religion.
Marco Antoniotti
Hrvoje Niksic <hni...@srce.hr> writes:
>
> John Arley Burns <abu...@earthling.mesas.com> writes:
>
> > Question: are some of the problems you mentioned alleviated by the
> > common lisp package (cl.el) in emacs?
>
> The type system, lexical scoping and loads of other stuff that cl.el
> tries to at least touch, are impossible to implement without changing
> the Emacs base.
On the cmucl mailing list there were some suggestions to use Hemlock
as you editor of choice. You can't get more CL than that :)
> Furthermore, Stallman has refused to preload CL with GNU Emacs, and
> many people don't want to use the features in their packages, because
> they are afraid of loading cl*.el.
I did not know this, it'd be interesting to know what is RMS'
rationale. I believe it is a big mistake.
bambo...@hotmail.com
Thanks to everyone who replied to my original article. I was expecting a
storm of replies but not that big :) But all I got from your posts is: 1)
Total ANSI LISP cannot be implemented by one person. 2) LISP interpreters
should not be written at all since there is plenty of them. 3) Beginners
and "Dummies" should not even try to write a single line of code before
reading 10+ books on LISP (published in 1975-1985).
Now, what about IBM PC implementations? All I found on the Web was
PC-Scheme dated around 1987 (and someone told me not to even look at
Scheme because CL is much more powerful). The only Windows product seems
to be Franz's Allegro (my browser just died trying to download it so I
still haven't have a chance to look at it).
What about the question I had in my original post (about implementing
ANSI CL or at least its subset in terms of a small core)? At this point
performance does not matter - my point is that working public domain
Windows product would soon be enhanced by everyone who will work with it.
If such public domain implementation exists, could someone provide the
URL for it? If not, does it mean that each ANSI CL system should
implement all 1000+ operators?
Still undecided,
Syarzhuk Kazachehnka
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Dima Zinoviev
> What about the question I had in my original post (about implementing
> ANSI CL or at least its subset in terms of a small core)? At this point
> performance does not matter - my point is that working public domain
> Windows product would soon be enhanced by everyone who will work with it.
>
> If such public domain implementation exists, could someone provide the
> URL for it? If not, does it mean that each ANSI CL system should
> implement all 1000+ operators?
Try XLisp-Plus! It is not 100% ANSI CL-compatible, but very close to
it. It runs under UNIX, Amiga, Windows, Mac, plain DOS and a bunch of
other OS'es. You can fetch it from here:
http://www.teleport.com/~almy/xlisp.html
There is also a corresponding newsgroup (comp.lang.lisp.x) but it
seems to be dead rather than alive.
--
Keep talking! /~~~~~~~~~~~~~~~
Dmitry Zinoviev / /~~~~~~~~/
/ `~~~~~~~'
_From the Other Side of the World ____________/ Long Island, NY
Steven D. Majewski
In article <scf4t5s...@infiniti.PATH.Berkeley.EDU>,
Marco Antoniotti <mar...@infiniti.path.berkeley.edu> wrote:
>mcr@this_email_address_intentionally_left_crap_wildcard.demon.co.uk (Martin Rodgers) writes:
>
>
>No you shouldn't give up on it. What you should NOT do is to write a
>Lisp which is neither Common Lisp nor Scheme (as a matter of fact,
>IMHO, you should not write a Lisp system which is not a ANSI Common
>Lisp).
>
I disagree.
I'ld agree with Richard Gabriel that
Common Lisp is too much, and scheme is too little.
However, that doesn't mean you have to go out of your way to be
incompatible -- most of the more interesting recent attempts to
build a better lisp: Oaklisp, Dylan, RSheme have all mostly been
mostly scheme. ( RScheme is certainly a compatible superset. )
---| Steven D. Majewski (804-982-0831) <sd...@Virginia.EDU> |---
---| Department of Molecular Physiology and Biological Physics |---
---| University of Virginia Health Sciences Center |---
---| P.O. Box 10011 Charlottesville, VA 22906-0011 |---
All power corrupts and obsolete power corrupts obsoletely." - Ted Nelson
Martin Rodgers
Barry Margolin wheezed these wise words:
> The Maclisp compiler then introduced the "SPECIAL" declaration to indicate
> variables that should be accessed and bound dynamically.
This is the significant feature that Cambridge Lisp lacked. I found it
very confusing, developing code using dynamic scoping and then
compiling it with lexical scoping.
I could redefine a Standard Lisp function like APPEND as a macro, and
this worked in the interpreter, but the compiler insisted on using the
standard meaning. I was trying to make make Cambridge Lisp look more
like Common Lisp, so I wanted an APPEND that took a variable number of
arguments, instead of a fixed number, in this case two.
I think I made it work by defining functions using a macro that
replaced calls to APPEND with calls to MY-APPEND, a function which
behaved just Common Lisp's APPEND. Perhaps I could've written a more
powerful macro that compiled CL code into Standard Lisp, but I didn't
go that far. A few trivial changes to the language and the syntax used
by the parser were enough for me.
William Paul Vrotney
In article <8787734...@dejanews.com> bambo...@hotmail.com writes:
>
> Thanks to everyone who replied to my original article. I was expecting a
> storm of replies but not that big :) But all I got from your posts is: 1)
> Total ANSI LISP cannot be implemented by one person. 2) LISP interpreters
> should not be written at all since there is plenty of them. 3) Beginners
> and "Dummies" should not even try to write a single line of code before
> reading 10+ books on LISP (published in 1975-1985).
>
You certainly didn't get any of this from my post. Part of the problem is
that some of us did not understand your motivations.
> Now, what about IBM PC implementations? All I found on the Web was
> PC-Scheme dated around 1987 (and someone told me not to even look at
> Scheme because CL is much more powerful). The only Windows product seems
> to be Franz's Allegro (my browser just died trying to download it so I
> still haven't have a chance to look at it).
>
Franz Allegro if an when you could down-load it is highly recommended.
One earlier version of Allegro that I used on a friend's Windows was very
slow outputting characters to a window, so much so that debugging was
impractical. I don't know if this is an inherent Windows problem or
something was installed wrong or that Franz has fixed this in later
versions.
> What about the question I had in my original post (about implementing
> ANSI CL or at least its subset in terms of a small core)? At this point
> performance does not matter - my point is that working public domain
> Windows product would soon be enhanced by everyone who will work with it.
>
If this is your motivation then I too would recommend a Common Lisp dialect.
Aside from the "enhanced by everyone" I believe this was Franz's motivation
also when they put the free Allegro version on the net.
> If such public domain implementation exists, could someone provide the
> URL for it? If not, does it mean that each ANSI CL system should
> implement all 1000+ operators?
>
Does anyone have any experience trying to get CMUCL or else GCL to compile
under Windows?
Will Hartung
bambo...@hotmail.com writes:
>Thanks to everyone who replied to my original article. I was expecting a
>storm of replies but not that big :) But all I got from your posts is:
>1) Total ANSI LISP cannot be implemented by one person.
It would be an awful lot of work, but if you happen to be stuck on a
desert island, with computer and a paper copy of the Lisp Hyper Spec
for several years, then go ahead and knock yourself out.
>2) LISP interpreters should not be written at all since there is
> plenty of them.
That wasn't so much the point being made as:
Time invested in Lisp code would better be spent on applications
and tools.
>3) Beginners and "Dummies" should not even try to write a single line
> of code before reading 10+ books on LISP (published in 1975-1985).
No, it sounds like you bumped into Erik in a dark alley. He gets kind
of grumpy some times.
If you bought the 4-5 books published in the last 5 years (1992+)
you'll be neck deep in great information. However, you really only
need one book to start.
>Now, what about IBM PC implementations? All I found on the Web was
>PC-Scheme dated around 1987 (and someone told me not to even look at
>Scheme because CL is much more powerful). The only Windows product seems
>to be Franz's Allegro (my browser just died trying to download it so I
>still haven't have a chance to look at it).
Franz's ACL-Lite is probably the best of the "freely downloadable"
Lisps for Windows. DrScheme is supposed to be a nice Scheme. The more
complete Lisps are on Unix.
>What about the question I had in my original post (about implementing
>ANSI CL or at least its subset in terms of a small core)? At this point
>performance does not matter - my point is that working public domain
>Windows product would soon be enhanced by everyone who will work with it.
The trick with that plan is getting "everyone" TO work with it.
Private, spare time research/coding seems to be focused mostly on
(dare I say it) tools and applications for the Lisp environment. Lots
of interest in making more sophisticated application servers and
environments. Lots of interest in tools that could be migrated and
integrated into a future OS based on Lisp, but are useful stand alone
in current images. The folks working on these tasks are either using
the mature PD implementations, or commercial implementations.
Just like GCC has pretty much destroyed the "PD C-Compiler" market (I
don't see a lot of folks trying to whip up their own C compiler, but,
admittedly, I don't look either), the dominant UNIX Lisps have most of
the brainshare in the PD Lisp market, though few run on Windows
because W95 is so brain damaged, and there hasn't been the push to NT.
Those PD Lisps that are being actively worked on are in the "fine
tuning" phase, trying to nail down stability, performance,
functionality, CLOS, and, perhaps, portability.
>If such public domain implementation exists, could someone provide the
>URL for it? If not, does it mean that each ANSI CL system should
>implement all 1000+ operators?
The trick that some folks don't realize is that those 1000+ operators
are a fusion of a relatively simple language with a large library. The
simplicity of the language is the "bait" for implementors, the 1000+
operators is the "switch". Imagine writing a C compiler, without the
pre-processor, and without an ANSI standard library. You can leave out a
"select few" of the 1000+ operators in Lisp, but which ones and how do
you choose? CL is not a nicely stacked set of operations layered on
top of each other, but tends to be a web of interdependencies. Lisp
was not "designed", it evolved. Only later was it actually documented.
Note, you do not need to know all 1000+ operators to code in Lisp and
write amazing creations, but everyone who does write Lisp code uses
their own subset of those 1000+ operators. While there is a lot of
overlap, there is a lot of difference. Hence why folks want all 1000+
operators.
Scheme was "designed" and has folks standing guard around the spec
with sharps knives and Dobermans. I think there is a weight limit on
the spec of only 1 pound. The Scheme spec is what many can consider
"Core" for a Lisp-esque system, but extremely extensible.
>Still undecided,
Go read the Lisp FAQ and take a look at the different implementations.
Go look at the Scheme Repository and look at the different Scheme
implementations, there is a wide variance there. All of them bend the
state of the art in some way.
Hunt down the LispOS archives and see what interests a LOT of folks
about where they want Lisp to go.
If you really really really want to write a Lisp system for Windows,
then start from scratch and implement one as an ActiveX Server/Client
that can easily interface to other ActiveX Servers/Clients. If you
write a slow (but not too slow, and no siezing up for GC), minimal
interpreter that has those interfaces, can be used as an extensible
scripting language, and create standalone .DLLs, Martin will move in
with you and marry your sister.
Rainer Joswig
bambo...@hotmail.com wrote:
> Thanks to everyone who replied to my original article. I was
> expecting a
> storm of replies but not that big :) But all I got from your posts is:
> 1)
> Total ANSI LISP cannot be implemented by one person.
It would cost you some years of your life.
> 2) LISP interpreters
> should not be written at all since there is plenty of them.
If you just want to waste your time, go ahead. If you are still
interested, go ahead.If you want to learn something about writing
interpreters, go ahead.
If you think you can do a better job, go ahead.
> 3) Beginners
> and "Dummies" should not even try to write a single line of code
> before
> reading 10+ books on LISP (published in 1975-1985).
No. There are some new books you should read first (for Lisp
implementationread something like "Lisp in small Pieces" published
recently).
> Now, what about IBM PC implementations? All I found on the Web was
> PC-Scheme dated around 1987 (and someone told me not to even look at
> Scheme because CL is much more powerful). The only Windows product
> seems
> to be Franz's Allegro (my browser just died trying to download it so I
>
> still haven't have a chance to look at it).
>
Read the FAQ. There are plenty Lisps for Windows. Currently one of the
best (IMHO)commercial implementations is LispWorks for Windows.
> What about the question I had in my original post (about implementing
> ANSI CL or at least its subset in terms of a small core)?
Already identifying the subset is a lot of work.
> At this point
> performance does not matter - my point is that working public domain
> Windows product would soon be enhanced by everyone who will work with
> it.
On a Mac somebody has done this (PowerLisp). You should ask the
implementorabout his experience in doing so. It was a lot of work for
him. At one
point he was interested on the PC. I don't know what the state of that
is.I guess, there is no good free CL with source code for
Windows.Shouldn't there be a version of CLISP? I guess CLISP would
be worth to look for. Again, read the FAQ and follow the pointers.
On Unix you have plenty of them (GCL, CMUCL, ECL, WCL, CLISP, ...).
> does it mean that each ANSI CL system should
> implement all 1000+ operators?
ANSI CL implementations need to. But sure you can identify some
subsets(like CL without dynamic features, CL without CLOS, ...). Some
people followed
this route (the "L" system from ISR, CL0 for CLICC, ...).
EuLisp is also worth to look at. It is a cleaner Lisp dialect. It has a
layered architecture.
Scheme is small enough to be used for experiments.
Marc Wachowitz
vfr...@netcom.com (Will Hartung) wrote:
[to a beginner wanting to implement Lisp for the educational experience]
> You can leave out a
> "select few" of the 1000+ operators in Lisp, but which ones and how do
> you choose?
If you want to stay roughly similar to Common Lisp, but the latter exceeds
your capacity, another alternative would be ISLisp (standardized by ISO).
For the language specification, go to
ftp://ftp.harlequin.co.uk/pub/kmp/iso/v20/
It has roughly the same "size" as Scheme, but it's object oriented, and
the functionality is somewhat more oriented towards things which most
programmers might want in practice, rather than theoretical elegance
as for Scheme (e.g. various forms of non-local exit vs. Scheme's general
continuations) - though some seasoned Common Lisp programmers will also
surely miss quite a lot in both Lisp dialects (let's not start a flame
war about that, please).
As it happens, I'm about to use an extension of ISLisp for a modular
Lisp, compiled to C, which can cooperate with (or be plugged into)
different kinds of environments, to be used as shell-style scripting
language, as extension language for programs written e.g. in C, or for
complete stand-alone applications in Lisp. I'm going to post my ideas
about a static module system, and its interaction with macros, probably
during the next few days. (Desipite the title of this thread, I'm doing
this on Unix, though.)
-- Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de>
Steven D. Majewski
In article <8787734...@dejanews.com>, <bambo...@hotmail.com> wrote:
>Thanks to everyone who replied to my original article. I was expecting a
>storm of replies but not that big :) But all I got from your posts is: 1)
>should not be written at all since there is plenty of them. 3) Beginners
>and "Dummies" should not even try to write a single line of code before
>reading 10+ books on LISP (published in 1975-1985).
You're taking the cumulative sum of all of the advice.
You might be better off with the average. ;-)
[ Also scheme may be better than common lisp for some applications.
Common Lisp has CLOS and a big library of functions which can be
a big help, but if you're just learning, scheme is simpler. ]
David Thornley
In article <34617AA4...@lavielle.com>,
Rainer Joswig <jos...@lavielle.com> wrote:
>bambo...@hotmail.com wrote:
>
>> At this point
>> performance does not matter - my point is that working public domain
>> Windows product would soon be enhanced by everyone who will work with
>> it.
>
>On a Mac somebody has done this (PowerLisp). You should ask the
>implementorabout his experience in doing so. It was a lot of work for
>him. At one
>point he was interested on the PC. I don't know what the state of that
>is.I guess, there is no good free CL with source code for
>Windows.Shouldn't there be a version of CLISP? I guess CLISP would
>be worth to look for. Again, read the FAQ and follow the pointers.
>On Unix you have plenty of them (GCL, CMUCL, ECL, WCL, CLISP, ...).
>
Windows. Windows support seems to come only with commercial
products. I suspect it is seen as too much work for the hack
value. If you want to build a freely-available Lisp system on
Windows, don't let us stop you, but I'd advise looking at the current
versions that are freely available and include source code.
Then swipe (reuse?) as much of that source as you can. Life's too
short as it is.
>
Further, it's arguable that another Windows CL or Scheme implementation
wouldn't be as useful as an implementation of something different.
--
David H. Thornley | These opinions are mine. I
da...@thornley.net | do give them freely to those
http://www.thornley.net/~thornley/david/ | who run too slowly.
Adam P. Jenkins
Marco Antoniotti <mar...@infiniti.path.berkeley.edu> writes:
> Hrvoje Niksic <hni...@srce.hr> writes:
> > Furthermore, Stallman has refused to preload CL with GNU Emacs, and
> > many people don't want to use the features in their packages, because
> > they are afraid of loading cl*.el.
>
> I did not know this, it'd be interesting to know what is RMS'
> rationale. I believe it is a big mistake.
Maybe it's because loading up cl*.el adds at least another meg to the
running size of emacs. Here at work where all the machines have at
least 64 megs, who cares. But considering that one of the biggest
complaints about emacs is its memory usage, I'd guess this is why he
didn't want to load cl by default.
Adam
--
Adam P. Jenkins Office Phone: (413) 545-3059
mailto:ajen...@cs.umass.edu
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQBNAzBt18UAAAECALmLVRW6EP59OrypUB4uT6ADRYGB3FfyW1wACf40cvdTfOUy
QHhM8Oy4aMWZ5RNYeY5qTkCRnvtsfGSsLRxEmN0ABRG0KUFkYW0gUC4gSmVua2lu
cyA8YXBqQHR3YWluLm9pdC51bWFzcy5lZHU+
=yzSE
-----END PGP PUBLIC KEY BLOCK-----
Martin Rodgers
Will Hartung wheezed these wise words:
> If you
> write a slow (but not too slow, and no siezing up for GC), minimal
> interpreter that has those interfaces, can be used as an extensible
> scripting language, and create standalone .DLLs, Martin will move in
> with you and marry your sister.
Stranger things have happened. ;)
Until then, I'm pursuing a number of alternatives, awaiting various
others, and giving encouragement where I can. This is one of those
times; I agree with you about not being too ambitious, like going for
a full CL. Something small, but complete enough to do real work, will
be gratefully received. Since this has been done for other languages
(e.g. Prolog, Smalltalk), I'm sure it could also be done for Lisp.
The bottom line is: make it work. Then - and only then - worry about
how to build something really ambitious, like a full CL. Start with
sone of the already avaiable Lisp systems and see what they can do.
Maybe what you want already exists. If not, then at least you'll have
some idea of where to go next.
In 1994, I discovered how easy it can be to write a simple Lisp
compiler (for an extreme subset of Scheme), but I also learned a lot
about how hard writing a more complete compiler would be. It's not
impossible to go further, and the results I got a few years ago showed
me that it is possible to use Lisp to write programs that run with
very small overheads. Almost no overheads at all, relative to C!
If you get hold of a compiler like Stalin or Bigloo, you can see for
yourself. Just don't start by writing a Lisp compiler! I had the
advantage of using Lisp for about 9 years, and thinking about how to
write a Lisp compiler for 5+ years. Plus reading a number of books
that explained how to do it!
Still, if I hadn't discovered Scheme then I'd never have seriously
considered it. Even a "small" compiler for Common Lisp is an entirely
different proposition. When I first thought about compiling Lisp, I
was only familiar with MacLisp (from W&H 1st ed), and I didn't want to
write a full compiler for _that_, either. However, it was realising
that a compiler for a subset could be useful that excited me. At the
time, I was heavily interested in compilers and esp parsers, so the
idea of writing a parser in Lisp, testing it, and then compiling it to
C or asm strongly appealed to me.
Today, I'm still writing parsers, but now they're mainly for reading
documents instead of programs. The principles are the same, and Lisp
is just as applicable as it looked to me in 1985. More so, in fact.
I can now parse files in Lisp, using parser and networking utilities
written in C and in Windows DLLs. This is how I link check my
homepage. I should add indexing of the meta tags next, plus more
complete HTML validation. The same C code can be reused in other
programs - anything that parses text or reads files from a web server.
Since most of the work is being done by a few very short C functions,
I could probably have used a Lisp interpreter, instead of a compiled
Lisp. Someday I might try that...
Erik Naggum
* bambo...@hotmail.com
| Thanks to everyone who replied to my original article. I was expecting a
| storm of replies but not that big :) But all I got from your posts is: 1)
| Total ANSI LISP cannot be implemented by one person. 2) LISP interpreters
| should not be written at all since there is plenty of them. 3) Beginners
| and "Dummies" should not even try to write a single line of code before
| reading 10+ books on LISP (published in 1975-1985).
(1) and (2) appear reasonable, but I haven't seen anybody say or imply
anything that could even remotely support the highly unreasonable (3), so I
assume you are getting a tad defensive on behalf of beginners and dummies.
(BTW, I would _never_ buy anything marketed to "dummies" even if I were all
new to a field. people who buy such books obviously think of themselves in
terms I find much too self-deprecatory and self-debasing.)
in a reasonable society, experience and knowledge are respected, and those
who wish to take part in any activity enjoyed by others _expect_ to have to
learn what the others know to enjoy it fully, not just out of respect for
those others whose time and enjoyment they do not want to waste or destroy,
but out of a personal sense of esteem in mastering something and reaching a
level of _informed_ and _competent_ enjoyment.
in a sick society, experience and knowledge are frowned upon, arrogant
ignorance encouraged, and those who wish to take part in any activity
enjoyed by others _demand_ to be taken seriously when they know nothing and
are prepared to do nothing, complete with the right to accuse everybody who
knows more than them of being elitist and actively hostile to beginners.
I wonder what happened to the concepts of education, training, and gaining
experience before attempting advanced stunts.
| What about the question I had in my original post (about implementing
| ANSI CL or at least its subset in terms of a small core)? At this point
| performance does not matter - my point is that working public domain
| Windows product would soon be enhanced by everyone who will work with it.
I believe this point is contradicted by fact.
part of the reason, I believe, is that if you want to program in Lisp, it's
because you _don't_ want to take detours down to the basement every few
hours to fix some plumbing detail or adjust the electrical system or any of
the other stuff that C programmers and Linux hackers seem to enjoy spending
a lot of time on. some people actually fancy the notion that computers
should not crash on them but just _work_, and I believe there are more of
these people working in higher-level languages than in low-level languages
-- and not just Lisp, but anything other than C and C++ and their friends.
| If such public domain implementation exists, could someone provide the
| URL for it? If not, does it mean that each ANSI CL system should
| implement all 1000+ operators?
I'm not aware of any such public domain "library" of ANSI CL source, but I
wonder why you find this so strange. it's actually like this in every
other language, too, and operating system, and major application. in every
high-level language, any implementation will have to establish a number of
conventions and adhere strictly to them. conventions will not mix easily
with each other. you need look no further than the conventions surrounding
the passing and returning of aggregate objects (structs) in C: there are at
least three very different ways to utilize system resources like memory and
registers. different programming languages have traditionally implemented
function calling conventions differently: Fortran, Pascal, and C being the
three major ones. note that C _broke_ with the predominant convention of
its time in that it required the _caller_ to adjust the argument stack.
there's also a non-trivial interaction between types, functions and
optimizing compilation that makes an implementation of all the Common Lisp
functions on a "naive" substrate less useful than it appears to be. in C,
you would have just one function and it would get called to do its job. in
Common Lisp, a function in the standard is more the advertized interface of
functionality. the function named `car' must exist, but in all likelihood
it is compiled to a single instruction. an `aref' is probably inlined
similarly. for other functions, you can probably expect there to be
several different versions depending on the compilation switches you have
given. Common Lisp has the notion of "safe code", but if you request
unsafe code and high performance, you shouldn't still be using safe code in
the functions you call.
also, the number of external symbols in the COMMON-LISP package are dwarfed
by the number of symbols in a decent implementation of Common Lisp. e.g.,
in a full Allegro Common Lisp with Common Windows, CLIM 2.1, and the
Composer, there are almost 32,000 symbols in 45 packages, and 21,000
function objects in the image. in a compiler-only Allegro CL, there are
13,500 symbols in 24 packages and 6,000 function objects. somehow, I don't
think there's much benefit to having the 752 functions in the COMMON-LISP
package taken from a public domain source base.
it took me quite a while to realize that Common Lisp qua language is
_small_ compared to a serious implementation of it, and that this is also
true of most other serious languages and attendant environments. the
smaller the language, in fact, the more external (extralingual?) features
and facilities are needed. once this realization has sunk in, it becomes
even less likely that encouraging people who want to learn the language by
implementing it themselves _outside_ of an existing environment is a good
idea. as I said above: it's all the stuff the programmer _doesn't_ have to
do that gives Lisp its major appeal.
#\Erik
--
if you think this year is "97", _you_ are not "year 2000 compliant".
see http://sourcery.naggum.no/emacs/ for GNU Emacs 20-related material.
Rainer Joswig
Erik Naggum wrote:
> also, the number of external symbols in the COMMON-LISP package are
> dwarfed
> by the number of symbols in a decent implementation of Common Lisp.
> e.g.,
> in a full Allegro Common Lisp with Common Windows, CLIM 2.1, and the
> Composer, there are almost 32,000 symbols in 45 packages, and 21,000
This is not something that would me make that proud of CL. Developing
smallapps is either hard or not possible. Only LW and MCL make the
integrated
environment idea (never leave your Lisp) of Genera somewhat thinkable.
MCL PPC is 1.5 MB for the App + 3.5 MB for the shared libraries.
Including
a better (IMHO) dev environment (integrated Editor, gadgets, ...). 15662
symbols in 9 packages
with 7761 functions. Why are the Unix versions and the code they are
generating so big?
Btw., LWW+CLIM dev environment comes in with >69 packages, >47000
symbols, >22000 functions.
Part of the reason is that ACL has support for user interaction
through CLIM, Common Windows, (is there still CLM?), CLX, Emacs, ...
Which I would call ***bloated***. And then some people are loading
CLUE or Garnet or something which their company has developed inhouse.
A sane modern implementation of
Common Lisp there would be one UI toolkit. I guess the Composer
stuff could be easily rewritten in CLIM (includes CLX). Having a
develoment
environment in CLIM would speed up development tremendously (and would
help
to improve CLIM). O.k., they are now going the Windows route.
Still, you are right. There is a lot more to CL than just what is in the
spec.
It´s worth to be taught and to be learned.
Hrvoje Niksic
ajen...@cs.umass.edu (Adam P. Jenkins) writes:
> Marco Antoniotti <mar...@infiniti.path.berkeley.edu> writes:
> > Hrvoje Niksic <hni...@srce.hr> writes:
> > > Furthermore, Stallman has refused to preload CL with GNU Emacs, and
> > > many people don't want to use the features in their packages, because
> > > they are afraid of loading cl*.el.
> >
> > I did not know this, it'd be interesting to know what is RMS'
> > rationale. I believe it is a big mistake.
First he said that these functions are invading the standard
name-space (they are not prefixed with `cl-'). I argued that, if they
are documented (cl.texi merged into the normal Emacs manual), the
name-space will become standard. Then he said he didn't have time to
document them. I answered I was prepared to do the work. Stallman
then said he didn't want all those features introduced "as a lump."
Hard to argue against that last point, isn't it?
Incidentally, many other people were asking for these features at one
time or the other, some of them being Barry Warsav, Lars Ingebrigtsen
and Erik Naggum. Stallman refused with simmilar arguments, so I guess
that's it.
> Maybe it's because loading up cl*.el adds at least another meg to the
> running size of emacs.
This is a definite overstatement. Most of the size of cl-*.el is in
CL macros (cl-macs.el), which is not dumped -- the macros are expanded
at compile-time anyway. The functions in cl.el don't take up even
nearly as much space.
--
Hrvoje Niksic <hni...@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Contrary to popular belief, Unix is user friendly.
It just happens to be selective about who it makes friends with.
Marco Antoniotti
Hrvoje Niksic <hni...@srce.hr> writes:
>
> ajen...@cs.umass.edu (Adam P. Jenkins) writes:
>
> > Marco Antoniotti <mar...@infiniti.path.berkeley.edu> writes:
> > > I did not know this, it'd be interesting to know what is RMS'
> > > rationale. I believe it is a big mistake.
>
> First he said that these functions are invading the standard
> name-space (they are not prefixed with `cl-'). I argued that, if they
> are documented (cl.texi merged into the normal Emacs manual), the
> name-space will become standard. Then he said he didn't have time to
> document them. I answered I was prepared to do the work. Stallman
> then said he didn't want all those features introduced "as a lump."
>
> Hard to argue against that last point, isn't it?
>
> Incidentally, many other people were asking for these features at one
> time or the other, some of them being Barry Warsav, Lars Ingebrigtsen
> and Erik Naggum. Stallman refused with simmilar arguments, so I guess
> that's it.
I still think it is a big mistake. As an example, Emacs Lisp programs
tend to be cluttered by lots of (nth x l) just because the writer did
not have the time to write a bunch of accessor macros. Just using
'defstruct' would make many Elisp programs much more readable and
maintainable.
Martin Cracauer
bambo...@hotmail.com writes:
>The only Windows product seems
>to be Franz's Allegro (my browser just died trying to download it so I
>still haven't have a chance to look at it).
And you don't take this as an opportunity to switch to a real
operating system and use non-graphical tools like fetch or wget to
download (if one try is all you have, as it seems)? Sad.
>What about the question I had in my original post (about implementing
>ANSI CL or at least its subset in terms of a small core)? At this point
>performance does not matter - my point is that working public domain
>Windows product would soon be enhanced by everyone who will work with it.
Clisp has a nice Win32 port. In my experience Windows users usually
don't enhance free software as much as users of other OSes do. Even if
so, Clisp is just fine except that it isn't a native compilation
system. Switching Clisp to use a native compiler wouldn't be muss less
work than to port CMUCL, so I think you're too optimistic.
>If such public domain implementation exists, could someone provide the
>URL for it?
Read the FAQs for the newsgroups you post to.
>If not, does it mean that each ANSI CL system should
>implement all 1000+ operators?
This is a silly question, isn't it? If you want a system to be ANSI,
your obviously have to implement all of ANSI. If you don't need all of
ANSI and someone provides an ANSI subset implementation you're happy
with, go for it. What else should we tell you?
Implementing most of ANSI isn't really the point nowadays. What else
do you need for your work: GUI interface, database interface, threads
are the subsystems one usually chooses a Lisp implementation on.
Thanks for supporting my prejustice about Windows users.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin....@wavehh.hanse.de http://www.cons.org/cracauer/
BSD User Group Hamburg/Germany http://www.bsdhh.org/
Donald Fisk
Marc Wachowitz wrote:
> It has roughly the same "size" as Scheme, but it's object oriented,
PC Scheme (originally from Texas Instruments) was object-oriented.
It came with SCOOPS. I don't know if SCOOPS is an extension or
an integral part of Scheme.
Paging Richard O'Keefe!
> -- Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de>
--
Le Hibou (mo bheachd fhe/in: my own opinion)
"What the ... This is Lambic! Where's my culture of amoebic
dysentery?"
-- Gary Larson
Marc Wachowitz
Donald Fisk <donal...@bt-sys.bt.spamblock.co.uk> wrote:
> Marc Wachowitz wrote:
> > [ISLisp] has roughly the same "size" as Scheme, but it's object oriented,
> PC Scheme (originally from Texas Instruments) was object-oriented.
> It came with SCOOPS. I don't know if SCOOPS is an extension or
> an integral part of Scheme.
Perhaps SCOOPS has (or could have) been implemented on top of Scheme, or
it was just an extension, but standard Scheme isn't what nowadays tends
to be considered object-oriented. There are indeed several implementations
of Scheme with different extensions for object-oriented programming.
Of course, depending what exactly you expect as object-orientation, and
the kind of optimizations you want to be realistic, it's already possible
to build one's own object system(s) in Scheme - depending on whom you'll
ask, this is seen either as a curse or a blessing. I think I remember a
footnote from the second edition of "Structure and Interpretation of
Computer Programs" (by Abelson, Sussman & Sussman) that in their view
there still isn't a clean view how generic operations should look like
in the general case (opposed to plain hierarchies, like Scheme's numeric
tower), and that may well be one reason why standard Scheme yet doesn't
have an object system in the usual sense of the word. Traditionally, the
Scheme gurus are supposed never to take something into RnRS on which they
can't reach a consensus that it's really the one and only pure solution ;-)
(Btw, pondering some issues of macros and modules, I think I'll go back
to Scheme rather than ISLisp as a foundation for my Lisp compiler, since
the primitive symbol-oriented macro approach of ISLisp just isn't good
enough for my purposes, whereas Scheme's hygienic macros can be extended
to work well for my interests [I can hear someone's sigh of relief ...])
-- Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de>
Pierre Mai
>>>>> "DT" == David Thornley <thor...@visi.com> writes:
DT> You can run CLISP on MS-DOS with no difficulty, but it doesn't
DT> do Windows. Windows support seems to come only with
DT> commercial products. I suspect it is seen as too much work
DT> for the hack value. If you want to build a freely-available
DT> Lisp system on Windows, don't let us stop you, but I'd advise
DT> looking at the current versions that are freely available and
DT> include source code. Then swipe (reuse?) as much of that
DT> source as you can. Life's too short as it is.
A good starting-point for a Windowing _Scheme_ might be STk, an
extended scheme (simple OO-System) married to Tk. Since Tk has been
successfully ported to Windows (the 8.0 Versions are even getting
native), you are "only" left the job of porting the scheme part...
Indeed this might have already happened...
OTOH there are workable Scheme implementations for Win32 (MitScheme,
Dr. Scheme, ...) with foreign-function interfaces to the Win32-API.
And the simplest option of providing an existing Lisp system with a
GUI is using tcl/tk via pipes (on platforms that have tcl/tk and
pipes, that is ;).
Regs, Pierre.