Dear lisp programmer & emacs users,
Can one make emacs to interpret common lisp instead of elisp? and if
one can, can you point me the way?
Thank you very much.
Regards
John
Centuries ago, Nostradamus foresaw a time when John T. H. Wong would say:
>Dear lisp programmer & emacs users,
>
> Can one make emacs to interpret common lisp instead of elisp? and if
>
>one can, can you point me the way?
> Thank you very much.
I think Erik Naggum is supposed to have a project under way to this
end, and if you explore <http://www.xemacs.org>, you may find some
information on what sort of effort would be required to implement this.
It would not be a small change, and nobody has seen fit to do the
work yet.
--
Obversely, a lot of verbal mileage can also be gotten by sending out
incomprehensible, cryptic, confusing or unintelligible messages, and
then iteratively "correcting" the "mistaken interpretations" in the
replys.
-- from the Symbolics Guidelines for Sending Mail
········@ntlug.org - - <http://www.ntlug.org/~cbbrowne/lsf.html>
"John T. H. Wong" <·······@hkucs.org> writes:
> Dear lisp programmer & emacs users,
>
> Can one make emacs to interpret common lisp instead of elisp? and if
> one can, can you point me the way?
i too would prefer a common-lisp emacs. (both written in common-lisp
and using common-lisp as its exentension language.)
i hear that someone spliced guile/scheme to emacs. perhaps a similar
stunt could be performed with clisp? this would be a fair amount of
work.
the zero work convenient kludge is to put (require 'cl) in your
emacs-lisp code. this allows the use of many (but far from all)
common-lisp constructions. keep in mind that it is just a veneer.
it's still good old dynamically scoped emacs-lisp and not true
common-lisp.
--
johan kullstam l72t00052
From: Hartmann Schaffer
Subject: Re: Common Lisp interpretation by emacs
Date:
Message-ID: <38da9c1d@news.sentex.net>
In article <·············@res.raytheon.com>,
Johan Kullstam <········@ne.mediaone.net> writes:
> "John T. H. Wong" <·······@hkucs.org> writes:
>
>> Dear lisp programmer & emacs users,
>>
>> Can one make emacs to interpret common lisp instead of elisp? and if
>> one can, can you point me the way?
>
> i too would prefer a common-lisp emacs. (both written in common-lisp
> and using common-lisp as its exentension language.)
>
> i hear that someone spliced guile/scheme to emacs. perhaps a similar
> stunt could be performed with clisp? this would be a fair amount of
> work.
would hemlock (?, the cmucl editor) be a suitable starting point?
> ...
--
Hartmann Schaffer
From: Christopher R. Barry
Subject: Re: Common Lisp interpretation by emacs
Date:
Message-ID: <87pusl2olg.fsf@2xtreme.net>
··@inferno.nirvananet (Hartmann Schaffer) writes:
> In article <·············@res.raytheon.com>,
> Johan Kullstam <········@ne.mediaone.net> writes:
> > "John T. H. Wong" <·······@hkucs.org> writes:
> >
> >> Dear lisp programmer & emacs users,
> >>
> >> Can one make emacs to interpret common lisp instead of elisp? and if
> >> one can, can you point me the way?
> >
> > i too would prefer a common-lisp emacs. (both written in common-lisp
> > and using common-lisp as its exentension language.)
> >
> > i hear that someone spliced guile/scheme to emacs. perhaps a similar
> > stunt could be performed with clisp? this would be a fair amount of
> > work.
>
> would hemlock (?, the cmucl editor) be a suitable starting point?
Hemlock is much, much simpler than GNU/X Emacs. In my opinion you
could not start with that codebase and hack up something like our
Emacs.
Most people that complain that they want a CL-Emacs haven't really
said what they'd do with it or what applications they'd develop for it
that they won't make for our current Emacs. Yes, having Gnus be able
to poll multiple servers simultaneously would be nice. Is that all???
Okay, I'd rather use the Allegro CL debugger and development
environment for programming Emacs applications, but do I really,
*really* need it? No. Our current Emacs is a good enough I think, and
anyone not happy with it should examine what they think they *really*
need that it can't do, and just use their intelligence,
problem-solving skills, and patience to make do with what we have and
learn to be happy, content, and find peace of mind with it and with
Unix generally.
Christopher
······@2xtreme.net (Christopher R. Barry) writes:
> Most people that complain that they want a CL-Emacs haven't really
> said what they'd do with it or what applications they'd develop for it
> that they won't make for our current Emacs. Yes, having Gnus be able
> to poll multiple servers simultaneously would be nice. Is that all???
Threads.
Compilation to native code for speed.
The underlying lisp gets much better integration with Emacs.
(Nothing here says CL. It could *in priniciple* be done with Scheme or
Emacs Lisp.)
> Okay, I'd rather use the Allegro CL debugger and development
> environment for programming Emacs applications, but do I really,
> *really* need it?
Lots of people get by with vi, so what's your point?
On the other hand, in the absence of FFI standards, it would probably
end up tied to one particular CL. Integration with the C substrate
would have to be redone for each CL implementation. Native compilation
would allow migrating more of the C substrate to Lisp, but now it's
starting to sound more and more like starting from scratch :-)
Jon K�re
Sorry to intrude in this newsgroup on which i am just lurking but:
Jon K Hellan wrote:
> (Nothing here says CL. It could *in priniciple* be done with Scheme or
> Emacs Lisp.)
Talking about Scheme their were some modifications made to Emacs to use
Guile and another to use Kawa.
Being Lispers you may not be interested to much by it and maybe even see
it as a way for me to promot eScheme that I love (I have nothing against
CL, I just hadn't had the time to learn it (yet)) but I think this may
help people that are trying to integrate Common Lisp with Emacs to look
at some people that wanted to do the same with a rather similar
language.
There is: jemacs.sourceforge.net/ that uses Kawa
Personally I think that it would be cool to be ablt to choose between an
Emacs with CL and an Emacs with Scheme (and even the old one if you
really prefer ELisp) depending of particular tastes and the language you
are working for (say, for one project I may prefer to use Scheme and for
another I may prefer to use CL).
Good luck to anyone that try to do it.
Julien
From: Erik Naggum
Subject: Re: Common Lisp interpretation by emacs
Date:
Message-ID: <3162858618807593@naggum.no>
* Christopher R. Barry
| Most people that complain that they want a CL-Emacs haven't really
| said what they'd do with it or what applications they'd develop for it
| that they won't make for our current Emacs. Yes, having Gnus be able
| to poll multiple servers simultaneously would be nice. Is that all???
what I have wanted that can't be done in the current Emacs are:
1 an Emacs server that talks to several Emacs clients that don't interfere
(such as one process per X window/Emacs frame).
2 file-system server processes in user space which serve Emacs clients with
network-optimal fragments of files on remote and local hosts alike, such
that you can edit files with the native privileges of several users.
3 integration via foreign function interfaces to other code on the system.
(there is now an Emacs with some dynamic loading support.)
#:Erik
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
>* Christopher R. Barry
> what I have wanted that can't be done in the current Emacs are:
>
>1 an Emacs server that talks to several Emacs clients that don't interfere
> (such as one process per X window/Emacs frame).
>
>2 file-system server processes in user space which serve Emacs clients with
> network-optimal fragments of files on remote and local hosts alike, such
> that you can edit files with the native privileges of several users.
>
>3 integration via foreign function interfaces to other code on the system.
> (there is now an Emacs with some dynamic loading support.)
#1 and #2 don't seem to be related to the dialect of Lisp that Emacs
happens to be written in. #3 doesn't depend on ANSI CL, but just the fact
that most CL implementations also include foreign function interfaces; but
there's no good reason why a similar FFI couldn't be included in Emacs
Lisp.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Erik Naggum
Subject: Re: Common Lisp interpretation by emacs
Date:
Message-ID: <3162910141905443@naggum.no>
* Barry Margolin <······@bbnplanet.com>
| #1 and #2 don't seem to be related to the dialect of Lisp that Emacs
| happens to be written in.
I prefixed what I wrote with "what I have wanted that can't be done in
the current Emacs are:", so I assume you ignored that context instead of
merely overlooking it, but it is in fact crucial, even to your supposed
counter-argument. Emacs Lisp has some _fundemental_ limitations that
Common Lisp the language and its several implementations don't have.
obviously, however, you _could_ do anything in any language given enough
effort and resources, but whether you want to is _usually_ a matter of
convenience and pragmatics for most people -- the absence of available
resources is usually an argument against "can". if you will, Emacs Lisp
makes certain tasks prohibitively inconvenient and/or impractical. for
me, that matters a lot. if it doesn't matter to you, I expect a free
implementation soon.
| #3 doesn't depend on ANSI CL, but just the fact that most CL
| implementations also include foreign function interfaces; but there's no
| good reason why a similar FFI couldn't be included in Emacs Lisp.
then you should have no objection to "then go do it", right?
I promise that I'll listen to your argument _after_ you have done it.
#:Erik
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
>* Barry Margolin <······@bbnplanet.com>
>| #1 and #2 don't seem to be related to the dialect of Lisp that Emacs
>| happens to be written in.
>
> I prefixed what I wrote with "what I have wanted that can't be done in
> the current Emacs are:", so I assume you ignored that context instead of
> merely overlooking it, but it is in fact crucial, even to your supposed
> counter-argument.
I interpreted it as "can't be done in the current Emacs because it's not
written in Common Lisp". I was assuming that your message was referring to
the thread subject, and trying to interpret the phrase in that light.
> Emacs Lisp has some _fundemental_ limitations that
> Common Lisp the language and its several implementations don't have.
> obviously, however, you _could_ do anything in any language given enough
> effort and resources, but whether you want to is _usually_ a matter of
> convenience and pragmatics for most people -- the absence of available
> resources is usually an argument against "can". if you will, Emacs Lisp
> makes certain tasks prohibitively inconvenient and/or impractical. for
> me, that matters a lot. if it doesn't matter to you, I expect a free
> implementation soon.
If I understand you correctly, the point you're making is that some CL
implementors have already implemented some things (like FFI) that haven't
been implemented in Emacs Lisp yet. So what you're really comparing are
implementations, not languages. None of these things are mentioned by, nor
even hinted at by, the ANSI CL spec. The fact that the Lisp
implementations with FFI are all CL could almost be considered a
coincidence.
>| #3 doesn't depend on ANSI CL, but just the fact that most CL
>| implementations also include foreign function interfaces; but there's no
>| good reason why a similar FFI couldn't be included in Emacs Lisp.
>
> then you should have no objection to "then go do it", right?
> I promise that I'll listen to your argument _after_ you have done it.
I never claimed to be a Lisp implementor.
Converting Emacs to Common Lisp would be an enormous undertaking. If you
can contemplate the resources being available for this, why can't you
imagine those same resources being applied to adding these features to
Emacs Lisp?
It would certainly have been nice if Emacs had been written in Common Lisp
to begin with. But now there's a huge body of code (the Emacs source
itself and all the public packages that are avaiable) that's dependent on
the current dialect. If Emacs were converted to Common Lisp it could
essentially set it back a decade or more as we wait for people to recode
all their packages to be compatible.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Sam Steingold
Subject: Re: Common Lisp interpretation by emacs
Date:
Message-ID: <u66uc5d82.fsf@ksp.com>
>>>> In message <·················@burlma1-snr2>
>>>> On the subject of "Re: Common Lisp interpretation by emacs"
>>>> Sent on Fri, 24 Mar 2000 19:23:58 GMT
>>>> Honorable Barry Margolin <······@bbnplanet.com> writes:
>>
>> It would certainly have been nice if Emacs had been written in
>> Common Lisp to begin with. But now there's a huge body of code (the
>> Emacs source itself and all the public packages that are avaiable)
>> that's dependent on the current dialect. If Emacs were converted to
>> Common Lisp it could essentially set it back a decade or more as we
>> wait for people to recode all their packages to be compatible.
No, not AT ALL!
Right now, this very moment, you can run any Emacs-Lisp code which
doesn't do display things (e.g., calendar) in any ANSI CL
implementation, using the file elisp.lsp in cllib (see
http://www.podval.org/~sds/data/cllib.html).
It is not hard at all to load any elisp in CL.
Nobody is suggesting discarding the decades of ELisp development.
As to the CL-Emacs, remember RMS said
(http://www.gnu.org/software/emacs/emacs-paper.html) that people will
want to extend the editor, so he gave them a powerful extension
language. the problem with this approach is that people will want to
extend the editor beyond your imagination (gnu, w3, calc &c), so you
better use a real language, not just an "extension language".
It is very unfortunate (and, IMO, detrimental to the popularity of Lisp)
that the Emacs users have to extend the editor using a language, useless
for anything else.
--
Sam Steingold (http://www.podval.org/~sds)
Micros**t is not the answer. Micros**t is a question, and the answer is Linux,
(http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation.
Your mouse has moved - WinNT has to be restarted for this to take effect.
From: Tim Bradshaw
Subject: Re: Common Lisp interpretation by emacs
Date:
Message-ID: <ey3ln36lf93.fsf@cley.com>
* Sam Steingold wrote:
> No, not AT ALL!
> Right now, this very moment, you can run any Emacs-Lisp code which
> doesn't do display things (e.g., calendar) in any ANSI CL
> implementation, using the file elisp.lsp in cllib (see
> http://www.podval.org/~sds/data/cllib.html).
Which is basically no emacs lisp code you might ever want to run, of
course.
--tim
From: Sam Steingold
Subject: Re: Common Lisp interpretation by emacs
Date:
Message-ID: <ubt40zapk.fsf@ksp.com>
>>>> In message <···············@cley.com>
>>>> On the subject of "Re: Common Lisp interpretation by emacs"
>>>> Sent on 26 Mar 2000 01:57:44 +0100
>>>> Honorable Tim Bradshaw <···@cley.com> writes:
>> * Sam Steingold wrote:
>>
>> > No, not AT ALL!
>>
>> > Right now, this very moment, you can run any Emacs-Lisp code which
>> > doesn't do display things (e.g., calendar) in any ANSI CL
>> > implementation, using the file elisp.lsp in cllib (see
>> > http://www.podval.org/~sds/data/cllib.html).
>>
>> Which is basically no emacs lisp code you might ever want to run, of
>> course.
calendar is fairly useful.
otoh, if my elisp.lsp could run the emacs buffer/display code too, it
would have been CL-Emacs already - and I never claimed I wrote one! :-)
--
Sam Steingold (http://www.podval.org/~sds)
Micros**t is not the answer. Micros**t is a question, and the answer is Linux,
(http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation.
The world will end in 5 minutes. Please log out.
From: Erik Naggum
Subject: Re: Common Lisp interpretation by emacs
Date:
Message-ID: <3162927272540679@naggum.no>
* Barry Margolin
| I interpreted it as "can't be done in the current Emacs because it's not
| written in Common Lisp". I was assuming that your message was referring
| to the thread subject, and trying to interpret the phrase in that light.
holy cow -- the level at which some people here work _so_ hard to find
something to quarrel over is flat out amazing. get some _sleep_, dude!
yes, it would be possible to do in some Common Lisp implementations.
yes, it would be possible to do in something different than Common Lisp.
yes, it would be possible to do in something entirely different than Emacs.
this _completely_ invalidates you quibbling "because it's not written in
Common Lisp". the causal relationship you so adamantly seek is absent.
why do I want to do it Common Lisp? is "duh!" a satisfactory answer or
do you actually have to have this _explained_ to you, Barry? one could
almost believe you have been getting really upset over something and are
not getting over it. this _has_ happened before. is it recurring?
| If I understand you correctly, the point you're making is that some CL
| implementors have already implemented some things (like FFI) that haven't
| been implemented in Emacs Lisp yet. So what you're really comparing are
| implementations, not languages. None of these things are mentioned by,
| nor even hinted at by, the ANSI CL spec.
I don't consider "Common Lisp" to be restricted to what's strictly in the
standard unless I explicitly and specifically name the standard or make
it the context. that's why I _also_ don't require everything I think is
useful to be part of the standard before I can use it and why I don't
believe that using implementation extensions is evil or any of the other
numerous anal-retentive attitudes that flourish in some subcommunities of
this newsgroup under the guise of "open source".
I will regret it if it is now necessary to verbosely state "I use an
implementation of Common Lisp in a development environment conducive to
the goals of the Common Lisp language" every time one wishes to say "I
use Common Lisp", but considering the personal needs of some people here
(and their history of same, which I'm reminded of) to find flaws and
quarrel where it has absolutely zero constructive value, maybe it's time
to post in HTML with hypertext links from just about every word to pages
upon pages of disclaimers and explanations.
| The fact that the Lisp implementations with FFI are all CL could almost
| be considered a coincidence.
sure, and that's perfectly fine by me. most of the interesting stuff
that happens in this world is by coincidence. it would be foolish to
deny or belittle facts merely because they are coincidences, of course,
but I assume that something like that underlies your argument, which I
must therefore reject as rather specious.
| If you can contemplate the resources being available for this, why can't
| you imagine those same resources being applied to adding these features
| to Emacs Lisp?
I can. I have. you're abaout five years too late with your question.
why do you assume so arrogantly that you are the first person on this
planet to have thought of counter-arguments? I find that puzzling. I
find it even more puzzling that the question is posed to aggressively.
if you have a personal problem you wish to raise, please don't feel
obliged to wrap it in gift paper like a pseudo-technical discussion.
| It would certainly have been nice if Emacs had been written in Common
| Lisp to begin with. But now there's a huge body of code (the Emacs
| source itself and all the public packages that are avaiable) that's
| dependent on the current dialect. If Emacs were converted to Common Lisp
| it could essentially set it back a decade or more as we wait for people
| to recode all their packages to be compatible.
you are certainly free to assume that this is the only way to think about
this problem and you are equally free to assume that noobody else would
have the wherewithal to solve technical problems of this kind, either.
the phrasing makes it abundantly clear that it has zero value to educate
you against your will on this topic, and so I won't even try. it would,
as has been said about another pointless endeavor, waste my time and
annoy you.
#:Erik
From: Thom Goodsell
Subject: Re: Common Lisp interpretation by emacs
Date:
Message-ID: <38DB7934.F2799BAA@cra.com>
"Christopher R. Barry" wrote:
> Okay, I'd rather use the Allegro CL debugger and development
> environment for programming Emacs applications, but do I really,
> *really* need it? No.
Yes, but if we only stuck to what we really, *really* needed, we'd all
still be using vi. We might even still be programming in binary on
punchcards. I agree that rewriting or hacking Emacs would be a pretty
daunting task, but if someone really, *really* *wants* to do it, more
power to them.
> Our current Emacs is a good enough I think, and
> anyone not happy with it should examine what they think they *really*
> need that it can't do, and just use their intelligence,
> problem-solving skills, and patience to make do with what we have and
> learn to be happy, content, and find peace of mind with it and with
> Unix generally.
I'm all for happiness, contentment, peace, and Zen, but why not use
their intelligence, problem-solving skills, and patience to get Emacs
(or Hemlock) to do what they want?
Thom
From: Tim Bradshaw
Subject: Re: Common Lisp interpretation by emacs
Date:
Message-ID: <ey3ya79dunl.fsf@cley.com>
* Hartmann Schaffer wrote:
> would hemlock (?, the cmucl editor) be a suitable starting point?
Hemlock was (is I suppose) pretty nice in a lot of ways, it would be
nice to see it revived!
--tim
Clemens Heitzinger <········@rainbow.studorg.tuwien.ac.at> writes:
> Johan Kullstam <········@ne.mediaone.net> writes:
>
> > i hear that someone spliced guile/scheme to emacs. perhaps a similar
> > stunt could be performed with clisp? this would be a fair amount of
> > work.
>
> clisp with multithreading would be a good base for an open source CL
> emacs. If somebody with emacs and CL experience would design such a
> beast...
I beg to differ. NO CL implementation should be a "good base" for an
open source CL-Emacs.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
In article <··············@parades.rm.cnr.it>,
Marco Antoniotti <·······@parades.rm.cnr.it> wrote:
>I beg to differ. NO CL implementation should be a "good base" for an
>open source CL-Emacs.
Why?
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Christopher R. Barry
Subject: Re: Common Lisp interpretation by emacs
Date:
Message-ID: <87u2hx2pmf.fsf@2xtreme.net>
Barry Margolin <······@bbnplanet.com> writes:
> In article <··············@parades.rm.cnr.it>,
> Marco Antoniotti <·······@parades.rm.cnr.it> wrote:
> >I beg to differ. NO CL implementation should be a "good base" for an
> >open source CL-Emacs.
>
> Why?
[...]
I'm sure he meant that a CL-Emacs should be portable across different
Lisps. (Most of the questions he asks of the group concern
portability.)
It's already too much trouble writing a non-portable CL-Emacs as is. A
portable one isn't going to happen without salaried experienced
programmers on the job. A non-portable one probably won't ever happen
either, nothing of the caliber of GNU/X Emacs at least.
It's impossible to meet real-world performance requirements for editor
operations without making the internal operations and data-structures
very hairy. An elegant CL-HTTP-style CLOS/MOP Emacs would be slower
than the current Emacs running interpreted Lisp, just like CL-HTTP
with compiled Lisp server applications is much, much slower than
Apache running interpreted Perl server applications.
Just learn to live with and love and improve the Emacs we have now,
since a CL one just isn't happening, and would take a lot of work to
make much more spectacular than our current Emacs even if it did.
Christopher
From: Erik Naggum
Subject: Re: Common Lisp interpretation by emacs
Date:
Message-ID: <3162852050149389@naggum.no>
* Christopher R. Barry
| Just learn to live with and love and improve the Emacs we have now,
| since a CL one just isn't happening, and would take a lot of work to
| make much more spectacular than our current Emacs even if it did.
regrettably, I have come to the same conclusion -- this won't fly if it
doesn't have a very significant advantage over the current Emacs, and
that means user-visible features, not just programmability in a much
better language. with two major disincentives operating against any
Common Lisp project, the chances of sufficient popularity are also very
slim. the two disincentives are primarily the close-minded attitude and
open hostility of the Open Source crowd towards anything that is not
sufficiently "open" -- i.e., "philosophically impure" in their eyes --
which detracts effort and would-be programmers alike, and secondarily
that the pool of people was already so small initially that it certainly
has no critical mass by the time the primary disincentive has eroded
popular enthusiasm.
#:Erik
······@2xtreme.net (Christopher R. Barry) writes:
> Barry Margolin <······@bbnplanet.com> writes:
>
> > In article <··············@parades.rm.cnr.it>,
> > Marco Antoniotti <·······@parades.rm.cnr.it> wrote:
> > >I beg to differ. NO CL implementation should be a "good base" for an
> > >open source CL-Emacs.
> >
> > Why?
>
> [...]
>
> I'm sure he meant that a CL-Emacs should be portable across different
> Lisps. (Most of the questions he asks of the group concern
> portability.)
Exactly.
> It's already too much trouble writing a non-portable CL-Emacs as is. A
> portable one isn't going to happen without salaried experienced
> programmers on the job. A non-portable one probably won't ever happen
> either, nothing of the caliber of GNU/X Emacs at least.
You are right.
...
> Just learn to live with and love and improve the Emacs we have now,
> since a CL one just isn't happening, and would take a lot of work to
> make much more spectacular than our current Emacs even if it did.
Good enough assessment.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
Charles Hixson <·······@earthlink.net> writes:
> OTOH, a multi-threaded CLisp sounds like a good idea in and of itself.
An even better idea would be to have all Common Lisp implementations
implement the a thread package based on, say, the CLIM processes spec.
> (Speaking as a TURE tyro.)
I'm missing this one. What does it mean?
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
From: Tim Bradshaw
Subject: Re: Common Lisp interpretation by emacs
Date:
Message-ID: <ey3wvmpvrxp.fsf@cley.com>
* Marco Antoniotti wrote:
> An even better idea would be to have all Common Lisp implementations
> implement the a thread package based on, say, the CLIM processes spec.
I'd much rather see everyone implement their own right now, and the
CLIM process spec (or some common one) be layered on top of it, which
was its purpose, after all.
--tim
······@2xtreme.net (Christopher R. Barry) writes:
> An elegant CL-HTTP-style CLOS/MOP Emacs would be slower
hey! FRED of MCL *is* a CLOS-based emacs (well, not quite as feature-
rich, but still: FRED Resembles Emacs Deliberately), and it is not
at all slow.
> than the current Emacs running interpreted Lisp, just like CL-HTTP
> with compiled Lisp server applications is much, much slower than
> Apache running interpreted Perl server applications.
now what's your reason for claiming that??
--
(espen)
Christopher R. Barry wrote in message <··············@2xtreme.net>...
...
[snip]
...
>It's impossible to meet real-world performance requirements for editor
>operations without making the internal operations and data-structures
>very hairy. An elegant CL-HTTP-style CLOS/MOP Emacs would be slower
>than the current Emacs running interpreted Lisp, just like CL-HTTP
>with compiled Lisp server applications is much, much slower than
>Apache running interpreted Perl server applications.
Could I trouble you to elaborate on this? I'm just starting in with CL-HTTP,
and am new to HTTP in general. So far I'm thrilled with the things CL-HTTP
will allow me to express, but right now I'm just tinkering with the
examples.
Is there some point at which performance issues make CL-HTTP a poor
choice for high-traffic applications?
Are there other barriers to building a commercial venture around CL-HTTP?
Greetings from San Diego,
- Eric Scott
Eric Scott wrote in message ...
>Christopher R. Barry wrote in message <··············@2xtreme.net>...
>>than the current Emacs running interpreted Lisp, just like CL-HTTP
>>with compiled Lisp server applications is much, much slower than
>>Apache running interpreted Perl server applications.
>
>Could I trouble you to elaborate on this? I'm just starting in with
CL-HTTP,
>and am new to HTTP in general. So far I'm thrilled with the things CL-HTTP
>will allow me to express, but right now I'm just tinkering with the
>examples.
>Is there some point at which performance issues make CL-HTTP a poor
>choice for high-traffic applications?
>
>Are there other barriers to building a commercial venture around CL-HTTP?
Regarding the assertion about CL-HTTP being fast or slow, I can't comment.
But I can give some thoughts on architecture and what not.
Conceptually, there should be no reason why CL-HTTP is any slower than some
other web server save for the fact that CL-HTTP is a much more dynamic
environment for HTTP applications than any of the other big web servers. It
turns out that adding functionality to a web server can be fairly
complicated and error prone.
How do I know that extending web servers is difficult? For one, I've done my
share of module programming for Apache, and for another, look at how many
tools and utilities are in the world to make Web programming "Easy!". If it
was that easy, there wouldn't just a diverse market for such tools.
In all seriousness, I think CL-HTTP is the wrong approach. It focuses work
on the wrong level.
If you look at something like the HTTP protocol, and the extensions built
upon that protocol, you'll notice that like much of the rest of the
Internet, it is moving very quickly. Perhaps moreso than most because of its
current role in the modern Internet, along with its young age.
The application folks should be considering HTTP the same way as TCP/IP, as
a delivery mechanism whose details aren't particularly important to the task
of moving application data.
IMHO, the time on Lisp shouldn't be spent on making an efficient HTTP
server. There are a LOT of efficient HTTP servers. Rather, the time should
be spent on making an efficient Lisp Application Server that interfaces with
the Big 3 HTTP servers. In one sense, much of the base infrastructure is
similiar, having a server that responds to multiple requests over a socket,
and all the pain of threading and state management, etc, that it entails.
The detail is the protocol, and the stability of the client.
The Lisp side is much better at dealing with the complexity and dynamics of
a large, sophisticated application. And the Lisp environments are well
suited to such applications. Serving static content over the web isn't a
particulary complicated application. Many web servers perform an admirable
job of just that task, and many are very fast. There's current development
of mating the static HTTP server into the Linux kernel, thus eliminating
layers of abstraction for the sake of performance for simple tasks - serving
static files over HTTP.
So, let Netscape, Apache, MS, etc tune the crap out of their web servers to
do the mundane, much needed, but routine task of serveing static content to
the web, and then plug a Lisp Application Server into this framework to
generate dynamic content. EVERY SERVER ON THE PLANET has this architecture.
Have a farily generic "web server module" that connects the standard web
servers to the LAS, and then you eliminate all sorts of platform issues,
scaling issues, etc, because your LAS can be one or more dedicated machines
to support the application with commodity "management compliant" web servers
fronting the load. Throw some caching into the mix, and performance will be
the least of your problems.
The classic example are the JSPs, ASPs, Servlets, etc. Who would run a
zillion hit web site on a server written in Java? Or Visual Basic? You
wouldn't...they're too slow. But, put these technologies behind the veneer
of an idiot savant web server, and performance becomes less of an issue.
Write an interface module that connect Apache, NIS, and IIS to an LAS using
a lispy protocol. You write that once. Then you focus on creating your
application on your LAS while the other guys focus on HTTP 1.0, 1.1, 2.0,
SSL, etc. etc. They can focus on all of that crap about interfacing to
stupid browsers, backward compatability, etc. YOU get to focus on your
application.
The work to be done is similiar, a protocol to be designed, appropriate
handling of sockets and multi-process, etc. But your environment is a little
bit more stable because you've got the web server dealing with a bunch of
the junk coming in to you over the less than reliable internet. Plus your
protocol moves forward at a much slower pace than the HTTP protocol does. As
HTTP advances, your server doesn't necesarilly have to change. All of those
advances come "free" with a new web server. Your HTTP protocol is "plug and
play".
Why keep up with the joneses? Why constantly re-invent the wheel? The
fastest web servers today are lousy application servers. One mistake and the
whole server explodes. But they're great at sucking data out of file systems
and sockets, and spitting them out as HTTP messages.
Focus on the creation and management of content to user, and let the web
mechanics worry about delivering it.
Will Hartung
(······@home.com)
On Tue, 28 Mar 2000 15:34:38 GMT, "Will Hartung" <······@home.com>
wrote:
>Eric Scott wrote in message ...
>>Christopher R. Barry wrote in message <··············@2xtreme.net>...
>>>than the current Emacs running interpreted Lisp, just like CL-HTTP
>>>with compiled Lisp server applications is much, much slower than
>>>Apache running interpreted Perl server applications.
>>
>>Could I trouble you to elaborate on this? I'm just starting in with
>CL-HTTP,
>>and am new to HTTP in general. So far I'm thrilled with the things CL-HTTP
>>will allow me to express, but right now I'm just tinkering with the
>>examples.
>>Is there some point at which performance issues make CL-HTTP a poor
>>choice for high-traffic applications?
>>
>>Are there other barriers to building a commercial venture around CL-HTTP?
>
>
>Regarding the assertion about CL-HTTP being fast or slow, I can't comment.
>But I can give some thoughts on architecture and what not.
>
>Conceptually, there should be no reason why CL-HTTP is any slower than some
>other web server save for the fact that CL-HTTP is a much more dynamic
>environment for HTTP applications than any of the other big web servers. It
>turns out that adding functionality to a web server can be fairly
>complicated and error prone.
>
>How do I know that extending web servers is difficult? For one, I've done my
>share of module programming for Apache, and for another, look at how many
>tools and utilities are in the world to make Web programming "Easy!". If it
>was that easy, there wouldn't just a diverse market for such tools.
>
>In all seriousness, I think CL-HTTP is the wrong approach. It focuses work
>on the wrong level.
>
>If you look at something like the HTTP protocol, and the extensions built
>upon that protocol, you'll notice that like much of the rest of the
>Internet, it is moving very quickly. Perhaps moreso than most because of its
>current role in the modern Internet, along with its young age.
>
>The application folks should be considering HTTP the same way as TCP/IP, as
>a delivery mechanism whose details aren't particularly important to the task
>of moving application data.
>
>IMHO, the time on Lisp shouldn't be spent on making an efficient HTTP
>server. There are a LOT of efficient HTTP servers. Rather, the time should
>be spent on making an efficient Lisp Application Server that interfaces with
>the Big 3 HTTP servers. In one sense, much of the base infrastructure is
>similiar, having a server that responds to multiple requests over a socket,
>and all the pain of threading and state management, etc, that it entails.
>The detail is the protocol, and the stability of the client.
>
>The Lisp side is much better at dealing with the complexity and dynamics of
>a large, sophisticated application. And the Lisp environments are well
>suited to such applications. Serving static content over the web isn't a
>particulary complicated application. Many web servers perform an admirable
>job of just that task, and many are very fast. There's current development
>of mating the static HTTP server into the Linux kernel, thus eliminating
>layers of abstraction for the sake of performance for simple tasks - serving
>static files over HTTP.
>
>So, let Netscape, Apache, MS, etc tune the crap out of their web servers to
>do the mundane, much needed, but routine task of serveing static content to
>the web, and then plug a Lisp Application Server into this framework to
>generate dynamic content. EVERY SERVER ON THE PLANET has this architecture.
Amen. :-) Do you know if there's someone working on this? O:-)
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
On Tue, 28 Mar 2000 17:08:57 GMT, Fernando <·······@must.die> wrote:
[snip]
Damn, sorry for the huge quoted text... O:-)
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
From: Paolo Amoroso
Subject: Re: CL-HTTP performance (was 'Common Lisp interpretation by emacs')
Date:
Message-ID: <hRfiOHrpjAShTUL9N4Uv+fnjxnui@4ax.com>
On Tue, 28 Mar 2000 17:08:57 GMT, Fernando <·······@must.die> wrote:
[about Lisp application servers]
> Amen. :-) Do you know if there's someone working on this? O:-)
You may check the "IMHO" toolkit:
http://alpha.onshore.com/lisp-software/
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
"Will Hartung" <······@home.com> writes:
> IMHO, the time on Lisp shouldn't be spent on making an efficient HTTP
> server. There are a LOT of efficient HTTP servers. Rather, the time should
> be spent on making an efficient Lisp Application Server that interfaces with
> the Big 3 HTTP servers. In one sense, much of the base infrastructure is
> similiar, having a server that responds to multiple requests over a socket,
> and all the pain of threading and state management, etc, that it entails.
> The detail is the protocol, and the stability of the client.
From a marketing point of view, you're perfectly right. This is the way
to go.
But in reality, what are a lot of these "servlet engines" and application
servers actually doing behind the curtains? Well, many of them are
actually doing socket-based communication with the web server... So
the backend server must be clever at handling socket connections anyway.
And HTTP is a very simple protocol to implement.
So my conjecture is that if your application is fairly static, using
apache in front is fairly useful, because only the dynamic stuff will
be forwarded to the backend server. But if almost everything is dynamic,
the only reason for putting something like apache in front is to make
the marketing department and the system guys confortable, since it
appears to them that they have a more uniform architecture since only
one kind of server is handling the remote requrest...
--
(espen)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> > IMHO, the time on Lisp shouldn't be spent on making an efficient
> > HTTP server. There are a LOT of efficient HTTP servers. Rather,
> > the time should be spent on making an efficient Lisp Application
> > Server that interfaces with the Big 3 HTTP servers. In one sense,
> > much of the base infrastructure is similiar, having a server that
> > responds to multiple requests over a socket, and all the pain of
> > threading and state management, etc, that it entails. The detail
> > is the protocol, and the stability of the client.
>
> From a marketing point of view, you're perfectly right. This is the way
> to go.
It has technical merits as well:
1. The webserver shim can broker more than one application. I can run
may different lisp applications and have them appear to be the same
website, without having to run them all in the same image.
2. The webserver shim can broker more than one instance of an
application. Load balancing across several machines is a very nice
feature of WO which uses this architecture. This is perhaps the
biggest win.
3. The webserver shim can give useful error messages to the user if
there is a drastic failure in the backend, as opposed to the users
connection just timing out.
4. The webserver also handle CGI and other common services, which
makes it easier to integrate the application into existing
websites while maintaining consisent URLs.
5. Full HTTP1.1 and the other common webserver facilities are not
trivial to implement, cl-http being a testament to that. I'm not
interested in maintaining that code.
6 The webserver shim let's me seperate the machine doing basic HTTP
service (static files, CGIs, whutever) from the machine running my
application. This means more flexibility when architecting the
application, and also allows me to isolate the application server
which may need to interact with sensitive systems.
> But in reality, what are a lot of these "servlet engines" and application
> servers actually doing behind the curtains? Well, many of them are
> actually doing socket-based communication with the web server... So
> the backend server must be clever at handling socket connections anyway.
> And HTTP is a very simple protocol to implement.
I think you are understating the different between a full HTTP1.1
implementation that works will all browsers out there, and a protocol
which you design/control which only has to talk to one client, your
webserver shim. If your shim, is just a CGI, then you don't even have
to port it to different webservers.
--
Craig Brozefsky <·····@red-bean.com>
Free Scheme/Lisp Software http://www.red-bean.com/~craig
"Hiding like thieves in the night from life, illusions of
oasis making you look twice. -- Mos Def and Talib Kweli
From: Daniel Barlow
Subject: Re: CL-HTTP performance (was 'Common Lisp interpretation by emacs')
Date:
Message-ID: <87ln3153c7.fsf@tninkpad.telent.net>
Craig Brozefsky <·····@red-bean.com> writes:
> It has technical merits as well:
>
> 5. Full HTTP1.1 and the other common webserver facilities are not
> trivial to implement, cl-http being a testament to that. I'm not
> interested in maintaining that code.
Related to which: SSL support is another non-trivial part of writing a
useful web server.
> I think you are understating the different between a full HTTP1.1
> implementation that works will all browsers out there, and a protocol
> which you design/control which only has to talk to one client, your
> webserver shim. If your shim, is just a CGI, then you don't even have
> to port it to different webservers.
My shim is apache's mod_proxy. My persistent process
(http://araneida.telent.net/) is an HTTP/1.0 server (which makes it
easy to test in the absence of the shim, too - just point a web
browser directly at it).
There are enough interoperability issues with strange TCP
implementations out there on the net that W Richard Stevens[1] can write
a third of a book about it. I'd far rather leverage the expertise of
the people who enjoy that stuff than worry about it myself.
-dan
[1] TCP/IP Illustrated, Volume 3, Part 2
Daniel Barlow <···@telent.net> writes:
> [...] There are enough interoperability issues with strange TCP
> implementations out there on the net that W Richard Stevens can
> write a third of a book about it.
Could have written. Stevens passed away on September 1, 1999, to the
great loss of the computer society. There's an obituary at
<URL:http://dan.pmbc.com/6bone/w.richard.stevens.obituary.html>.
--
'------------------- Markus Bjartveit Kr�ger ---------------------`
' `
` E-mail: ·······@pvv.org WWW: http://www.pvv.org/~markusk/ '
)-------------------------------------------------------------------(
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> "Will Hartung" <······@home.com> writes:
>
> > IMHO, the time on Lisp shouldn't be spent on making an efficient HTTP
> > server. There are a LOT of efficient HTTP servers. Rather, the time should
> > be spent on making an efficient Lisp Application Server that interfaces with
> > the Big 3 HTTP servers. In one sense, much of the base infrastructure is
> > similiar, having a server that responds to multiple requests over a socket,
> > and all the pain of threading and state management, etc, that it entails.
> > The detail is the protocol, and the stability of the client.
>
> From a marketing point of view, you're perfectly right. This is the way
> to go.
>
> But in reality, what are a lot of these "servlet engines" and
> application servers actually doing behind the curtains? Well, many
> of them are actually doing socket-based communication with the web
> server... So the backend server must be clever at handling socket
> connections anyway. And HTTP is a very simple protocol to
> implement.
The socket comms are a bit simpler, at least in the cases that I am
familiar with, most notably, Apache JServ. The company I work for is
in the process of developing something a bit like what Will describes
above--I think we've gotten to the point where we have something
useful, so if you like, please see my following post announcing its
public availability.
Jesse Bouwman
<·····@onshore.com>
From: Christopher C Stacy
Subject: Re: Common Lisp interpretation by emacs
Date:
Message-ID: <x8lk8itxmlm.fsf@world.std.com>
>>>>> On Thu, 23 Mar 2000 18:27:21 +0800, John T H Wong ("John") writes:
John> Dear lisp programmer & emacs users,
John> Can one make emacs to interpret common lisp instead of elisp?
No. GNU Emacs has its own Emacs Lisp language, and does not have Common Lisp,
and the two are not compatible. They are only vaguely related in that they
both belong to a broad family of languages under the name "Lisp".
Common Lisp is a much more powerful language, and it would be possible
to implement Emacs (including an Emacs-Lisp interpreter) in Common Lisp.
Of course, reimplementing Emacs (mostly from scratch) would be a big job.
Also, while GNU Emacs is the most popular implementation of Emacs,
and though it (well, actually there are at least two) is considered
the reference implementation of Emacs, other Emacs editors do exist.
The major Lisp development environments include their own Emacs
editors that are written in Common Lisp. These do not accept ELisp code
and are not compatible with Elisp programs. The usually do not include
the full Emacs functionality, and there are usually some small differences
in some of the commands. But all of these Emacs editors (including GNU)
were inspired by the same original Emacs from the 1970s.
"John T. H. Wong" <·······@hkucs.org> writes:
> Dear lisp programmer & emacs users,
>
> Can one make emacs to interpret common lisp instead of elisp? and if
>
> one can, can you point me the way?
> Thank you very much.
Which of these things do you mean precisely?
Make emacs run Common Lisp? M-x run-lisp
Make emacs use Common Lisp as its extension language? Not without
essentially rewriting emacs.
Make Elisp use Common Lisp constructions? You can get most of that
with:
(require 'cl)
I've got a file tehom-cl.el that takes care of a little more. The
eieio package emulates CLOS, but leaves out a lot.
--
Tom Breton, http://world.std.com/~tob
Not using "gh" since 1997. http://world.std.com/~tob/ugh-free.html
Rethink some Lisp features, http://world.std.com/~tob/rethink-lisp/index.html