i saw on cmucl's website (http://www.cons.org/cmucl) that it comes
with a emacs-type hemlock.
Given that there are so many libraries in (x)emacs which people may be
using, you surely don't expect people to give all that up and switch
to hemlock. Surely somebody somewhere must be working to let hemlock
interpret elisp?
(PS: Letting CL interpret elisp should be not too hard, right? since
CL allows for both scoping schemes... etc. ?)
--Deepak, http://www.glue.umd.edu/~deego
In article <················@rac2.wam.umd.edu>, Deepak Goel wrote:
>
>i saw on cmucl's website (http://www.cons.org/cmucl) that it comes
>with a emacs-type hemlock.
>
>Given that there are so many libraries in (x)emacs which people may be
>using, you surely don't expect people to give all that up and switch
>to hemlock. Surely somebody somewhere must be working to let hemlock
>interpret elisp?
Nope. Not that I'm aware, anyway. You're welcome to, though. :)
Hemlock comes with a fairly reasonable set of libraries. Note that lots
of features in (X)Emacs are not implemented in Hemlock (syntax
highlighting comes immediately to mind). Looking through the user's
manual for Hemlock, it looks a little bit more well thought-out, but
that's just my opinion.
I'm guessing that Hemlock was mostly written before X support in Emacs
was good (Hemlock was originally X-only), so that may have been the
motivating factor in its development.
--
</nathan> ·······@rose-hulman.edu | http://www.rose-hulman.edu/~froydnj/
Yes, God had a deadline. So He wrote it all in Lisp.
·······@rose-hulman.edu (Nathan Froyd) writes:
> In article <················@rac2.wam.umd.edu>, Deepak Goel wrote:
> >
> >i saw on cmucl's website (http://www.cons.org/cmucl) that it comes
> >with a emacs-type hemlock.
> >
> >Given that there are so many libraries in (x)emacs which people may be
> >using, you surely don't expect people to give all that up and switch
> >to hemlock. Surely somebody somewhere must be working to let hemlock
> >interpret elisp?
>
> Nope. Not that I'm aware, anyway. You're welcome to, though. :)
It's also not that simple: While it is quite possible to let a modern
Common Lisp interpret Emacs Lisp qua language, the important part of
Emacs isn't Emacs Lisp, it is the large array of built-in primitives,
which comprises among other things a fairly complete OS-independent
GUI toolkit. Given the grown structure of Emacs, it is necessary to
reimplement most of the C substrate in a bug-for-bug compatible way,
in order to let real-life Emacs packages work.
While something like this has been done a couple of years back on a
Scheme implementation, upto the point that the emulation was capable
of running GNUS (the old one, not Gnus), it is certainly not a trivial
task.
In the meantime most people don't use Hemlock, but use (X)Emacs in
combination with ILISP to work with CMU CL.
> Hemlock comes with a fairly reasonable set of libraries. Note that lots
> of features in (X)Emacs are not implemented in Hemlock (syntax
> highlighting comes immediately to mind). Looking through the user's
> manual for Hemlock, it looks a little bit more well thought-out, but
> that's just my opinion.
>
> I'm guessing that Hemlock was mostly written before X support in Emacs
> was good (Hemlock was originally X-only), so that may have been the
> motivating factor in its development.
Actually Hemlock predates (public releases of) GNU Emacs by a year or
so, since it existed since around 1984. It was part of the Spice
workstation environment, together with Spice Lisp (which only later
became CMU Common Lisp). It also predates X, which was created around
1986, and the first port of Hemlock to X was checked-in in 1987. See
hemlock.log in the hemlock source directory of CMU CL for details.
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
On 23 Apr 2001, Pierre R. Mai wrote:
> It's also not that simple: While it is quite possible to let a
> modern Common Lisp interpret Emacs Lisp qua language, the important
> part of Emacs isn't Emacs Lisp, it is the large array of built-in
> primitives, which comprises among other things a fairly complete
> OS-independent GUI toolkit. Given the grown structure of Emacs, it
> is necessary to reimplement most of the C substrate in a bug-for-bug
> compatible way, in order to let real-life Emacs packages work.
Do you think it would be possible to take some CL implementation and
replace the Emacs Lisp interpreter with it?
kai
--
The passive voice should never be used.
···············@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> On 23 Apr 2001, Pierre R. Mai wrote:
>
> > It's also not that simple: While it is quite possible to let a
> > modern Common Lisp interpret Emacs Lisp qua language, the important
> > part of Emacs isn't Emacs Lisp, it is the large array of built-in
> > primitives, which comprises among other things a fairly complete
> > OS-independent GUI toolkit. Given the grown structure of Emacs, it
> > is necessary to reimplement most of the C substrate in a bug-for-bug
> > compatible way, in order to let real-life Emacs packages work.
>
> Do you think it would be possible to take some CL implementation and
> replace the Emacs Lisp interpreter with it?
I don't think that's trivial either: The Emacs primitives, the Emacs
GC and the Emacs Lisp interpreter are fairly intertwined, and you'd
have to replace the GC and interpreter at the same time (the Emacs
GC is fairly crappy), etc. For XEmacs, Ben Wing has written up an
outline of what would be required in order to exchange the lisp
engine, see
http://www.xemacs.org/Architecting-XEmacs/lisp-engine-replacement.html
for details.
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" <····@acm.org> writes:
> While something like this has been done a couple of years back on a
> Scheme implementation, upto the point that the emulation was capable
> of running GNUS (the old one, not Gnus), it is certainly not a
> trivial task.
Really? I've never ever heard of this thing. Could you post some
pointers?
Hrvoje Niksic <·······@arsdigita.com> writes:
> "Pierre R. Mai" <····@acm.org> writes:
>
> > While something like this has been done a couple of years back on a
> > Scheme implementation, upto the point that the emulation was capable
> > of running GNUS (the old one, not Gnus), it is certainly not a
> > trivial task.
>
> Really? I've never ever heard of this thing. Could you post some
> pointers?
My mind is fuzzy, but for some reason I think it was done in Edwin,
the editor in MIT Scheme. I think there was a paper about it...
--
T. Kurt Bond, ···@tkb.mpl.com
Hrvoje Niksic <·······@arsdigita.com> writes:
> "Pierre R. Mai" <····@acm.org> writes:
>
> > While something like this has been done a couple of years back on a
> > Scheme implementation, upto the point that the emulation was capable
> > of running GNUS (the old one, not Gnus), it is certainly not a
> > trivial task.
>
> Really? I've never ever heard of this thing. Could you post some
> pointers?
* M. Birkholz ``Emacs Lisp in Edwin Scheme'',
MIT Artificial Intelligence Lab Report TR-1451, September 1993.
The MIT-Scheme program development environment includes a
general-purpose text editor, Edwin, that has an extension language,
Edwin Scheme. Edwin is very similar to another general-purpose text
editor, GNU Emacs, which also has an extension language, Emacs
Lisp. The popularity of GNU Emacs has lead to a large library of
tools written in Emacs Lisp. The goal of this thesis is to
implement a useful subset of Emacs Lisp in Edwin Scheme. This
subset was chosen to be sufficient for simple operation of the GNUS
news reading program.
IIRC then this report was available somewhere on the net (I might even
have a copy of this stored on some archival CD-R somewhere), you might
want to look at the MIT AI Lab document servers. The bibliographic
reference above can be gotten from:
http://www-swiss.ai.mit.edu/projects/mac/bibliography.html
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
Thanks all of you for the pointers..
, and it was nice to discover that elisp can indeed be parsed by common
lisp, using elisp.lisp from sourceforge... i am gonna soon try out
hemlock.. :)
--Deepak, http://www.glue.umd.edu/~deego
[Followup posted to comp.lang.lisp only - Paolo]
On 22 Apr 2001 20:22:43 -0400, Deepak Goel <·····@rac2.wam.umd.edu> wrote:
> Given that there are so many libraries in (x)emacs which people may be
> using, you surely don't expect people to give all that up and switch
> to hemlock. Surely somebody somewhere must be working to let hemlock
This is apparently what those who use Hemlock do.
> (PS: Letting CL interpret elisp should be not too hard, right? since
> CL allows for both scoping schemes... etc. ?)
This has been done. Emacs Lisp support for Common Lisp is included in
cllib, which is part of CLOCC:
Common Lisp Open Code Collection
http://clocc.sourceforge.net/
Note that this is only _language_ support for Emacs Lisp.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/