Lisp: 4th Most Frequently Used Language in Debian GNU/Linux
Emre Sevinc
A detailed study shows that Lisp is the 4th most
common language used for software in
Debian Sarge GNU/Linux repository.
Debian GNU/Linux system includes 230 millions of SLOC and the
majority is written in C and C++. Shell programming ranks 3rd and
the 4th position is occupied by Lisp which beath languages
like Perl, Python and Java.
The story appears on FM Int:
http://www.fazlamesai.net/int/?a=article&sid=15
--
Emre Sevinc
eMBA Software Developer Actively engaged in:
http:www.bilgi.edu.tr http://ileriseviye.org
http://www.bilgi.edu.tr http://fazlamesai.net
Cognitive Science Student http://cazci.com
http://www.cogsci.boun.edu.tr
Edi Weitz
> A detailed study shows that Lisp is the 4th most common language
> used for software in Debian Sarge GNU/Linux repository.
>
> Debian GNU/Linux system includes 230 millions of SLOC and the
> majority is written in C and C++. Shell programming ranks 3rd and
> the 4th position is occupied by Lisp which beath languages like
> Perl, Python and Java.
>
> The story appears on FM Int:
>
> http://www.fazlamesai.net/int/?a=article&sid=15
Of course, this got to be mostly Emacs Lisp and other dialects that
aren't Common Lisp... :(
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq "spam...@agharta.de" 5) "edi")
Andras Simon
> A detailed study shows that Lisp is the 4th most
> common language used for software in
> Debian Sarge GNU/Linux repository.
>
> Debian GNU/Linux system includes 230 millions of SLOC and the
> majority is written in C and C++. Shell programming ranks 3rd and
> the 4th position is occupied by Lisp which beath languages
> like Perl, Python and Java.
I'm pretty sure the emacs is the culprit.
Andras
Frank Buss
> A detailed study shows that Lisp is the 4th most
> common language used for software in
> Debian Sarge GNU/Linux repository.
there are many different Lisp distributions like clisp, cmucl, sbcl etc. in
Debian, which comes with source code and implements the Lisp itself instead
of for example shell scripts, which are used for other tasks than building
shell script interpreters :-)
--
Frank Buß, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
LuisGLopez
> Debian GNU/Linux system includes 230 millions
Did I read *230 millions*???? ¿¿¿¿230,000,000?????
¿¿¿¿¿¿¿¿230e6??????????
*That's* a lot...
Rob Thorpe
> A detailed study shows that Lisp is the 4th most
> common language used for software in
> Debian Sarge GNU/Linux repository.
>
> Debian GNU/Linux system includes 230 millions of SLOC and the
> majority is written in C and C++. Shell programming ranks 3rd and
> the 4th position is occupied by Lisp which beath languages
> like Perl, Python and Java.
>
> The story appears on FM Int:
>
> http://www.fazlamesai.net/int/?a=article&sid=15
I'm most impressed by the amount of code, 230 million lines!
I think some of the results for lisp come from duplication, much emacs
lisp is common between XEmacs and GNU Emacs, but I expect they counted
both separately. Also, many languages include their emacs modes in
their source distributions.
The results for shell may not be accurate either since it's often
generated automatically. I think sloccount (which they used) knows
about some of these ways, but not all of them.
Duane Rettig
> A detailed study shows that Lisp is the 4th most
> common language used for software in
> Debian Sarge GNU/Linux repository.
>
> Debian GNU/Linux system includes 230 millions of SLOC and the
> majority is written in C and C++. Shell programming ranks 3rd and
> the 4th position is occupied by Lisp which beath languages
> like Perl, Python and Java.
>
> The story appears on FM Int:
>
> http://www.fazlamesai.net/int/?a=article&sid=15
Now why do I get the distinct feeling that people are going
to jump all over this thing and tell us how invalid it is?
Already you are getting responses that are attributing it to
emacs-lisp. So what? Lisp is lisp. Until 1984, there were
many lisps around, all disjoint and not counted as one at all.
Now we have two or three that call themselves Lisp, and that
should be good enough. But rest assured someone will find a
way to discount the study for one reason or another...
--
Duane Rettig du...@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
alex...@gmail.com
> A detailed study shows that Lisp is the 4th most
> common language used for software in
> Debian Sarge GNU/Linux repository.
>
> Debian GNU/Linux system includes 230 millions of SLOC and the
> majority is written in C and C++. Shell programming ranks 3rd and
> the 4th position is occupied by Lisp which beath languages
> like Perl, Python and Java.
>
> The story appears on FM Int:
>
> http://www.fazlamesai.net/int/?a=article&sid=15
C is almost, but not entirely a proper subset of C++. Interestingly,
they are in separate groups, but Emacs Lisp, Scheme and Common Lisp are
in one.
--
"Or maybe you shouldn't bring me every little piece of trash you happen
to pick up" - Narrator
Kenny Tilton
Duane Rettig wrote:
> Emre Sevinc <em...@bilgi.edu.tr> writes:
>
>
>>A detailed study shows that Lisp is the 4th most
>>common language used for software in
>>Debian Sarge GNU/Linux repository.
>>
>>Debian GNU/Linux system includes 230 millions of SLOC and the
>>majority is written in C and C++. Shell programming ranks 3rd and
>>the 4th position is occupied by Lisp which beath languages
>>like Perl, Python and Java.
>>
>>The story appears on FM Int:
>>
>>http://www.fazlamesai.net/int/?a=article&sid=15
>
>
> Now why do I get the distinct feeling that people are going
> to jump all over this thing and tell us how invalid it is?
What part of "there is no such thing as bad publicity" do you not
understand?! :)
We should hope for a huge, badmouthing, anti-Lisp flamewar if we really
want to build mindshare. As a software sales guy said after a disastrous
presentation in which the client totally reamed him, "If you are not
getting shot at, then you are not over the target."
--
Kenny
Why Lisp? http://wiki.alu.org/RtL_Highlight_Film
"I've wrestled with reality for 35 years, Doctor, and I'm happy to state
I finally won out over it."
Elwood P. Dowd, "Harvey", 1950
Tayssir John Gabbour
> Emre Sevinc <em...@bilgi.edu.tr> writes:
>
> > A detailed study shows that Lisp is the 4th most
> > common language used for software in
> > Debian Sarge GNU/Linux repository.
> >
> > Debian GNU/Linux system includes 230 millions of SLOC and the
> > majority is written in C and C++. Shell programming ranks 3rd and
> > the 4th position is occupied by Lisp which beath languages
> > like Perl, Python and Java.
> >
> > The story appears on FM Int:
> >
> > http://www.fazlamesai.net/int/?a=article&sid=15
>
> Now why do I get the distinct feeling that people are going
> to jump all over this thing and tell us how invalid it is?
There seems to be nothing invalid about the statistics. However,
statistics are notorious for tricking people into drawing false
conclusions. Any stat should be (politely) scrutinized.
Assuming almost all of it is Emacs Lisp, I think the proper conclusion
is that Emacs has historically been a fairly successful platform, much
more so than Common Lisp. (But I think it also means there shouldn't be
a deep technical barrier to Common Lisp's success.)
Further, as I think well-macroed Lisps are far more concise than many
other languages, Emacs Lisp does even better than at first glance.
Tayssir
Duane Rettig
> Duane Rettig wrote:
>> Emre Sevinc <em...@bilgi.edu.tr> writes:
>>
>>> A detailed study shows that Lisp is the 4th most common language
>>> used for software in Debian Sarge GNU/Linux repository.
>>>
>>> Debian GNU/Linux system includes 230 millions of SLOC and the
>>> majority is written in C and C++. Shell programming ranks 3rd and
>>> the 4th position is occupied by Lisp which beath languages like
>>> Perl, Python and Java.
>>>
>>>The story appears on FM Int:
>>>
>>>http://www.fazlamesai.net/int/?a=article&sid=15
>> Now why do I get the distinct feeling that people are going
>> to jump all over this thing and tell us how invalid it is?
>
> What part of "there is no such thing as bad publicity" do you not
> understand?! :)
What part of "there is no such thing as bad publicity" do you not
understand?! :)
Two responses to my complaint within 5 minutes. I think that's
pretty good :-)
Duane Rettig
In my younger days, I used to participate in gymnastics, track, and
swimming teams. We would compete, and I was never very good, although
I did improve and I believe am in much better shape nowadays because of
these sports than I would have been without them. These sports are
individual sports, but the meets were team-oriented anyway. I noticed
two different kinds of participants at those meets: there were individuals
who competed for all of the glory, and who went home surrounded by a dark
cloud if they didn't win first place in their event (even if they had
bettered their times over their last competition), and there were
individuals who, whether they did well or not, would root for their
teammates, and who would leave a meet happy if their team had won, even
if they had not. And although coaches had a tendency to dote over their
star athletes, they also tried to inspire the latter kind of attitude,
where team spirit were important enough to be counted as a sign of
good character.
I'd prefer that we Common Lispers look at emacs-lisp in the same way,
as a teammate who has helped our team to do well at a meet, rather than
as a competitor who has stolen glory away from us. And as long as
we are bettering ourselves (i.e. our language) wrt where it has
been before, we should not be going home in a dark cloud of self-loathing
(not that you're doing this, of course; this just fits into my story and
is something I'd want others to avoid doing).
Christopher C. Stacy
> Emre Sevinc wrote:
> > A detailed study shows that Lisp is the 4th most
> > common language used for software in
> > Debian Sarge GNU/Linux repository.
> >
> > Debian GNU/Linux system includes 230 millions of SLOC and the
> > majority is written in C and C++. Shell programming ranks 3rd and
> > the 4th position is occupied by Lisp which beath languages
> > like Perl, Python and Java.
> >
> > The story appears on FM Int:
> >
> > http://www.fazlamesai.net/int/?a=article&sid=15
>
> C is almost, but not entirely a proper subset of C++. Interestingly,
> they are in separate groups, but Emacs Lisp, Scheme and Common Lisp are
> in one.
There's statistics, damn statistics, and LOC statistics.
Robert Uhl
>
> I'd prefer that we Common Lispers look at emacs-lisp in the same way,
> as a teammate who has helped our team to do well at a meet, rather
> than as a competitor who has stolen glory away from us.
Anyone know why Scheme was chosen over Common Lisp for the future of
emacs (not that it looks as though it'll ever come to fruition...)? A
quick Googling didn't turn anything up.
--
Robert Uhl <http://public.xdi.org/=ruhl>
In Faerie one can indeed conceive of an ogre who possesses a castle as
hideous as a nightmare (for the evil of the ogre wills it so), but one
cannot conceive of a house built with a good purpose--an inn, a hostel
for travellers, the hall of a virtuous and noble king--that is yet
sickeningly ugly. At the present day it would be rash to hope to see
one that was not--unless it was built before our time. --J.R.R. Tolkien
Christopher C. Stacy
> Anyone know why Scheme was chosen over Common Lisp for the future of
> emacs (not that it looks as though it'll ever come to fruition...)?
> A quick Googling didn't turn anything up.
I am sure that it's partly due to the fact that Scheme
comes from the group that houses RMS's office; by contrast,
RMS doesn't ever use Common Lisp. Scheme has a history of
being used as a scripting language, and someone already did
a thesis on porting GNU Emacs to Scheme (well enough to run
the "gnus" newsreader in it). And finally, someone has
already written the Scheme ("Guile") interpreter and made
it available under licensing terms that RMS can accept.
Meanwhile on the technical front, at the time the decision was made,
free Common Lisp systems may not have been quite up to the task.
Certainly GCL was not. A lot of improvements in functionality
and bugs and ANSI conformance have been made to the various
non-commercial CL implementations, very recently.
Maybe Lisp newbies would also find it easier to write (very small)
Guile programs than to understand and extend full-blown CL programs.
You could always ask RMS; the above is just my guessing.
Matthew D Swank
> Robert Uhl <eadm...@NOSPAMgmail.com> writes:
>> Anyone know why Scheme was chosen over Common Lisp for the future of
>> emacs (not that it looks as though it'll ever come to fruition...)?
>> A quick Googling didn't turn anything up.
>
...
> You could always ask RMS; the above is just my guessing.
from the emacs wiki (http://www.emacswiki.org/cgi-bin/wiki/CommonLisp):
RichardStallman has chosen not to adopt CommonLisp. He said in this
post, 2003-08-31 on the emacs-devel mailing list, when asked to include
a large part of the cl package into the EmacsLisp core:
I am willing to consider a small number of functions for inclusion
as standard parts of Emacs. I don't have time to consider a large
number, and I can't agree to them without considering them.
I do not like the Common Lisp style of using keyword arguments
for many common functions. I basically do not have a very high
opinion of many of the decisions that were made in Common Lisp.
--
"You do not really understand something unless you can
explain it to your grandmother." — Albert Einstein.
Robert Strandh
> Anyone know why Scheme was chosen over Common Lisp for the future of
> emacs (not that it looks as though it'll ever come to fruition...)? A
> quick Googling didn't turn anything up.
Yes, the idea was to translate other scripting languages into the one
chosen. Therefore, in order to make translation easy, the one chosen
had to be at least as powerful as the ones to be translated. It was
thought that Scheme, with first-class functions and first-class
continuations could easily express most constructs, including things
like exceptions, in other scripting languages.
--
Robert Strandh
Tim X
> Duane Rettig <du...@franz.com> writes:
> >
> > I'd prefer that we Common Lispers look at emacs-lisp in the same way,
> > as a teammate who has helped our team to do well at a meet, rather
> > than as a competitor who has stolen glory away from us.
>
> Anyone know why Scheme was chosen over Common Lisp for the future of
> emacs (not that it looks as though it'll ever come to fruition...)? A
> quick Googling didn't turn anything up.
>
> --
From memory, a while ago it was decided that guile would become the
official "extension language" for all GNU sponsored projects that
incorporated some form of extensibility. However, it was soon realised
that there was just way too much useful functional elisp out there to
replace it all with guile and that elisp wold need to be supported for
a long time even if guile was added as another extension language to
emacs.
So, I think we may still see a guile based plugin for emacs, but
wouldn't expect elisp to be desupported for a long time (if ever). On
one level, I can see the rationale behind GNU supporting and
maintaining just one type of lisp and having a standardised way for
all their official projects to be extended etc, but I think this may
be a case of trying to get the toothpaste back intot he tube - just a
bit late.
Tim
--
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you
really need to send mail, you should be able to work it out!
Ulrich Hobelmann
> from the emacs wiki (http://www.emacswiki.org/cgi-bin/wiki/CommonLisp):
>
> RichardStallman has chosen not to adopt CommonLisp. He said in this
> post, 2003-08-31 on the emacs-devel mailing list, when asked to include
> a large part of the cl package into the EmacsLisp core:
>
> I am willing to consider a small number of functions for inclusion
> as standard parts of Emacs. I don't have time to consider a large
> number, and I can't agree to them without considering them.
That's RMS the maximo lider that has to approve everything :D
> I do not like the Common Lisp style of using keyword arguments
> for many common functions. I basically do not have a very high
> opinion of many of the decisions that were made in Common Lisp.
And I don't like it that RMS rejects design decisions that obviously he
didn't even have the time to consider or understand. I suspect he
prefers Java-style ten-functions-for-one-purpose then.
--
My mouth says the words, my brain is thinking monstertrucks.
Joey (Friends)
Hrvoje Blazevic
> Matthew D Swank wrote:
>
> That's RMS the maximo lider that has to approve everything :D
>
>> I do not like the Common Lisp style of using keyword arguments
>> for many common functions. I basically do not have a very high
>> opinion of many of the decisions that were made in Common Lisp.
>
>
> And I don't like it that RMS rejects design decisions that obviously he
> didn't even have the time to consider or understand. I suspect he
> prefers Java-style ten-functions-for-one-purpose then.
>
That's slightly bellow the belt. Maybe he prefers simplicity of Scheme?
(Although that's probably not true either :-)
Anyway, finally a kindred spirit when talking about keyword arguments. I
too would prefer, say foldr foldr1 foldl foldl1, instead of ceaseless
checking for keyword arguments to REDUCE in CLTL.
-- Hrvoje
Edi Weitz
> Anyway, finally a kindred spirit when talking about keyword
> arguments. I too would prefer, say foldr foldr1 foldl foldl1,
Looks like Scheme is for you...
> instead of ceaseless checking for keyword arguments to REDUCE in
> CLTL.
Have you ever tried SLIME?
Cheers,
Edi.
Hrvoje Blazevic
> On Thu, 15 Sep 2005 11:21:11 +0200, Hrvoje Blazevic <hrv...@despammed.com> wrote:
> Looks like Scheme is for you...
>
>
>>instead of ceaseless checking for keyword arguments to REDUCE in
>>CLTL.
>
>
> Have you ever tried SLIME?
>
Yes I have, but never got as far as actually reading the manual. I guess
then that SLIME can automate searching through CLTL?
-- Hrvoje
Edi Weitz
> Yes I have, but never got as far as actually reading the manual. I
> guess then that SLIME can automate searching through CLTL?
SLIME can automatically look up entries in the CLHS for you. But
that's not what I meant. Just type "(reduce", then press the space
bar, and the argument list for REDUCE will be shown in the mini buffer
- no reason to look up anything.
Ulrich Hobelmann
A actually agree there, because the folds are all somewhat different
(I'd make the start value (the 1) optional, though).
In many cases, however, I think that just having Java overloading or
scheme &rest parameter lists is too much work to express very simple
variations and parametrisations in a given function.
Oh, and you can always DEFUN fold to be reduce with whatever keywords
you like... Getting keyword convenience in elisp or Scheme would be harder.
Förster vom Silberwald
Duane Rettig wrote:
> Now why do I get the distinct feeling that people are going
> to jump all over this thing and tell us how invalid it is?
>
> Already you are getting responses that are attributing it to
> emacs-lisp. So what? Lisp is lisp. Until 1984, there were
> many lisps around, all disjoint and not counted as one at all.
> Now we have two or three that call themselves Lisp, and that
> should be good enough. But rest assured someone will find a
> way to discount the study for one reason or another...
You must see it from this perspective: nobody will call Emacs
programmers genuine programmers. However, it is not wrong to call
CommonLisp programmers real programmers.
It is sometimes how people are recognised and acknowledged. Would you
call Mathemtica or Matlab programmers programmers?
Schneewittchen
PS: Oh yes I for one woul call Emacs, Matlab, Mathematica, etc.
programmer programmers.
Hrvoje Blazevic
> SLIME can automatically look up entries in the CLHS for you. But
> that's not what I meant. Just type "(reduce", then press the space
> bar, and the argument list for REDUCE will be shown in the mini buffer
> - no reason to look up anything.
Neat.
-- Hrvoje
Hrvoje Blazevic
> Oh, and you can always DEFUN fold to be reduce with whatever keywords
> you like... Getting keyword convenience in elisp or Scheme would be
> harder.
>
True. However, this is just a matter of aesthetics. There's a fine line
between this kind of convenience, and syntax burden.
-- Hrvoje
Duane Rettig
> Duane Rettig wrote:
>
>> Now why do I get the distinct feeling that people are going
>> to jump all over this thing and tell us how invalid it is?
>>
>> Already you are getting responses that are attributing it to
>> emacs-lisp. So what? Lisp is lisp. Until 1984, there were
>> many lisps around, all disjoint and not counted as one at all.
>> Now we have two or three that call themselves Lisp, and that
>> should be good enough. But rest assured someone will find a
>> way to discount the study for one reason or another...
>
> You must see it from this perspective: nobody will call Emacs
> programmers genuine programmers. However, it is not wrong to call
> CommonLisp programmers real programmers.
>
> It is sometimes how people are recognised and acknowledged. Would you
> call Mathemtica or Matlab programmers programmers?
What does the question of whether a person is a programmer have to
do with this discussion?
> Schneewittchen
> PS: Oh yes I for one woul call Emacs, Matlab, Mathematica, etc.
> programmer programmers.
Then why did you set this strawman argument up, only to knock it
down again? To what purpose?
Richard Fateman
>
> <snip>
> C is almost, but not entirely a proper subset of C++. Interestingly,
> they are in separate groups, but Emacs Lisp, Scheme and Common Lisp are
> in one.
>
So is your point that
if one groups C and C++ as "the same language",
then Lisp comes in 3rd instead of 4th?
Förster vom Silberwald
> What does the question of whether a person is a programmer have to
> do with this discussion?
Whether a person feels like a programmer is irrelevant. However, what
counts: whether a person actually is recognised as a programmer.
Have you ever seen a book: "Learn programming by means of Emacs" -
haven't you?
Neither Lisp nor Scheme (my favorite language) are big players under
Linux, even. Truth is ...
First, one should check whether he counts Emacs as a real programming
language. It is a straw-man argument saying Lisp and Scheme play a
dominant role among Unix/Linux platforms since that particular Lisp is
based on Emacs-Lisp.
Schneewittchen
Kent M Pitman
Funny. I think that keywords will one day be seen as one of the very
important features of CL. They provide redundancy of information,
lessening syntax errors. They are statically compilable, so they
don't reduce speed. And they permit flexible re-ordering of arguments
in order to manage side-effects.
This is also not the first time I've seen someone fail to take good
ideas from something just to make what seems to amount to a political
point. Good ideas are good ideas regardless of their source. To
dismiss all aspects of a past effort you don't like just because you
don't like its totality seems silly. There may be individual reasons
to dismiss each and every design decision of CL, and that's fine. But
dismissing something in bulk isn't very scientific...
Personally, I think what Stallman doesn't like about CL is that he
didn't design it. And I'd have more respect for him if he just said
that plainly, since then it could at least be addressed head on. But
making something gratuitously incompatible when it's "in range" seems
an exercise in ego foisted upon a community of users which seems to
feel obliged to tolerate it. If I were them, in response to what he
says, I would take the source and make it ANSI CL compatible anyway,
and just leave him behind. Isn't that the whole point of open source?
Why is what he is willing to consider even relevant?
Duane Rettig
> Duane Rettig wrote:
>
>> What does the question of whether a person is a programmer have to
>> do with this discussion?
>
> Whether a person feels like a programmer is irrelevant. However, what
> counts: whether a person actually is recognised as a programmer.
>
> Have you ever seen a book: "Learn programming by means of Emacs" -
> haven't you?
But you just finished saying that you yourself believe that emacs
lisp is a programming language (i.e. its programmers are indeed
programmers). And since I also believe this, where's the disagreement?
> Neither Lisp nor Scheme (my favorite language) are big players under
> Linux, even. Truth is ...
Ah, keep things separate, eh? Every language dialect must stand
on its own, or fall?
> First, one should check whether he counts Emacs as a real programming
> language. It is a straw-man argument saying Lisp and Scheme play a
> dominant role among Unix/Linux platforms since that particular Lisp is
> based on Emacs-Lisp.
Look up what a "straw man argument" is. It's certainly not me that
is putting up that argument as a strawman; I believe the argument. Lisp
is lisp, and I refuse to denegrate emacs-lisp just because it overshadows
my own favorite Lisp (which happens to be Common Lisp).
Lars Brinkhoff
> If I were them, in response to what he says, I would take the source
> and make it ANSI CL compatible anyway, and just leave him behind.
> Isn't that the whole point of open source? Why is what he is
> willing to consider even relevant?
I believe RMS has the final say over any change to GNU Emacs, and the
developers seem happy with this. Or, it's my impression that if there
is a group of developers that want to break off and create their own
fork, they either aren't very interested in Common Lisp, or they are
too few to get the work done.
Harald Hanche-Olsen
Indeed the cost of forking a project can be prohibitive. And if
you're not willing to pay that cost, you have to go along with whoever
owns the project. Erik Naggum started a project to common-lispify
emacs a number of years ago, but gave up on it. I don't know how much
time he spent on it, or how far he got. But the obvious lesson is
that this is a non-trivial undertaking.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Pascal Costanza
> Funny. I think that keywords will one day be seen as one of the very
> important features of CL. They provide redundancy of information,
> lessening syntax errors. They are statically compilable, so they
> don't reduce speed. And they permit flexible re-ordering of arguments
> in order to manage side-effects.
Furthermore, they allow you to evolve code by extending an argument list
without affecting all call sites. You can then only change the call
sites that actually need the new argument. (I think the advantages you
mention are good points, but this one is something that buys you a real
technical advantage IMHO.)
Pascal
--
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++
Pascal Costanza
> + Lars Brinkhoff <lars...@nocrew.org>:
>
> | Kent M Pitman <pit...@nhplace.com> writes:
> | > If I were them, in response to what he says, I would take the source
> | > and make it ANSI CL compatible anyway, and just leave him behind.
> | > Isn't that the whole point of open source? Why is what he is
> | > willing to consider even relevant?
> |
> | I believe RMS has the final say over any change to GNU Emacs, and the
> | developers seem happy with this. Or, it's my impression that if there
> | is a group of developers that want to break off and create their own
> | fork, they either aren't very interested in Common Lisp, or they are
> | too few to get the work done.
>
> Indeed the cost of forking a project can be prohibitive. And if
> you're not willing to pay that cost, you have to go along with whoever
> owns the project. Erik Naggum started a project to common-lispify
> emacs a number of years ago, but gave up on it. I don't know how much
> time he spent on it, or how far he got. But the obvious lesson is
> that this is a non-trivial undertaking.
Don't forget about the projects that reimplement Emacs from scratch in
Common Lisp. There is some noticeable progress being made there.
Kent M Pitman
> + Lars Brinkhoff <lars...@nocrew.org>:
>
> | Kent M Pitman <pit...@nhplace.com> writes:
> | > If I were them, in response to what he says, I would take the source
> | > and make it ANSI CL compatible anyway, and just leave him behind.
> | > Isn't that the whole point of open source? Why is what he is
> | > willing to consider even relevant?
> |
> | I believe RMS has the final say over any change to GNU Emacs, and the
> | developers seem happy with this. Or, it's my impression that if there
> | is a group of developers that want to break off and create their own
> | fork, they either aren't very interested in Common Lisp, or they are
> | too few to get the work done.
>
> Indeed the cost of forking a project can be prohibitive. And if
> you're not willing to pay that cost, you have to go along with whoever
> owns the project. Erik Naggum started a project to common-lispify
> emacs a number of years ago, but gave up on it. I don't know how much
> time he spent on it, or how far he got. But the obvious lesson is
> that this is a non-trivial undertaking.
I think this is true, but it's interesting that free software is often
"sold" on the basis of the availability of this as an option. So it's
interesting to see that even when no money is at stake, the phenomenon
of "marketingspeak" is in play...
(In case that's too vague a remark, I'll add a strawman definition of
marketingspeak as the use of statements that are almost always true,
and yet just as often irrelevant, incomplete, out-of-context, or
otherwise misleading usually not for what they say but what they omit.)
Dave Roberts
"Tayssir John Gabbour" <tayss...@yahoo.com> writes:
> Assuming almost all of it is Emacs Lisp, I think the proper conclusion
> is that Emacs has historically been a fairly successful platform, much
> more so than Common Lisp. (But I think it also means there shouldn't be
> a deep technical barrier to Common Lisp's success.)
I had a thought the other day that Lisp Machines never really
died. Oh, sure, the hardware went away. We just replaced them with
Unix systems running Emacs instead. ;-) Seriously, it's interesting
how good old elisp-based Emacs has grown way beyond text editing. I
used to joke with a friend who is an Emacs freak (to the point of
virtually living for days in a single Emacs session) that Unix is just
the Emacs boot-loader.
--
Dave Roberts
dave -remove- AT findinglisp DoT com
http://www.findinglisp.com/
Pascal Bourguignon
> I had a thought the other day that Lisp Machines never really
> died. Oh, sure, the hardware went away. We just replaced them with
> Unix systems running Emacs instead. ;-) Seriously, it's interesting
> how good old elisp-based Emacs has grown way beyond text editing. I
> used to joke with a friend who is an Emacs freak (to the point of
> virtually living for days in a single Emacs session) that Unix is just
> the Emacs boot-loader.
What do you mean? You can use it for something else?
http://www.informatimago.com/linux/emacs-on-user-mode-linux.html
--
__Pascal Bourguignon__ http://www.informatimago.com/
I need a new toy.
Tail of black dog keeps good time.
Pounce! Good dog! Good dog!
Kent M Pitman
> Kent M Pitman wrote:
>
> > Funny. I think that keywords will one day be seen as one of the very
> > important features of CL. They provide redundancy of information,
> > lessening syntax errors. They are statically compilable, so they
> > don't reduce speed. And they permit flexible re-ordering of arguments
> > in order to manage side-effects.
>
> Furthermore, they allow you to evolve code by extending an argument
> list without affecting all call sites. You can then only change the
> call sites that actually need the new argument. (I think the
> advantages you mention are good points, but this one is something that
> buys you a real technical advantage IMHO.)
Yes, I think this is one of the reasons Paul Graham seems to be a big
fan of them.
Note, too, apropos a related thread, that keywords are among the things
that are natural-language-like about CL. They are very like prepositional
guide words. "Give the ball to John".
Harlequin had a product called WebMaker that translated FrameMaker MIF
format files to HTML using a rule language. I implemented an
extension to that language that allowed you to name arguments and
still also use them positionally, so that you could implement the full
set of
Give John the ball.
Give to John the ball.
Give the ball to John.
by basically first processing keywords and then coming back and filling
in keywords. e.g.,
(defun give (&key direct-obj to) ...)
(give ball :to john) ; keyword :to only, one positional arg
(give :to john ball) ; keyword :to only, one positional arg
(give :to john :direct-obj ball) ; keywords :to and :direct-obj
(give :direct-obj ball :to john) ; keywords :to and :direct-obj
It's perhaps tricky to compile, but it was cool to use.
It's possible that some additional constraint such as not allowing args
to evaluate to keywords would help, but one has to be careful not to lock
out the ability to use APPLY to merge keyword lists that come from two
different places, so it's not quite as simple as that. Nevertheless, I
consider it a virtue of Lisp that it's willing to dive into an area like
this, get some user experience, and then evolve.
Incidentally, while I'm listing things I would do differently with keywords,
the other things on my list are:
&key should be :key. The whole presence of &keywords in CL is needless.
(We fixed this in ISLISP, which takes :rest and :optional.)
I pushed during the early design of CL to have keywords be a different
datatype, not symbols. It never happened, in spite of promises from
some at the time that we would reconsider this issue later. I've come
to the belief that the right datatype is STRING. That is, that
keywords should be what I think Java calls "canonical
strings"--immutable strings that are possible to compare with EQ.
A thing that has often troubled me is "symbol proliferation", that is,
that there are a zillion keywords whose only purpose is to serve as the
guide words for same-named variables. When you do &key x, you implicitly
also create :x. It's not a huge deal, but it would be cool if
(eq (symbol-name 'x) :x), since it would save space. It would also mean
:rest and :optional in keyword lists could be recognized by their
stringness, not by being "also symbols, just ones that happen to be
in the keyword package" (a kind of weirdness that harkens back to the
days of CLTL1, and earlier, when lists whose car was LAMBDA were
counted as FUNCTIONP).
Perhaps the above are some fun things people who have their own lisps
percolating could give a try with...
Joe Marshall
> That is, that keywords should be what I think Java calls "canonical
> strings" --- immutable strings that are possible to compare with EQ.
Er, isn't that usually called a `symbol'? Yeah, there are some other
fields generally associated with a symbol, but being immutable,
interned, and symbolic (human readable) are the essence of symbolhood.
Kent M Pitman
Scheme might call it a symbol, but no CL.
Symbols have plists, value cells, and function cells.
I think it would be useful to have an intermediate datatype.
Kent M Pitman
Oops. A little voice in my head was saying "four" and I could only
think of three things. Packages. Symbols also have packages.
Moreover, you can shadow normal symbols. You can't shadow keywords.
Hence the remark about Scheme, which has no real way to package and
shadow symbols, and consequently a need for separate facilities to
manage macro hygiene (which is handled implicitly in other ways in CL).
Thomas F. Burdick
> Pascal Costanza <p...@p-cos.net> writes:
>
> > Kent M Pitman wrote:
> >
> > > Funny. I think that keywords will one day be seen as one of the very
> > > important features of CL. They provide redundancy of information,
> > > lessening syntax errors. They are statically compilable, so they
> > > don't reduce speed. And they permit flexible re-ordering of arguments
> > > in order to manage side-effects.
> >
> > Furthermore, they allow you to evolve code by extending an argument
> > list without affecting all call sites. You can then only change the
> > call sites that actually need the new argument. (I think the
> > advantages you mention are good points, but this one is something that
> > buys you a real technical advantage IMHO.)
>
> Yes, I think this is one of the reasons Paul Graham seems to be a big
> fan of them.
>
> Note, too, apropos a related thread, that keywords are among the things
> that are natural-language-like about CL. They are very like prepositional
> guide words. "Give the ball to John".
When you put it that way, it raises another posibility. Instead of
using keywords, we could just decline a function's arguments. That
would make it easier to pass along keywords. Instead of
(defun give (obj &key to)
(if (far-away-p to)
(throw obj :to to)
(hand obj :to to)))
we'd have
(defun give ((obj direct-object) (to indirect-object))
(if (far-away-p to)
(throw to obj)
(hand obj to)))
Not that I really want to write
(give (decline *ball* 'indirect-object) (decline *dog* 'direct-object))
But I do think it's a cut idea to allow the keyword that an argument
is associated with to tag along with the argument itself.
--
/|_ .-----------------------.
,' .\ / | Free Mumia Abu-Jamal! |
,--' _,' | Abolish the racist |
/ / | death penalty! |
( -. | `-----------------------'
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick
> Dave Roberts <dave-...@remove-findinglisp.com> writes:
> > I had a thought the other day that Lisp Machines never really
> > died. Oh, sure, the hardware went away. We just replaced them with
> > Unix systems running Emacs instead. ;-) Seriously, it's interesting
> > how good old elisp-based Emacs has grown way beyond text editing. I
> > used to joke with a friend who is an Emacs freak (to the point of
> > virtually living for days in a single Emacs session) that Unix is just
> > the Emacs boot-loader.
>
> What do you mean? You can use it for something else?
> http://www.informatimago.com/linux/emacs-on-user-mode-linux.html
Wimps, relying on the huge Linux kernel -- they should have tried it
with Mach.
David Steuber
> I'd prefer that we Common Lispers look at emacs-lisp in the same way,
> as a teammate who has helped our team to do well at a meet, rather than
> as a competitor who has stolen glory away from us. And as long as
> we are bettering ourselves (i.e. our language) wrt where it has
> been before, we should not be going home in a dark cloud of self-loathing
> (not that you're doing this, of course; this just fits into my story and
> is something I'd want others to avoid doing).
Wouldn't SLIME be in this very spirit? It is written in both Emacs
Lisp and Common Lisp for the purpose of improving Common Lisp
development.
--
You should maybe check the chemical content of your breakfast
cereal. --- Bill Watterson
Alain Picard
> used to joke with a friend who is an Emacs freak (to the point of
> virtually living for days in a single Emacs session)
Watch who you're calling a freak. I've had emacs sessions
live longer than the average uptime of most Windows boxes.
Granted, that's not a very difficult feat.
:-)
Richard Fateman
peoplesparc.CS.Berkeley.EDU% ps -ef | grep emacs
fateman 498 488 0 May 11 ? 46:46 emacs
Not unusual for Peoplesparc to run continuously between
power failures. A Sun Sparc of some sort. So emacs
runs for a long time. But keep on reading, for an
even better deal.
That emacs is mostly used for monitoring a remote
program running a web server. Also on a Sun.
That program, Tilu, is written in Allegro Common Lisp,
and that job has been running since May 11, too.
You can visit it at http://torte.cs.berkeley.edu:8010/tilu
It looks up symbolic integrals in a table. It has been
running most of the time since 1996. The machine it runs
on has been declared "unmaintained" so the next time
it crashes it may not be revived. It's been running for
months that way.
RJF
Pascal Bourguignon
> Not that I really want to write
>
> (give (decline *ball* 'indirect-object) (decline *dog* 'direct-object))
>
> But I do think it's a cut idea to allow the keyword that an argument
> is associated with to tag along with the argument itself.
But it would be a nice lispigata; you could write indifferently:
(ballus dogo oferte)
(ballus oferte dogo)
(oferte ballus dogo)
http://www.csse.monash.edu.au/~damian/papers/HTML/Perligata.html
That would make a nice notation too for those who don't like aref:
(primi dogorum) or (dogorum primi) <---> (aref dog 0)
It's even possible that we could do without the parentheses, since
there's enough grammar for the parser to build the syntax tree. You
would need indeed utility functions to ease macro writting.
I think we would need to retain more declinations than in perligata...
We could use another verb declination for macros vs. functions.
If I had time, I'd love to write this lispigata. Should be a nice
project for this year students ;-)
--
__Pascal Bourguignon__ http://www.informatimago.com/
In deep sleep hear sound,
Cat vomit hairball somewhere.
Will find in morning.
BR
> It looks up symbolic integrals in a table. It has been running most of
> the time since 1996. The machine it runs on has been declared
> "unmaintained" so the next time it crashes it may not be revived. It's
> been running for months that way.
Hmmm...what would be the longest running computer?
David Steuber
> Harald Hanche-Olsen <han...@math.ntnu.no> writes:
>
> > + Lars Brinkhoff <lars...@nocrew.org>:
> >
> > Indeed the cost of forking a project can be prohibitive. And if
> > you're not willing to pay that cost, you have to go along with whoever
> > owns the project. Erik Naggum started a project to common-lispify
> > emacs a number of years ago, but gave up on it. I don't know how much
> > time he spent on it, or how far he got. But the obvious lesson is
> > that this is a non-trivial undertaking.
>
> I think this is true, but it's interesting that free software is often
> "sold" on the basis of the availability of this as an option. So it's
> interesting to see that even when no money is at stake, the phenomenon
> of "marketingspeak" is in play...
I think forking of free software is more an exception than a rule.
According to du -h, there are 208MB of data in my emacs directory from
CVS and building.
That includes 1043 .el files consisting of 1183775 lines as per:
$ find emacs -name '*.el' | xargs cat | wc -l
188 .c files consisting of 338683 lines
315 .h files consisting of 46456 lines
That's a fair sized program to redo in Common Lisp.
I don't think they will get it switched over to guille anytime soon.
Kent M Pitman
...
> I think forking of free software is more an exception than a rule.
>
> According to du -h, there are 208MB of data in my emacs directory from
> CVS and building.
>
> That includes 1043 .el files consisting of 1183775 lines as per:
>
> $ find emacs -name '*.el' | xargs cat | wc -l
>
> 188 .c files consisting of 338683 lines
> 315 .h files consisting of 46456 lines
>
> That's a fair sized program to redo in Common Lisp.
>
> I don't think they will get it switched over to guille anytime soon.
For comparison, when I was at Symbolics in 1986 on hardware quite a
bit slower than modern hardware, Macsyma (about 100,000 lines of code)
took me about 3 months to convert from a Maclisp/Franz/Zetalisp mix to
Common Lisp (CLTL1), and perhaps a few more months to debug, since the
actual semantics of both the source and target dialects were pretty iffy.
I had some tools that worked pretty well interactively on specified
expressions, offering a fine degree of control but losing comments.
(They could, of course, be repatriated as a post-pass.) Dave Moon
[I think it was] wrote some even cooler tools that even preserved
comments. I didn't even have Dave's tools to work with, and I think
maybe some of the rules they used were based on the results of what I
learned in my conversion. (These tools might be used either directly
on Genera or similar tools made for present-day Emacs. I can't emphasize
enough the importance of good tools when doing a lot of repetitive
tasks, but yet people often don't do that if they don't stop to
analyze what is repetitive about what they are doing and they think it
all a judgment task, which translation is simply not.)
I've also converted several other large packages of code to Common Lisp,
including Zmacs itself to Common Lisp.
http://groups.google.com/group/comp.lang.lisp/msg/e0a0fa357f4f0a69?hl=en&
And a lot of the work setting up conversions is doing the initial work.
Once you get the basic conversions in place, the number of lines is not
as relevant as the time it takes to work out the subroutine base and
the conversion strategy. So I'm not sure the work scales linearly in
the number of lines. If I had to make it proportional to something, I'd
say make it proportional to the number of "hard differences" between the
two languages. For example, in the Zmacs conversion, the two things Moon
had told me were going to be really hard were (as mentioned in the above
article) array leaders and special instance variables. These were
significant problems and ended up having to be solved on a per-use
basis. (Not per-site-in-code, but per-paradigm, since some variables
could be changed one way and some another, and then all their clients
had to know that the access paradigm was different.)
Likewise in Maclisp->CL there were particular "hard problems". I have
a list somewhere I plan to web sometime, but they included things like
the Maclisp division function, which was overloaded, not generic. That
is, (quotient 3 2) => 1 but (quotient 3 2.0) => 1.5, so if you saw
(quotient x y), you had a real problem. [This was trivially fixed by
introducing an alien function CL-USER::QUOTIENT that accomplished just
this, but that inhibited efficient compilation, so required special
treatment.] There were also just tedious syntax issues like that /
was used in Maclisp for what \ was used for in CL, but the conversion
was not entirely mechanical because although // became \/, variable
names like 1//2 neihter wanted to become 1\/2 nor 1/2. It took a few
days to do this conversion.
In converting Macsyma, I also got a lot of mileage in going breadth
first in these tasks, not having to revisit solved problems. I was
advised to do depth-first so my managers could gauge progress
properly, but I told them it would be inefficient. They feared doing
breadth-first because the entire system could not be tested until the
entire work was done. (Then again, I was the only person using the
system during this time, so testing seemed irrelevant to me.) In the
end, what I did was push out the time at which I promised a
depth-first conversion of one module as far as I could and then did
the entire conversion breadth-first in the same period of time, before
my first milestone, so I could do it my way. I suppose that was
risky. But I still think breadth first was the most efficient way to
go, in spite of the inability to do checking along the way... or maybe
because of it. That is, maybe checking all the time would have just
slowed things down.
What was really needed was a good set of regressions that checked
basic behavior before and after, and Macsyma had a lot of test cases.
It was a bit harder to test my Zmacs port. Mostly I just did spot
checking of commands that did various actions, and at some point I
started using it for my own editing. (I had Zmacs on the key sequence
Select E and CL Zmacs on Select Epsilon, so I could easily go between
them doing testing.) I did a similar thing with Macsyma, having both
Macsyma and Climax (CL Macsyma) loaded at the same time on select A
and Select Alpha--with tools that could run the same test in both,
comparing results. But I think that's really no different than having
two different versions of LispWorks or two different Emacs versions
loaded on a conventional platform, which I do all the time on Linux
and even sometimes on Windows.
So all this to say I'm not just idly speculating when I say that it
should be possible, given the energy I've seen in the open source
community, to do a port to ANSI CL in relatively finite time. But
it's full-time work for two, maybe three, people for a year. And
perhaps part-time work for some others. And what I said about
breadth-first above might not apply if more people were working on
things. I'd personally still go breadth-first across a core of
libraries to get a working system, but for optional modules, they
could perhaps be farmed out to volunteers to achieve parallelism, once
a conversion strategy was articulated. I bet a lot of those libraries
are optional, and that might reduce the amount of time until you
had a working core to a matter of a few months.
There is, of course, the "little detail" of making sure the core Lisp
platform you are using actually has all the functionality you want. A
lot of translation is just syntax. But in the end, if you don't have
something that can do the system operations (files, windowing, etc.)
that the original Emacs could, you have to get that in place. But at
least that can be done as a modularly separate task either beforehand
or co-routined in an on-demand way by someone committed to the timely
success of the project.
I'd welcome commentary from anyone [Erik?] who has tried a conversion
effort of this kind already as to whether any of the above analysis
is flawed...
Julian Stecklina
> Pascal Bourguignon <sp...@mouse-potato.com> writes:
>
>> Dave Roberts <dave-...@remove-findinglisp.com> writes:
>> > I had a thought the other day that Lisp Machines never really
>> > died. Oh, sure, the hardware went away. We just replaced them with
>> > Unix systems running Emacs instead. ;-) Seriously, it's interesting
>> > how good old elisp-based Emacs has grown way beyond text editing. I
>> > used to joke with a friend who is an Emacs freak (to the point of
>> > virtually living for days in a single Emacs session) that Unix is just
>> > the Emacs boot-loader.
>>
>> What do you mean? You can use it for something else?
>> http://www.informatimago.com/linux/emacs-on-user-mode-linux.html
>
> Wimps, relying on the huge Linux kernel -- they should have tried it
> with Mach.
Pah, relying on the huge Mach kernel, try it with L4. :)
Regards,
--
Julian Stecklina
When someone says "I want a programming language in which I
need only say what I wish done," give him a lollipop. - Alan Perlis
Rob Warnock
+---------------
| Richard Fateman wrote:
| > It has been running most of time since 1996...
|
| Hmmm...what would be the longest running computer?
I dunno, but two of my FreeBSD machines at home have been up for a
reasonably long time:
% uptime
7:38PM up 395 days, 11:09, 12 users, load averages: 0.00, 0.00, 0.00
% ssh ${ANOTHER} uptime
7:38PM up 1006 days, 13:40, 0 users, load averages: 0.15, 0.03, 0.01
%
Note that 1006 days is exactly the time since I installed a small UPS!! ;-}
Before that, they were crashing several times a month due to short-
duration power outages (typ. under 5 seconds). I explicitly rebooted
the first one [my main server] about a year ago for some reason, but
I forgot why. Mostly they just run & run & run, as does the CMUCL
process that runs a persistent application server [behind Apache].
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Thomas F. Burdick
> t...@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > Pascal Bourguignon <sp...@mouse-potato.com> writes:
> >
> >> Dave Roberts <dave-...@remove-findinglisp.com> writes:
> >> > I had a thought the other day that Lisp Machines never really
> >> > died. Oh, sure, the hardware went away. We just replaced them with
> >> > Unix systems running Emacs instead. ;-) Seriously, it's interesting
> >> > how good old elisp-based Emacs has grown way beyond text editing. I
> >> > used to joke with a friend who is an Emacs freak (to the point of
> >> > virtually living for days in a single Emacs session) that Unix is just
> >> > the Emacs boot-loader.
> >>
> >> What do you mean? You can use it for something else?
> >> http://www.informatimago.com/linux/emacs-on-user-mode-linux.html
> >
> > Wimps, relying on the huge Linux kernel -- they should have tried it
> > with Mach.
>
> Pah, relying on the huge Mach kernel, try it with L4. :)
L4? That obese thing? If they were real men, they'd have used the
KeyKOS nanokernel :-)
Kent M Pitman
I found myself wanting to ponder this question but found I didn't have a
good notion of what the words "running" and "computer" meant...
Is an abacus a computer? If it is extant, is it running? A sundial?
What about a babbage machine? A person? Do machines that go to sleep
continue to run while they are asleep? Now Oracle has these server
farms where if one server goes down, the rest continue. Does that
count as continuous? It gets all very blurry to me any more...
Kind of reminds me of people who talk about the Internet as "up" or "down".
As if it could ever (again) be so binary...
BR
> I found myself wanting to ponder this question but found I didn't have a
> good notion of what the words "running" and "computer" meant...
*smile*
[OOP]
http://osnews.com/permalink.php?news_id=11910&comment_id=33157
[Object]
http://osnews.com/permalink.php?news_id=11910&comment_id=33197
Well you and the above gentlemen would get along swimmingly.
Rob Warnock
+---------------
| Kind of reminds me of people who talk about the Internet as "up"
| or "down". As if it could ever (again) be so binary...
Well, with some of those DDoS attacks against the DNS root servers... ;-}
Your post also reminds me of those who consider "the Internet" to
be down when they can't reach some particular service, e.g., Google.
[Though maybe they have a point. If you can't get to *Google*...] ;-}
Lars Brinkhoff
> should be possible, given the energy I've seen in the open source
> community, to do a port to ANSI CL in relatively finite time.
I don't think anyone is disputing that it's possible. It's just a lot
of work (as you note), and neither the GNU Emacs or XEmacs developers
seem very interested in a conversion. Those who are interested don't
have enough resources.
> There is, of course, the "little detail" of making sure the core
> Lisp platform you are using actually has all the functionality you
> want. A lot of translation is just syntax.
The elisp code wouldn't necessarily have to be translated to CL. It
could be ran in a elisp implementation written in CL, and that problem
has been solved at least twice.
The bigger problem, I believe, is translating the large body of
functions written in C, and that translation isn't exactly "just
syntax".
> I'd welcome commentary from anyone [Erik?] who has tried a
> conversion effort of this kind already as to whether any of the
> above analysis is flawed...
I think most of the previous and current efforts are reimplementations
from scratch.
Didier Verna
> I don't think anyone is disputing that it's possible. It's just a lot
> of work (as you note), and neither the GNU Emacs or XEmacs developers
> seem very interested in a conversion. Those who are interested don't
> have enough resources.
That pretty much describes the current situation (for XEmacs at least)
indeed. But I would add one more thing: in our case, if we were to switch to a
more modern Lisp dialect, I suspect that would start a very hot flamewar
between those who want Scheme and those who want CL.
--
Didier Verna, did...@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bicętre, France Fax.+33 (1) 53 14 59 22 did...@xemacs.org
Christian Lynbech
Ingvar> However, there's (as noted) one hell of a lot of "elisp" code
Ingvar> that's written in C
Although there be many such functions in a raw count, the amount of
functions that will matter to high-level libraries such as as
'calendar' or 'gnus' would be smaller. A lot of elisp code uses only a
handful of abstractions such as buffers and windows with the
associated datastructures and accessors.
And one should not forget that even though emacs ships with a lot of
code, the real problem (or challenge as one may see it) is all of the
gazillion big and small extensions out there in the community that is
not part of the core distribution.
------------------------+-----------------------------------------------------
Christian Lynbech | christian #\@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- pet...@hal.com (Michael A. Petonic)
Christopher C. Stacy
> >>>>> "Ingvar" == Ingvar <ing...@hexapodia.net> writes:
>
> Ingvar> However, there's (as noted) one hell of a lot of "elisp" code
> Ingvar> that's written in C
>
> Although there be many such functions in a raw count, the amount of
> functions that will matter to high-level libraries such as as
> 'calendar' or 'gnus' would be smaller.
gnus was already ported to Scheme as someone's B.S.
(making an elisp environment in Scheme) years ago.
So this can't be an intractable problem.