hi,
Do you know if there's another elisp compiler, or if the elisp compiler
from emacs can be
somehow magically separated from the editor?
I've heard that there is an elisp emulator for clisp, do you know more
about this?
thanks.
cu,
Martin Schmidt
* Martin Schmidt wrote:
> hi,
> Do you know if there's another elisp compiler, or if the elisp compiler
> from emacs can be
> somehow magically separated from the editor?
I think there once was such a thing, or part of one, but I forget the
details. It's kind of not very interesting because the interesting
thing about elisp is really the million emacs primitives and billion
library functions. I can't really see what you'd use an elisp system
without emacs *for*!
If you want to run elisp without `being in a text editor' then I think
`emacs -batch' is your friend.
--tim
>>>>> "Tim" == Tim Bradshaw <···@cley.com> writes:
Tim> If you want to run elisp without `being in a text editor' then I think
Tim> `emacs -batch' is your friend.
One could also rip out the lisp machinery from the emacs sources to do
a standalone lisp without all the extra editing stuff. This is not
that difficult, a former colleague reported, after doing the exercise
a few years back.
One could then use the ordinary emacs lisp compiler as usual.
It is of course not obvious of what practical use such a system would be.
A more rewarding approach would of course be to write some Common Lisp
code that was able to read in emacs lisp code and thus effectively
convert it to Common Lisp.
------------------------+-----------------------------------------------------
Christian Lynbech | Ericsson Telebit, Skanderborgvej 232, DK-8260 Viby J
Phone: +45 8938 5244 | email: ·················@ted.ericsson.dk
Fax: +45 8938 5101 | web: www.ericsson.com
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
Martin Schmidt <·······@gmx.net> writes:
> or is there an elisp to <another language, e.g. perl> compiler?
> thanks in advance.
There is a (partial) compiler from ELisp to Java bytecodes.
See http://JEmacs.net and http://www.gnu/org/software/kawa/
To compile an ELisp file with Kawa, do:
java kawa.repl --elisp -C hello.el
which creates the file hanoi.class.
JEmacs does support a good chunk of Emacs Lisp, but I haven't had much
time to work on it lately.
--
--Per Bothner
···@bothner.com http://www.bothner.com/~per/
Per Bothner <···@bothner.com> writes:
> Martin Schmidt <·······@gmx.net> writes:
>
> > or is there an elisp to <another language, e.g. perl> compiler?
> > thanks in advance.
>
> There is a (partial) compiler from ELisp to Java bytecodes.
> See http://JEmacs.net and http://www.gnu/org/software/kawa/
I used to think very highly of such projects, but nowadays I think
that they're a serious waste of time. For this project, for example:
o GNU Emacs and XEmacs are already very highly portable across
platforms.
o Elisp works just fine on these platforms, and though the elisp
compiler that comes with XEmacs isn't so hot, it does the job.
o Most Lisp users want to use Lisp, and many (e.g. people on this
group) wished that elisp would be more CL-like, and do not wish to
move to either Scheme or Java.
If there were a serious platform on which Emacs or XEmacs didn't run,
but there were people wanting it there, then I might see the utility
of such a project.
I got lambasted about 4 or 5 years ago on comp.emacs.xemacs for
suggesting that the Elisp compiler instead compile into JVM bytecode;
that way, for all the money being put into Java technology, our
emacsen would benefit. It took me a while to see it.
A much more worthwhile project would be to implement (X)Emacs purely
in Common Lisp. This, of course, wouldn't be easy, but CL already has
a nice interface to X (and if the Windows junkies don't like X, then
they can get Xwin32, VNC, Exceed (sp?), or something), and I think
that Elisp can fully be written in Common Lisp, simply as a separate
package (and some clever hacking to handle the dynamic scoping rules
of elisp), and portable modifications to the reader.
The big savings here would be avoiding the writing of the Emacs Lisp
compiler, avoiding C and all its heinousness, and the ability to use a
real language environment. In fact, I am dumbfounded that it hasn't
been done yet in Common Lisp, especially considering that it's been
done in OCaml already! I know that people have mentioned and spoke of
it, but as far as I know, it doesn't exist in CL.
One part that might be tricky is the tty-mode version. I don't know
if CL interfaces exist to all of the libraries such as ncurses, but
most good CLs an easily link to .so files, and so with a single header
file-reading FFI code generator that works well (e.g. CormanLisp's),
making a lot of this actually feasible.
I think the only real problem with Emacs in CL would be the
_interference_ between CL and elisp in where they differ. Something
like (require 'cl) would be rediculous; it would be the other way
around.
I think that the level of brain damage in XEmacs's garbage collector
and elisp compiler might cancelled out by the more sane redesign
inside a good CL implementation, making the result near-equal in
performance, except, probably with respect to display.
Also, in such a project, the real goal is to get rid of the C backend
to the elisp compiler and to make CL the *real* extension language,
controlling the main loop; not to necessarily get rid of C
altogether. So of course, no one would complain if a CL (X)Emacs used
standard libraries (e.g. libncurses.so), but it probably wouldn't hurt
to bundle some of the useful stuff in XEmacs in either, as it might
save some work (at least initially).
I should end by saying that this is probably a good project for me to
attempt, since the src to XEmacs is all open, and it would be an
excellent learning experience, and it's something I've always wanted,
and I'd like it much more than XEmacs as-is, with its current
extension language.
Lastly, one nice thing that may come of such a project is a *real*
IDE/debugger for Common Lisp. Every debugger I've seen commercially
for Common Lisp is seriously lacking in line-by-line debugging. Even
edebug is light years ahead of any CL I've seen in this respect.
dave
David Bakhash <·····@alum.mit.edu> writes:
> Per Bothner <···@bothner.com> writes:
>
> > There is a (partial) compiler from ELisp to Java bytecodes. See
> > http://JEmacs.net and http://www.gnu/org/software/kawa/
>
> I used to think very highly of such projects, but nowadays I think
> that they're a serious waste of time. For this project, for
> example:
[...]
> o Elisp works just fine on these platforms, and though the elisp
> compiler that comes with XEmacs isn't so hot, it does the job.
Well, one thing that would be nice is to take advantage of the free
JIT-compilers out there. Especially since I think many people
(including me) keep their Emacs running for weeks at a time, this
could be a big win.
>>>>> On Sat, 10 Mar 2001 20:24:16 GMT, David Bakhash ("David") writes:
David> A much more worthwhile project would be to implement (X)Emacs purely
David> in Common Lisp.
...
David> The big savings here would be avoiding the writing of the Emacs Lisp
David> compiler, avoiding
The current Emacs implementation provides for delivery of an executable
Emacs distribution (and optionally the source code, but most users,
especially on Windows, do not have the tools to build it from source.)
Emacs includes a byte compiler for its own extension language.
If one were to reimplement Emacs in Common Lisp and (use presumably
also using Common Lisp as the extension language), what Lisp compiler
would be included in the end-user binary and source distributions?
Christopher Stacy <······@spacy.Boston.MA.US> writes:
> >>>>> On Sat, 10 Mar 2001 20:24:16 GMT, David Bakhash ("David") writes:
> David> A much more worthwhile project would be to implement (X)Emacs purely
> David> in Common Lisp.
> ...
> David> The big savings here would be avoiding the writing of the Emacs Lisp
> David> compiler, avoiding
> The current Emacs implementation provides for delivery of an
> executable Emacs distribution (and optionally the source code, but
> most users, especially on Windows, do not have the tools to build it
> from source.) Emacs includes a byte compiler for its own extension
> language.
> If one were to reimplement Emacs in Common Lisp and (use presumably
> also using Common Lisp as the extension language), what Lisp
> compiler would be included in the end-user binary and source
> distributions?
Good question.
The "run time licensing" for the commercial CLs that includes EVAL
seems to be fairly pricey. And _somebody_ has to incur that cost...
--
(reverse (concatenate 'string ····················@" "454aa"))
http://vip.hyperusa.com/~cbbrowne/editors.html
"Purely applicative languages are poorly applicable." -- Alan Perlis
········@hex.net writes:
> The "run time licensing" for the commercial CLs that includes EVAL
> seems to be fairly pricey. And _somebody_ has to incur that cost...
Weird. And here I thought the whole pont of offering evaluation licenses
was that they be free...
········@hex.net writes:
>
> The "run time licensing" for the commercial CLs that includes EVAL
> seems to be fairly pricey. And _somebody_ has to incur that cost...
This seems to be the smallest problem of them all. I think there are
enough Lisps to choose from (and even Common Lisps). I think this idea
has come up more than once. But I can't see anyone really working on
it. The closest thing maybe is Hemlock, maybe it would be worth a look
into the editor of the Lisp Machines.
Just some points which come to my mind. Who pays for the development?
Who is willing to spend money on an Emacs clone in Common Lisp? If
no-one will than from whom comes the money for the devlopment?
So find someone who sponsors that development and it will take place
otherwise ...
Regards
Friedrich
········@hex.net writes:
> Christopher Stacy <······@spacy.Boston.MA.US> writes:
> > If one were to reimplement Emacs in Common Lisp and (use presumably
> > also using Common Lisp as the extension language), what Lisp
> > compiler would be included in the end-user binary and source
> > distributions?
>
> Good question.
Again, CL would be the language; elisp would be some combination of
package and reader hacks within that environment (so it's all
contained within Common Lisp, if possible (no one wants to dive into
the infinite mess of elisp libraries). To do this, and keep it
portable, there's only one solution: CLISP. There is no other. Not
even the commercial CLs are portable enough for this job.
Incidentally, CLISP has the same license as GNU Emacs, as far as I
know, so this won't be a problem with respect to licensing.
> The "run time licensing" for the commercial CLs that includes EVAL
> seems to be fairly pricey. And _somebody_ has to incur that cost...
I think that's kinda true, and there's probably good reason for it.
But what makes you think that such a project would ever use a
commercial CL? The *only* CL that anyone in his right mind would want
to work with is one that is fully open-source.
Also, I should say that I'm out of the loop on the CMUCL derivative
implementations, and don't know about them. I've only used with LW,
ACL, CMUCL, LCL (Lucid), CLISP, and played with CormanLisp. I am not
the best judge of which implementation would be best, but I'd hope
that the design would not depend too strongly on this decision so
much.
dave
Erik Naggum <····@naggum.net> writes:
> * David Bakhash <·····@alum.mit.edu>
> > But what makes you think that such a project would ever use a commercial
> > CL? The *only* CL that anyone in his right mind would want to work with
> > is one that is fully open-source.
> I think it makes perfect sense to start with a commercial Common
> Lisp while the open-source Common Lisps improve sufficiently to be
> viable competitors. That way, there would also be some _direction_
> to the development of the open-source Common Lisps.
The _critical_ thing that is missing in the "free" CL implementations
is the notion of having a _reasonably_ fully functional cross-platform
GUI, as well as, in general, the ability to run cross-platform.
For instance, CMU/CL is nice, if you only want to run on certain
Unix-like platforms. Windows not being an option, and architectures
having to be carefully chosen.
In contrast, CLISP runs on rather many platforms, but nonetheless
lacks the multiplatform GUI.
That ignores ECoLisp; I'm not sure what to say about it...
--
(reverse (concatenate 'string ····················@" "454aa"))
http://www.ntlug.org/~cbbrowne/finances.html
"sic transit discus mundi"
-- From the System Administrator's Guide, by Lars Wirzenius
········@hex.net writes:
> The _critical_ thing that is missing in the "free" CL implementations
> is the notion of having a _reasonably_ fully functional cross-platform
> GUI, as well as, in general, the ability to run cross-platform.
Perhaps CLIM could play an important r�le here. CLIM exists for all
commercial implementations, and we are making good progress on a free
version.
--
Robert Strandh
---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------
>>>>"DB" == David Bakhash schrieb am Sat, 10 Mar 2001 20:24:16 GMT:
DB> does the job. o Most Lisp users want to use Lisp, and many
DB> (e.g. people on this group) wished that elisp would be more
DB> CL-like, and do not wish to move to either Scheme or Java.
I don't know if it's possible with JEmacs, but I know that constant
questions to change the extension language of Emacs to something else
keep re-appearing, with Java being only one of several suggestions.
DB> A much more worthwhile project would be to implement (X)Emacs
DB> purely in Common Lisp. This, of course, wouldn't be easy, but CL
DB> already has a nice interface to X (and if the Windows junkies
DB> don't like X, then they can get Xwin32, VNC, Exceed (sp?), or
I believe that you have never ever taken a look at the XEmacs
source. I see no way that one could easily substitute Elisp with
CL. Any attempt at this will really have to be a completly new
implementation in CL.
DB> The big savings here would be avoiding the writing of the Emacs
DB> Lisp compiler, avoiding C and all its heinousness, and the
DB> ability to use a real language environment. In fact, I am
DB> dumbfounded that it hasn't been done yet in Common Lisp,
You know of Eriks attempt at that and of Hemlock which comes with CMU
CL? The big problem is that todays XEmacs provides an awful lot of
functionality, like LDAP-support, support for several graphics
libraries, drag&drop-support on many platforms, recently even the use
of GTK is possible. I believe that any attempt to get something
working is to put together a group of enthusiasts, and given the
amount of people I've seen that really showed enough interest, I think
that at the moment any such attempt is very likely to fail.
DB> Also, in such a project, the real goal is to get rid of the C
DB> backend to the elisp compiler and to make CL the *real* extension
DB> language, controlling the main loop; not to necessarily get rid
DB> of C altogether.
I think, back in 1998, we had a flame-feast on xemacs-beta with regard
to the extension language, started of by the attempts of some FSF
people to adopt Guile, a scheme implementation, to Gnu Emacs. Several
people, including me, suggested a look at the existing free CL
implementations, which mainly amounted to CLisp and CMUCL. One of the
major points is that the people currently involved in the XEmacs
development know the Elisp engine quite well; in contrast, the
internals of CLisp or CMUCL were, at least at that time, at best
unknown to them. There are some political aspects relating to that,
e.g. who takes responsibity for a bug in the Lisp interpreter, which
features are required (portability?), etc.
If you like to start, you have all my best wished and I'm very
interested. But I wouldn't hold my breath until your version reaches
10% of the functionality offered by XEmacs today.
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"You have the right not to be killed.
Murder is a crime unless it was done by a policeman."
-- The Clash, "Know Your Rights"
Holger Schauer <··············@gmx.de> writes:
>
> You know of Eriks attempt at that and of Hemlock which comes with CMU
> CL? The big problem is that todays XEmacs provides an awful lot of
> functionality, like LDAP-support, support for several graphics
> libraries, drag&drop-support on many platforms, recently even the use
> of GTK is possible. I believe that any attempt to get something
> working is to put together a group of enthusiasts, and given the
> amount of people I've seen that really showed enough interest, I think
> that at the moment any such attempt is very likely to fail.
Now finding a group of enthusiasts seem to be not too difficult. The
question is who pays for it or who can afford spending the needed time
on a re-implementation. And again what buys it? Who will use it? Will
anyone swith good ole' Emacs or XEmacs? I can't tell.
Regards
Friedrich
Holger Schauer <··············@gmx.de> writes:
> DB> A much more worthwhile project would be to implement (X)Emacs
> DB> purely in Common Lisp. This, of course, wouldn't be easy, but CL
> DB> already has a nice interface to X (and if the Windows junkies
> DB> don't like X, then they can get Xwin32, VNC, Exceed (sp?), or
>
> I believe that you have never ever taken a look at the XEmacs
> source. I see no way that one could easily substitute Elisp with
> CL. Any attempt at this will really have to be a completly new
> implementation in CL.
I am pretty sure that XEmacs does a reasonably good job separating the
low-level UI code from all else (though I don't know about GNU
Emacs).
> The big problem is that todays XEmacs provides an awful lot of
> functionality, like LDAP-support, support for several graphics
> libraries, drag&drop-support on many platforms, recently even the
> use of GTK is possible. I believe that any attempt to get something
> working is to put together a group of enthusiasts, and given the
> amount of people I've seen that really showed enough interest, I
> think that at the moment any such attempt is very likely to fail.
It's a design issue. The vast majority of XEmacs, still, is in
elisp. Therefore there's hope. Some of the stuff that's C can be
packaged and interfaced to. Where do you see a problem? Note that
where C code defines functions that exist in elisp, they use a DEFUN
macro defined through the C preprocessor.
> I think, back in 1998, we had a flame-feast on xemacs-beta with
> regard to the extension language, started of by the attempts of some
> FSF people to adopt Guile, a scheme implementation, to Gnu Emacs.
I remember that. However, the people here are well aware that Guile
over CL would be a horrendous mistake. It's 10x worse than elisp.
I'd rather implement Guile in elisp than switch (X)Emacs over to
Guile. I used Guile a lot with SND (an awesome sound program), and
know how much it sucks. I mean, it _really_ sucks. I had to wonder
if its proponents were actually _trying_ to make it suck.
> Several people, including me, suggested a look at the existing free
> CL implementations, which mainly amounted to CLisp and CMUCL. One of
> the major points is that the people currently involved in the XEmacs
> development know the Elisp engine quite well; in contrast, the
> internals of CLisp or CMUCL were, at least at that time, at best
> unknown to them. There are some political aspects relating to that,
> e.g. who takes responsibity for a bug in the Lisp interpreter, which
> features are required (portability?), etc.
Like I said:
o CLISP works almost everywhere, and though some don't like it (and
definitely this sentiment has been expressed here, in this
newsgroup), it's the best all-around solution we've got.
o The `Emacs Lisp' language, as we know it, would just be Common Lisp
+ lots of effort in reader hacking + lots of effort shadowing and
re-defining things like DEFUN. Of course, we would toss a lot of
cl.el out the window, but who cares. Did you know that there's
already something out there like "emacs-lisp.cl"? Last I saw it,
it was trivial, and just defined some basic stuff, but I had quite
a bit in mind for the version that would read in user elisp
extensions to produce the same functionality.
Keep in mind what the upside to all this is:
o new extensions can be coded in Common Lisp, make use of packages,
logical pathnames, CLOS, the condition system, etc.
o It becomes much easier to write applications that use XEmacs as the
UI, which (at that point) you'd have enormous control over.
> If you like to start, you have all my best wished and I'm very
> interested. But I wouldn't hold my breath until your version reaches
> 10% of the functionality offered by XEmacs today.
If jwz wern't already rich, and I was, I'd pay him to start the
project. He *hates* C and C++, yet he knows it well. there's a guy
out there named Hrvoje Niksic who's excellent, and he's another guy I
think would be excellent to start the project off, given his
background, and that he's an excellent dude.
If Guile people wanted to do their version, then let them. It's a
non-issue (anyone who would even consider moving to Guile is someone I
personally wouldn't want working on the CL port). Anyway, looking
through the sources of XEmacs, we see a rediculous C preprocessor
system system for DEFUN which (though clever) demonstrates how
Lisp-based XEmacs is, even at the C level.
dave
David Bakhash writes:
> I remember that. However, the people here are well aware that Guile
> over CL would be a horrendous mistake. It's 10x worse than elisp.
> I'd rather implement Guile in elisp than switch (X)Emacs over to
> Guile. I used Guile a lot with SND (an awesome sound program), and
> know how much it sucks. I mean, it _really_ sucks. I had to wonder
> if its proponents were actually _trying_ to make it suck.
Would you mind expanding on that? Is it because Guile is Scheme, or
because the Guile implementation is bad? I thought Guile was based on
SCM, which I've found to be a rather speedy, useful Scheme.
I need an extension language for a few C projects, and I was toying
with using Guile, so I'm quite curious. (I'm tempted to use Ruby,
Python, or Lua now.)
--J
--
Johann Hibschman ······@physics.berkeley.edu
Johann Hibschman <······@physics.berkeley.edu> writes:
> David Bakhash writes:
>
> > I remember that. However, the people here are well aware that Guile
> > over CL would be a horrendous mistake. It's 10x worse than elisp.
> > I'd rather implement Guile in elisp than switch (X)Emacs over to
> > Guile. I used Guile a lot with SND (an awesome sound program), and
> > know how much it sucks. I mean, it _really_ sucks. I had to wonder
> > if its proponents were actually _trying_ to make it suck.
>
> Would you mind expanding on that? Is it because Guile is Scheme, or
> because the Guile implementation is bad? I thought Guile was based on
> SCM, which I've found to be a rather speedy, useful Scheme.
This probably ought to be "expanded" over to comp.lang.scheme...
I'm sure that "all of the above" is intended; whether or not that's
fair is certainly arguable. [Particularly the "it's bad because it's
Scheme" part.]
What I have noticed is that Guile is really rather slow; slower than
just about any other implementation I've used. That is supposedly
improving, but the perpetual "win" is always billed as being the
integration of Hobbit that allows compiling Scheme code into C, and
that seems little closer now than it was in the mid '90s.
--
(concatenate 'string "cbbrowne" ·@ntlug.org")
http://www.ntlug.org/~cbbrowne/scheme.html
What hair color do they put on the driver's licenses of bald men?
········@hex.net writes:
> Johann Hibschman <······@physics.berkeley.edu> writes:
> > Would you mind expanding on that? Is it because Guile is Scheme, or
> > because the Guile implementation is bad? I thought Guile was based on
> > SCM, which I've found to be a rather speedy, useful Scheme.
Well, SCM never has been the fastest one, as far as I remember. It was
(sorry --- is) _reasonably_ fast, though, and pretty nice to use.
> I'm sure that "all of the above" is intended; whether or not that's
> fair is certainly arguable. [Particularly the "it's bad because it's
> Scheme" part.]
Well, lispers like to flame schemers for just being schemers, which
attitude is pretty mean, in my opinion. But, all my sympathy with
Scheme aside, I agree that to implement something the size of *Emacs
with just bare Report Scheme would be next to ridiculous. A rich
library of primitives is necessary for an effort like this. In the
Scheme world PLT leads the development of such tools. Common Lisp has
the great advantage in this case that those myriads of useful features
are standard.
> What I have noticed is that Guile is really rather slow; slower than
> just about any other implementation I've used. That is supposedly
> improving, but the perpetual "win" is always billed as being the
> integration of Hobbit that allows compiling Scheme code into C, and
> that seems little closer now than it was in the mid '90s.
Oh, forget Guile. Are there any _schemers_ about here who really think
Guile is a superior implementation? I doubt that. [Without disrespect
for Guile developers.]
B.Smilga
Boris Smilga <·····@bhasha.com> writes:
> > I'm sure that "all of the above" is intended; whether or not
> > that's fair is certainly arguable. [Particularly the "it's bad
> > because it's Scheme" part.]
>
> Well, lispers like to flame schemers for just being schemers, which
> attitude is pretty mean, in my opinion.
Please. So far in this particular thread (or at least I) havn't
flamed Scheme programmers. Please don't draw conclusions. I said an
opinion, that I strongly dislike Scheme, but mostly to warn people
of my bias. People here don't form their opinions based on what
others think, and there are few people here whose mere opinions sway
others. I simply note *some* people's instinct to pigeonhole, and
make it easy for them to do this to me, if they so choose, and based
on your last sentence, this is what you've concluded, based on what I
said about Guile.
I dislike Guile partly because of how slow it is, but mostly because
of how inconsistent I found the libraries to be (at least when I
loaded up SND). I couldn't stand trying to find all of the basic
things I'd need to load up just to do simple stuff.
Admittedly, this had a bit to do with SND too, and the seemingly
arbitrary variable naming conventions in the *variables* (something
that has nothing to do with Guile itself).
Sorry I can't be more precise. It's been a while. I don't have much
to compare it to, as the only other Scheme systems I've used are SIOD
(in Festival -- pretty bad) and MIT Scheme, going way back.
BTW, anyone here ever tinker with the Scheme that's in Gimp? How does
that one compare?
dave
On Mon, 12 Mar 2001 08:45:10 GMT, David Bakhash <·····@alum.mit.edu> wrote:
>Boris Smilga <·····@bhasha.com> writes:
>BTW, anyone here ever tinker with the Scheme that's in Gimp? How does
>that one compare?
That Scheme is SIOD, which is not RnRS for any n.
It is also not very efficient. But for scripting Guile, it
is adequate.
Stephan
--
ir. Stephan H.M.J. Houben
tel. +31-40-2474358 / +31-40-2743497
e-mail: ········@win.tue.nl
·······@pcrm.win.tue.nl () writes:
> That Scheme is SIOD, which is not RnRS for any n.
> It is also not very efficient. But for scripting [the Gimp], it
> is adequate.
(I assume you meant to type "Gimp" above, not "Guile").
IMO, this really shows the problem with using a half-assed scripting
solution. I don't doubt that SIOD is good enough for what people want
to do with it in the Gimp MOST of the time, but it's gotten in my way
a couple of times. I *really* don't understand why they didn't use a
real language; having to hack around the fact that the scheme you're
using is *smaller* than RnRS is just absurd.
David Bakhash <·····@alum.mit.edu> writes:
> BTW, anyone here ever tinker with the Scheme that's in Gimp? How does
> that one compare?
That's SIOD. At least it was.
--
Janis Dzerins
If million people say a stupid thing it's still a stupid thing.
In article <··············@alum.mit.edu> writes:
> Admittedly, this had a bit to do with SND too, and the seemingly
> arbitrary variable naming conventions in the *variables* (something
> that has nothing to do with Guile itself).
If you have the time, I'd be interested in which variable names
in Snd (assuming that's what you're referring to) struck you as
arbitrary. Some inconsistencies came about mainly because
I started Snd with very modest goals (I just wanted to look
at a waveform on the SGI and in Linux), but then the thing
grew and grew...
opinions are all too often spread here, and I should rephrase what I
said about Guile.
Guile is not the most terrific implementation of Scheme, but it's
probably better than SIOD, and considering what I was able to do with
that, and that Guile was at least as good, I shouldn't complain. It
was more of a style/opinion thing, and it has as much to do with its
being Scheme than as it did with anything else.
Again, one of Guile's strengths is that it integrates well, and
relatively easily, into many environments.
But it was slow enough in SND that I had to give up on it. That was a
bit of a let-down too.
It's also pretty small, though I don't think it's as small as SIOD.
dave
>>>>> "David" == David Bakhash <·····@alum.mit.edu> writes:
David> Guile is not the most terrific implementation of Scheme, but it's
David> probably better than SIOD, and considering what I was able to do with
David> that, and that Guile was at least as good, I shouldn't complain. It
David> was more of a style/opinion thing, and it has as much to do with its
David> being Scheme than as it did with anything else.
We are actually using Guile Scheme[1] and I must say that allthough I am
no great fan of scheme, I find that Guile has worked pretty well for
us in many respects.
Of course, being interpreted puts it at a terrible disadvantage
against compiled systems, but Guile reportedly is among the fastest
interpreters around (last I heard only SCM was faster).
Among the good things is that it has a very featurefull
implementation, in particular it has a pretty complete CLOS extension,
threads and good integration with the OS.
It also has an active user community (something we found important
when we chose Guile; there are many nifty but half and whole dead
scheme implementatons around) and they are several projects going on
to improve performance including heap loading, byte compilers and
improved gc and module systems.
[1] yes, we are actively seeking replacements and yes, we are also
considering CL.
------------------------+-----------------------------------------------------
Christian Lynbech | Ericsson Telebit, Skanderborgvej 232, DK-8260 Viby J
Phone: +45 8938 5244 | email: ·················@ted.ericsson.dk
Fax: +45 8938 5101 | web: www.ericsson.com
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
David Bakhash <·····@alum.mit.edu> writes:
> If jwz wern't already rich, and I was, I'd pay him to start the
> project. He *hates* C and C++, yet he knows it well.
If he gets tired of the LA night club project, I wouldn't find it
completely shocking if he thought this a neat idea.
When he left Netscape, and Harlequin was going through difficult
times, I was half anticipating that jwz might potentially be an
"angel" to come along and pick up the Lisp bits.
--
(concatenate 'string "cbbrowne" ·@ntlug.org")
http://www.ntlug.org/~cbbrowne/linux.html
Rules of the Evil Overlord #161. "I will occasionally vary my daily
routine and not live my life in a rut. For example, I will not always
take a swig of wine or ring a giant gong before finishing off my
enemy." <http://www.eviloverlord.com/>
Holger Schauer wrote:
>
> If you like to start, you have all my best wished and I'm very
> interested. But I wouldn't hold my breath until your version reaches
> 10% of the functionality offered by XEmacs today.
>
How much of the functionality in (X)emacs is required in a CLmacs which
is to be used directly under some CL implementation? I guess I mean "the
thing that is invoked when you do (ed something)". Also, can such a
CLmacs be implemented with a reasonable effort using a subset of CL
(avoiding CLOS etc) and some basic functionality from eg CLIM and/or a
selected set of primitives in X11/Windows32?
Lars
>>>>"c" == ck schrieb am Mon, 12 Mar 2001 08:51:13 +0100:
c> How much of the functionality in (X)emacs is required in a CLmacs
c> which is to be used directly under some CL implementation? I guess
c> I mean "the thing that is invoked when you do (ed
c> something)".
Good question. I just can supply my own personal view on it: I use
Emacs for a lot more than hacking code: writing documents, reading and
writing mails/news mainly, but I am also doing other things
frequently. For this, the start of external programs like LaTeX is
necessary. And if one likes a nice GUI like that of XEmacs, well,
I don't know whether any of the more wide-spread Lisps comes with a
graphics library capable of that.
c> some basic functionality from eg CLIM and/or a selected set of
c> primitives in X11/Windows32?
Good question, again.
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"The whole reason there is a Free Software Foundation is because of
Symbolic's closed source, proprietary mindset. I've seen absolutely no
indication that its changed one iota in the last fifteen years or so."
-- Mike McDonald in comp.lang.lisp
On Mon, 12 Mar 2001, Lars [iso-8859-1] Lundbäck wrote:
> How much of the functionality in (X)emacs is required in a CLmacs which
> is to be used directly under some CL implementation? I guess I mean "the
> thing that is invoked when you do (ed something)". Also, can such a
> CLmacs be implemented with a reasonable effort using a subset of CL
> (avoiding CLOS etc) and some basic functionality from eg CLIM and/or a
^^^^^^^^^^^^^^^^^^
What's the point of that?
> selected set of primitives in X11/Windows32?
>
> Lars
Tim
Tim Moore <·····@herschel.bricoworks.com> writes:
> On Mon, 12 Mar 2001, Lars [iso-8859-1] Lundb=E4ck wrote:
> > How much of the functionality in (X)emacs is required in a CLmacs which
> > is to be used directly under some CL implementation? I guess I mean "the
> > thing that is invoked when you do (ed something)". Also, can such a
> > CLmacs be implemented with a reasonable effort using a subset of CL
> > (avoiding CLOS etc) and some basic functionality from eg CLIM and/or a
> ^^^^^^^^^^^^^^^^^^
> What's the point of that?
A good question indeed.
I suspect the point here is to look to some subset of CL that is
readily implementable and/or portable across existing CL
implementations. The smaller the subset, presumably the easier it
becomes to get a basic set of functionality up and running.
The notion that "smaller is better" strikes me as a, um, "potentially
significant source of controversy."
If _using_ CLOS were to allow implementing Emacs in a manner that
would be terser, more powerful, and perhaps more reliable, then that
would seem likely to be preferable to _not_ using CLOS.
--
(reverse (concatenate 'string ··········@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/linuxdistributions.html
All ITS machines now have hardware for a new machine instruction --
XOI Execute Operator Immediate.
Please update your programs.
········@hex.net writes:
> Tim Moore <·····@herschel.bricoworks.com> writes:
> > On Mon, 12 Mar 2001, Lars [iso-8859-1] Lundb=E4ck wrote:
> > > How much of the functionality in (X)emacs is required in a CLmacs which
> > > is to be used directly under some CL implementation? I guess I mean "the
> > > thing that is invoked when you do (ed something)". Also, can such a
> > > CLmacs be implemented with a reasonable effort using a subset of CL
> > > (avoiding CLOS etc) and some basic functionality from eg CLIM and/or a
> > ^^^^^^^^^^^^^^^^^^
> > What's the point of that?
>
> A good question indeed.
>
> I suspect the point here is to look to some subset of CL that is
> readily implementable and/or portable across existing CL
> implementations. The smaller the subset, presumably the easier it
> becomes to get a basic set of functionality up and running.
Well, since the goal was to implement an Emacs using CL as both the
implementation language, but more importantly, the _extension_
language, the smallest subset that is acceptable is ANSI CL. If I
wanted an Emacs that offered me as small a subset of CL as it could
get away with, then (X)Emacs already is there for the taking.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
"Pierre R. Mai" wrote:
>
> Well, since the goal was to implement an Emacs using CL as both the
> implementation language, but more importantly, the _extension_
> language, the smallest subset that is acceptable is ANSI CL.
Absolutely, I *know* the thread is titled "emacs in CL", but I did say
"the thing you get when doing (ed ...)", so I was not talking about a
full emacs.
> If I wanted an Emacs ..
but I said CLmacs. You know, I intended to arrive at a joke; delete the
's' and you have CLmac - Common Lisp on a Mac, which has been praised by
some posters. Delete more characters and you have CLm, the CL machine.
:-)
> that offered me as small a subset of CL as it could
> get away with, then (X)Emacs already is there for the taking.
>
Again, absolutely. Is emacs the thing for you, or do you envision
something else?
Regards, Lars
········@hex.net wrote:
>
> I suspect the point here is to look to some subset of CL that is
> readily implementable and/or portable across existing CL
> implementations. The smaller the subset, presumably the easier it
> becomes to get a basic set of functionality up and running.
Mhm, but not "as small as possible", rather a "reasonably limited set".
I imagine there are some would-be CL implementors hidden out there that
have not arrived at a full CLOS yet ...
> The notion that "smaller is better" strikes me as a, um, "potentially
> significant source of controversy."
c.l.l has been kind of quiet for some time now, busy with those schemers
and whatnot. Anyway, controversies arrive when people understand emacs
differently.
"Which is the best combination of browser/editor/inspector for CL
source code?"
"Can an even better solution be contrived, implemented in CL with a
minimum of extensions?"
> If _using_ CLOS were to allow implementing Emacs in a manner that
> would be terser, more powerful, and perhaps more reliable, then that
> would seem likely to be preferable to _not_ using CLOS.
Mhm again, meaning yes. But do all CL implementations behave exactly the
same? I like CL code that is free from all those *features* checks and
#+ACME (acme:initialize-something) uglies. Also, is implementing emacs
as-is in Common Lisp the ultimate goal? I prefer to view emacs as a
concept, rather than a template.
Anyway, we have not answered any of those "good questions". Sigh. From
now on, I will use capitals only in CL-related stuff.
Regards, Lars
Erik Naggum <····@naggum.net> writes:
> * Lars Lundback <·············@era.ericsson.se>
> > But do all CL implementations behave exactly the same?
> CLOS is extremely portable. MOP is just portable. CL is portable
> enough, but there are differences and "portability/conformance"
> bugs.
The "open" question (which I expect is a silly one) is whether or not
"conformance" issues surrounding CLOS would make its use prohibitively
difficult.
>> I like CL code that is free from all those *features* checks and
>> #+ACME (acme:initialize-something) uglies.
>It is not such CL that you like, it is the real world that you
>dislike. Incidentally, nothing keeps you from stuffing
>system-dependent stuff in files that are loaded conditionally instead
>of stuffing #+ and #- in you code. If you really want to write
>"clean" code, you do need to deal with unclean world. Doing it all
>over the place betrays lack of forethought.
Oddball-factoid-of-the-day:
SAP's ABAP/4 language supports something _precisely_ like #+; they've
got the "operators:"
#+R2
#+R3
that allow statements to be included iff the program is running on R/2
(old mainframe version) or R/3 (newer client/server version).
>> Also, is implementing emacs as-is in Common Lisp the ultimate goal?
> I found that not to be my goal, which means that capitalizing on the
> continuing development of X/Emacs packages would be hard. Hell, it
> is hard enough for package developers to track both Emacsen today.
> However, certain packages would be extremely useful to run in any
> Emacs, and the porting work from all the crufty Elisp out there
> would be develishly hard, so perhaps only a bytecode interpreter
> would be necessary.
Yes, there lies the problem; how to avoid recreating 20 years worth of
crufty elisp...
>> I prefer to view emacs as a concept, rather than a template.
> My initial design was extremely different from extant Emacs, with
> "file system processors" that you started up over local/rsh/ssh
> connections so you could edit files as a different user or at a
> different machine without having to start Emacs anew or using
> ange-ftp. Emacs would not do file system I/O in other words.
> Emacs would no longer load the entire file into memory before
> displaying a portion of it. The display would be handled
> similarly, by dedicated "display system processors" that could run
> anywhere and connect to the Emacs process as long as they shared
> some access information. The DSP's would only be sent as much of
> the buffer as they needed to display, but would also cache it so
> scrolling and such could take place entirely locally if you had
> seen that part of the buffer before and it hadn't changed. Very
> simple operations like insert and delete at the character or line
> level would be handled by the display process if nothing magic
> would happen.
Ah... Yes.
In other words, Emacs becomes a set of "processors," some that "do
stuff," others that "display stuff."
The classic problem that demonstrates where Emacs falls down is when
you run Gnus, and it starts reading newsgroup information in, and
then, and then, and then _everything else hangs_ because a
long-running process has taken over, and nothing else can get at the
display.
It would indeed be very slick to have Emacs be a set of
intercommunicating processes. Gnus might well have its own "FSP."
(Or if you're running Gnus Agent, perhaps several FSPs...)
I'm not sure whether each window should have a DSP, or if there should
be one for every buffer being displayed. Probably one for each
window...
> The FSP's would be written in C so they would not require a Lisp
> image on the machine. Similarly, the DSP's would (likely) be
> implemented in C, simply because the CL version would have
> required so much FFI stuff. I'd like to generate the C code from
> CL, however, to make it supremely portable, but readability for
> mere humans would not be a high priority.
I wouldn't have expected you to take that approach, but that has the
merit of allowing "Multi-Emacs" to run places where CL may not have
been implemented. And makes it irrelevant whether or not _I_ have a
license to (say) ACL, as the code that gets generated doesn't depend
on a particular CL environment.
> The upside of this distributed approach is that most operations
> would be fast and immediate. The downside is that those operations
> that are not local would both be unpredictable and significantly
> slower, but not necessarily noticeably so, but much faster than
> running Emacs remotely over X and probably noticeably faster than
> running Emacs in a remote xterm. All of this to support a central
> machine that would run the Common Lisp with Emacs, acting as a
> local user on other machines via a network file system protocol
> cognizant of the needs of the caller, and with full support and
> recognition of the fact that people would like to work on machines
> that are far away from the user.
> I had no higher goal at first than to make the integrated Emacs
> support the underlying Common Lisp system for a better development
> environment.
It wouldn't be worth the _massive_ breakage of existing code to do
anything too much less revolutionary, but that would be a rather
immense project.
--
(concatenate 'string "cbbrowne" ·@ntlug.org")
http://vip.hyperusa.com/~cbbrowne/lisp.html
"The code should be beaten into submission" -- Arthur Norman
········@hex.net writes:
> In other words, Emacs becomes a set of "processors," some that "do
> stuff," others that "display stuff."
"H*rd of Emacs-replacing defuns", perhaps? That gives us one
of the two mutually recursive acronyms required :-)
--
Raymond Wiker
·············@fast.no
Raymond Wiker <·············@fast.no> writes:
> ········@hex.net writes:
>
> > In other words, Emacs becomes a set of "processors," some that "do
> > stuff," others that "display stuff."
>
> "H*rd of Emacs-replacing defuns", perhaps? That gives us one
> of the two mutually recursive acronyms required :-)
In effect, yup. That horribly-punned acronym already being taken, a
new set of horrible puns would need to be coined before an
implementation could proceed.
[The secret and appalling truth of all this being that Erik couldn't
proceed because he couldn't find puns horrible enough :-).]
--
(reverse (concatenate 'string ··········@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/finances.html
What hair color do they put on the driver's licenses of bald men?
The name "CLmacs" suggests a twizzle to "CLiMacs" to provide a
suggestive pronounciation. CLiMacs or CLIMacs would both be
appropriate, with CLIMacs requiring CLIM integration.
Maybe just leave the "i" out and keep the pronounciation. Hey, could
there be a better editor than a CLmacs? ;)
> How much of the functionality in (X)emacs is required in a CLmacs which
> is to be used directly under some CL implementation? I guess I mean "the
> thing that is invoked when you do (ed something)". Also, can such a
> CLmacs be implemented with a reasonable effort using a subset of CL
> (avoiding CLOS etc) and some basic functionality from eg CLIM and/or a
> selected set of primitives in X11/Windows32?
>
> Lars
--
- Mike
"Thus if induction is 'inductively valid' it will
almost always lead to false conclusions; and
therefore it is inductively invalid."
-- K.R. Popper
David Bakhash <·····@alum.mit.edu> writes:
> A much more worthwhile project would be to implement (X)Emacs purely
> in Common Lisp. This, of course, wouldn't be easy, but CL already has
> a nice interface to X (and if the Windows junkies don't like X, then
> they can get Xwin32, VNC, Exceed (sp?), or something), and I think
> that Elisp can fully be written in Common Lisp, simply as a separate
> package (and some clever hacking to handle the dynamic scoping rules
> of elisp), and portable modifications to the reader.
Another way is to implement the missing functionality in the
Emacs-like editors that come with LispWorks or MCL. I'm using the
LispWorks editor more and more instead of XEmacs and I just add what I
really miss, which is a far smaller project than reimplementing all
XEmacs functionality.
--
Lieven Marchand <···@wyrd.be>
Gla�r ok reifr skyli gumna hverr, unz sinn b��r bana.
Martin Schmidt <·······@gmx.net> writes:
> hi,
> Do you know if there's another elisp compiler, or if the elisp compiler
> from emacs can be
> somehow magically separated from the editor?
isn't 'emacs -batch' magical enough for you?
--
(espen)