ilisp verse eli
J Scott Jaderholm
Can someone that is familiar with ilisp and ACL's eli tell me how they
differ and which they prefer and why?
Thanks,
jsj
--
"Man's mind, once stretched by a new idea, never regains its original
dimensions." Oliver Wendell Holmes (a Lisp programmer at heart)
Eugene Zaikonnikov
J> Hi, Can someone that is familiar with ilisp and ACL's eli tell me
J> how they differ and which they prefer and why?
Both provide very similar functionality, but ilisp has bindings for
several Lisp implementations, so that if you ever change your vehicle,
the controls will feel familiar.
Eli of ACL 6 refuses to work with GNU Emacs 21, but I believe that
when the latter will come out of pretest Franz will fix that quickly.
--
Eugene
J Scott Jaderholm
> * "J" == J Scott Jaderholm <lisp...@sage.cortland.com> writes:
>
> J> Hi, Can someone that is familiar with ilisp and ACL's eli tell me
> J> how they differ and which they prefer and why?
>
> Both provide very similar functionality, but ilisp has bindings for
> several Lisp implementations, so that if you ever change your vehicle,
> the controls will feel familiar.
So there are no major eli features I'll be missing if I use ilisp?
> Eli of ACL 6 refuses to work with GNU Emacs 21, but I believe that
> when the latter will come out of pretest Franz will fix that quickly.
This is one of the major reasons I'm considering using ilisp instead
of eli :)
Tim Bradshaw
> So there are no major eli features I'll be missing if I use ilisp?
>
eli deals a lot better with acl-specific stuff -- for instance if you
get errors in processes other than the listener it deals with that
very nicely. ACL's ED understands eli and will cause emacs to edit
the file containing the definition. ilisp has gone through phases of
totally failing to work in the current stable xemacs release though I
think they've fixed that. eli's default keybindings are, I find, a
bit painful.
--tim
Pierre R. Mai
> > Both provide very similar functionality, but ilisp has bindings for
> > several Lisp implementations, so that if you ever change your vehicle,
> > the controls will feel familiar.
> So there are no major eli features I'll be missing if I use ilisp?
eli is IMHO much better integrated with ACL (not surprisingly), and
offers a more stable and sometimes more powerful user-environment.
Regs, Pierre.
--
Pierre R. Mai <pm...@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
Marco Antoniotti
Tim Bradshaw <t...@tfeb.org> writes:
> J Scott Jaderholm <lisp...@sage.cortland.com> writes:
>
> > So there are no major eli features I'll be missing if I use ilisp?
> >
>
> eli deals a lot better with acl-specific stuff -- for instance if you
> get errors in processes other than the listener it deals with that
> very nicely. ACL's ED understands eli and will cause emacs to edit
> the file containing the definition. ilisp has gone through phases of
> totally failing to work in the current stable xemacs release though I
> think they've fixed that.
Of course people can pitch in.
http://sourceforge.net/projects/ilisp
Cheers
--
Marco Antoniotti =============================================================
NYU Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
Sunil Mishra
fragile. I wish I could list all the problems I had with it, but now all
I can say is that I could not figure out how to do some relatively
simple tasks. Perhaps that was just a learning problem... But what
really got to me was that eli did not respect the paradigms that other
lisp modes follow, such as M-p and M-n for previous and next command. It
made using eli an "irregular" mode of operation (wrt emacs) for me, so I
went back to ilisp. Which despite some significant problems (eg, losing
the current state of the lisp image when running lispworks so that
dynamic evaluation from a buffer stops working, subsequently locking up
lisp interaction until a panic-reset) ilisp has worked well for me.
Sunil
Pierre R. Mai wrote:
> J Scott Jaderholm <lisp...@sage.cortland.com> writes:
>
>
>>> Both provide very similar functionality, but ilisp has bindings for
>>> several Lisp implementations, so that if you ever change your vehicle,
>>> the controls will feel familiar.
>>
>
>> So there are no major eli features I'll be missing if I use ilisp?
>
>
Erik Naggum
| But what
| really got to me was that eli did not respect the paradigms that other
| lisp modes follow, such as M-p and M-n for previous and next command.
Yes, C-c p and C-c n are massively annoying, but rebinding them to M-p
and M-n is really quite simple. You're _supposed_ to make your own
bindings that fit your own needs in Emacs, so while not excessively
sympathetic to your plight, I agree that the default should be more in
line with other packages.
I can't live without the multiple listeners and the background streams
in eli, nor without any of the other support for multiprocessing in
the same Lisp image. Last I checked, ilisp couldn't deal with
multiprocessing at all, possibly because CMUCL and CLISP don't have
real multiprocessing so there is no need for it there.
#:Erik
--
Solution to U.S. Presidential Election Crisis 2000:
Let Texas secede from the Union and elect George W. Bush their
very first President. All parties, states would rejoice.
Marco Antoniotti
Erik Naggum <er...@naggum.net> writes:
> * Sunil Mishra <sunil....@everest.com>
> | But what
> | really got to me was that eli did not respect the paradigms that other
> | lisp modes follow, such as M-p and M-n for previous and next command.
>
> Yes, C-c p and C-c n are massively annoying, but rebinding them to M-p
> and M-n is really quite simple. You're _supposed_ to make your own
> bindings that fit your own needs in Emacs, so while not excessively
> sympathetic to your plight, I agree that the default should be more in
> line with other packages.
>
> I can't live without the multiple listeners and the background streams
> in eli, nor without any of the other support for multiprocessing in
> the same Lisp image. Last I checked, ilisp couldn't deal with
> multiprocessing at all, possibly because CMUCL and CLISP don't have
> real multiprocessing so there is no need for it there.
>
Yep. Multiprocessing handling is not in ILISP. Any takers? :)