Differences between Elisp and Lisp

Differences between Elisp and Lisp

[Daniel R. Anderson]

On emacswiki.org there is a "wish list".  Quite a few people want emacs
to be based on another version of LISP.  Out of curiosity, what is it
that makes elisp inherently bad, or why would people want it to be
changed?

Thanks,

-Dan Anderson

Re: Differences between Elisp and Lisp

[Friedrich Dominicus]

"Daniel R. Anderson" <dan@mathjunkies.com> writes:

> On emacswiki.org there is a "wish list".  Quite a few people want emacs
> to be based on another version of LISP.  Out of curiosity, what is it
> that makes elisp inherently bad, or why would people want it to be
> changed?
Uh oh, Flamewar alert ;-)

Oh no, I can' resist. Well saying elisp is inherently bad is way too
strong, anyway elisp was and partly is weak in the following areas.
- Datastructures (yes I know defstruct does exist and as eieio does
exist too.). If you look a bit through Emacs Lisp code than you'll see
that nearly every package goes through Lists.... 
- missing package system (everyone who write a package prefix his/her
stuff with some prefix..., what makes up for some sort of package)
- dynamically scoped (no "real closures", other may see this as an
advantage.
- without the cl-package Emacs Lisp would really be uncomplete ...

Now what would we gain with something else?
Depenps on what we choose, IMHO nothing is better for extensions than
some Lisp Dialect, having the ability to write macros seems to be very
good do have for an Editor.

Now what would I prefer?
I would prefer having based Emacs on Common Lisp. I tend to think that
structuring the code in-the-large on CLOS would make for an
exceptional framework for any kine of text processing, well it would
be a very large framework that's for sure, therefor learning it would
be not an easy task but it would be way easier than having what we
have a the moment. I tend to think that with CLOS code duplication
would be much lowered. 

Anyway let's see the fact. I bet the code base from Emacs Lisp is one
of the larget around and Emacs does help much to find one's way
through it's API. There's hardly anything which Emacs can't do, and
all is available for your own tools too. Thousans of man years of
development has been carried out with Emacs Lisp, if something new
comes along which has to do with handling text, sooner than latter
Emacs will capable of doing it too. 


Emacs is really a miracle....

Regards
Friedrich

Re: Differences between Elisp and Lisp

[Lars Magne Ingebrigtsen]

"Daniel R. Anderson" <dan@mathjunkies.com> writes:

> On emacswiki.org there is a "wish list".  Quite a few people want emacs
> to be based on another version of LISP.  Out of curiosity, what is it
> that makes elisp inherently bad, or why would people want it to be
> changed?

There's nothing inherently bad about Emacs Lisp, in my opinion.  I
think it's a cute language that fun to work with.

However, it has some peculiarities that many people find
disconcerting.  For instance -- all variables have dynamic scope,
which is somewhat unusual these days.  There's no package system (to
avoid clobbering variables/functions from other packages).  It
doesn't have much of an object system, and dispatching functions
based on type would be nice.

But there are really only two things that I think are really
important.

1) Emacs Lisp is kinda slow.

2) Emacs Lisp is single threaded.

But I like Emacs Lisp.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Differences between Elisp and Lisp

[David Kastrup]

Lars Magne Ingebrigtsen <lmi@gnus.org> writes:

> "Daniel R. Anderson" <dan@mathjunkies.com> writes:
> 
> > On emacswiki.org there is a "wish list".  Quite a few people want emacs
> > to be based on another version of LISP.  Out of curiosity, what is it
> > that makes elisp inherently bad, or why would people want it to be
> > changed?
> 
> There's nothing inherently bad about Emacs Lisp, in my opinion.  I
> think it's a cute language that fun to work with.
> 
> However, it has some peculiarities that many people find
> disconcerting.  For instance -- all variables have dynamic scope,
> which is somewhat unusual these days.

It is also unpredictable and inefficient.  For example, you have to
write
((lambda (f g n) (funcall g (funcall f f g) n))
 (lambda (f g) `(lambda (n) (,g (funcall ,f ,f ,g) n)))
 (lambda (f n) (if (zerop n) 1 (* n (funcall f (1- n)))))
 5)
in Emacs-Lisp (meaning that the stuff can't be compiled at compile
time) instead of
((lambda (f g n) (funcall g (funcall f f g) n))
 (lambda (f g) (lambda (n) (funcall g (funcall f f g) n)))
 (lambda (f n) (if (zerop n) 1 (* n (funcall f (1- n)))))
 5)
as is possible in Common Lisp.

It also means that you can't completely compile functions, as the
referenced variables might be something completely different from what
you expect: any function you call may wish to tamper with your own
local variables.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Differences between Elisp and Lisp

[Oliver Scholz]

Lars Magne Ingebrigtsen <lmi@gnus.org> writes:
[...]
> However, it has some peculiarities that many people find
> disconcerting.  For instance -- all variables have dynamic scope,
> which is somewhat unusual these days.  
[...]

AFAIK Miles Bader is working on a branch (“lexbind”) where he's
implementing lexical scoping. But I have not found the time to check
it out, yet, and I hope I don't spread misinformation. I hope that
will get us closures, too.

    Oliver
-- 
10 Floréal an 211 de la Révolution
Liberté, Egalité, Fraternité!

Re: Differences between Elisp and Lisp

[Phillip Lord]

>>>>> "os" == Oliver Scholz <alkibiades@gmx.de> writes:

  os> Lars Magne Ingebrigtsen <lmi@gnus.org> writes: [...]
  >> However, it has some peculiarities that many people find
  >> disconcerting.  For instance -- all variables have dynamic scope,
  >> which is somewhat unusual these days.
  os> [...]

  os> AFAIK Miles Bader is working on a branch (“lexbind”) where he's
  os> implementing lexical scoping. But I have not found the time to
  os> check it out, yet, and I hope I don't spread misinformation. I
  os> hope that will get us closures, too.


I thought that CL already implemented lexical binding? At least within
a let form (or "lexical-let"). 

If emacs just went to using lexical binding in the large, I suspect
that it would cause lots of problems with existing packages. I have
used dynamic scoping to achieve ends in the past, which might be a bit
nasty, but it does work!

Cheers

Phil

Re: Differences between Elisp and Lisp

[Thomas Link]

> I thought that CL already implemented lexical binding? At least within
> a let form (or "lexical-let"). 

I guess it's faking lexical binding by replacing variable names with 
gensyms. This makes it pseudo-lexical but not more efficient.

> If emacs just went to using lexical binding in the large, I suspect
> that it would cause lots of problems with existing packages. I have
> used dynamic scoping to achieve ends in the past, which might be a bit
> nasty, but it does work!

Correct me if I'm wrong, but e.g. Common Lisp has dynamic binding for 
variables defined with defvar. The following works with clisp:

	(defvar x 1)
	(defun y (a) (+ x 1))
	(y 1) => 2
	(let ((x 10)) (y 1)) => 11

So one could have both. The question is, which one should be the 
"default" mode and which one should be subject to special constructs.

Cheers,
Thomas.

Re: Differences between Elisp and Lisp

[Kent M Pitman]

Thomas Link <samul@web.de> writes:

> > I thought that CL already implemented lexical binding? At least within
> > a let form (or "lexical-let").
> 
> I guess it's faking lexical binding by replacing variable names with
> gensyms. This makes it pseudo-lexical but not more efficient.

In addition to having questionable efficiency issues, such a strategy
also eliminates the one primary reason that more than anything
justifies lexical scoping--the ability to know 'just by looking' that
no other uses of the variable exist and that it's ok to optimize.
Consider:

 (let ((x 1))
   (f x))

which might result from a macro expansion.  You'd like this to compile the
same as (f 1).  But if you just turn it into

 (let ((x0001 1))
   (f x0001))

the compiler still has to worry that x0001 might be accessible within the
definition of f, and so it can't make the binding for it go away. What 
allows you to make the binding go away is not the _fact_ that this is the 
only use of x0001 but the _lexically apparent knowledge_ that this is the
only use of x0001.  And that knowledge comes from 'real lexicality', not
from clever tricks.  [Even if you have access to the source code of 'f',
you can't rely on that since f might be later redefined.  It should be
possible to later introduce a new f with different properties without
recompiling callers to f.]

Additionally, tricks like the above mean that in error breaks, the stack
is cluttered with myriad special variable bindings that one really doesn't
want to have to paw through.

> > If emacs just went to using lexical binding in the large, I suspect
> > that it would cause lots of problems with existing packages. I have
> > used dynamic scoping to achieve ends in the past, which might be a bit
> > nasty, but it does work!
> 
> Correct me if I'm wrong, but e.g. Common Lisp has dynamic binding for
> variables defined with defvar. The following works with clisp:
> 
> 	(defvar x 1)
> 	(defun y (a) (+ x 1))
> 	(y 1) => 2
> 	(let ((x 10)) (y 1)) => 11
> 
> So one could have both. The question is, which one should be the
> "default" mode and which one should be subject to special constructs.

You are not wrong.  The above example will work fine in CL, though we usually
(by convention, not requirement) use *'s around a variable that is 'special'
(dynamically bound) so that people don't get confused.  We would usually
write:

 (defvar *x* 1)
 (defun y (a) (+ *x* 1))
 (y 1) => 2
 (let ((*x* 10)) (y 1)) => 11

Further, even a variable not defined with defvar can be on a one-time basis
bound dynamically in CL by declaring it locally special.  In this case, we
still encourage *'s, but it's more common for that to be violated. e.g.,

 (let ((x 1) (y 2))
   (declare (special x y))
   (eval '(+ x y))) => 3

Without the special declaration, this would signal an error since an x and
y bound lexically would not be visible to eval.  It would be easy for an
elisp based on cl to offer a macro like:

 (defmacro dynamic-let (bindings &body forms)
   `(let ,bindings
      (declare (special ,@(mapcar #'car bindings)))
      ,@forms))

so that

 (dynamic-let ((x 1) (y 2))
   (eval '(+ x y)))

would expand to the previous 'let' expression, in the rare case that a defvar
had not been done but a dynamic binding was still wanted.

Re: Differences between Elisp and Lisp

[Phillip Lord]

>>>>> "Kent" == Kent M Pitman <pitman@world.std.com> writes:

  Kent> Thomas Link <samul@web.de> writes:

  >> > I thought that CL already implemented lexical binding? At least
  >> >within a let form (or "lexical-let").
  >> I guess it's faking lexical binding by replacing variable names
  >> with gensyms. This makes it pseudo-lexical but not more
  >> efficient.

  Kent> In addition to having questionable efficiency issues, such a
  Kent> strategy also eliminates the one primary reason that more than
  Kent> anything justifies lexical scoping--the ability to know 'just
  Kent> by looking' that no other uses of the variable exist and that
  Kent> it's ok to optimize. 

Perhaps I am confusing things here, but I always assumed that the
problem with dynamic binding is that it makes odd things happen.

So take...

(defvar x 1)

(defun test()
  (let ((x 10))
    (test2)
    (message "test: %s" x)))

(defun test2()
  (setq x 20))

(test)

x


Eval'ing (test) gives "test: 20", and x gives 1.
If you change the let to lexical-let you get
"test:10" and "20". This seems much more intuitive to me. Of course
its useful to be able to "subvert" the setq in test2 to not work on
the main defvar defined x, and I've used this occasionally. But in
general its likely to result in program errors, as the test function
needs to know that none of the functions it use a variable called x.

Optimisation might be an issue as well of course, but processors are
fast these days! Its nice, but not essential. 


Cheers

Phil

Re: Differences between Elisp and Lisp

[Kent M Pitman]

Phillip Lord <p.lord@russet.org.uk> writes:

> >>>>> "Kent" == Kent M Pitman <pitman@world.std.com> writes:
> 
>   Kent> Thomas Link <samul@web.de> writes:
> 
>   >> > I thought that CL already implemented lexical binding? At least
>   >> >within a let form (or "lexical-let").
>   >> I guess it's faking lexical binding by replacing variable names
>   >> with gensyms. This makes it pseudo-lexical but not more
>   >> efficient.
> 
>   Kent> In addition to having questionable efficiency issues, such a
>   Kent> strategy also eliminates the one primary reason that more than
>   Kent> anything justifies lexical scoping--the ability to know 'just
>   Kent> by looking' that no other uses of the variable exist and that
>   Kent> it's ok to optimize. 
> 
> Perhaps I am confusing things here, but I always assumed that the
> problem with dynamic binding is that it makes odd things happen.

You're saying the same thing as I was saying only in different words.
Both the efficiency loss and this other effect you cite (accessibility
from outside) are effects of having the name be accessible from the
outside.  In general, both a programmer and a compiler have the same
interest--to know when they see a binding or a reference or an assignment
whether the variable involved is private or public.  When you make the 
default be 'public', the problem is that lots of things get made public
that don't need to be, and this both makes it hard to optimize and 
makes it likely that errors will creep in due to unwanted assignments
or even sometimes unwanted reads.

> So take...
> 
> (defvar x 1)
> 
> (defun test()
>   (let ((x 10))
>     (test2)
>     (message "test: %s" x)))
> 
> (defun test2()
>   (setq x 20))
> 
> (test)
> 
> x
> 
> 
> Eval'ing (test) gives "test: 20", and x gives 1.
> If you change the let to lexical-let you get
> "test:10" and "20". This seems much more intuitive to me. Of course
> its useful to be able to "subvert" the setq in test2 to not work on
> the main defvar defined x, and I've used this occasionally. But in
> general its likely to result in program errors, as the test function
> needs to know that none of the functions it use a variable called x.
> 
> Optimisation might be an issue as well of course, but processors are
> fast these days! Its nice, but not essential. 

This sort of assumes a single-user machine.  Server machines can be
overloaded regardless of capacity.  Efficiency determines the 
the size of the working set, the number of processes you can give the 
illusion of running at the same time when time-slicing, etc.  Ultimately,
when a server is overloaded, you have to buy a new machine.  It's nice to
stave this off by not being gratuitously inefficient.  Further, even on
a single-user machine,  if you have other programs running in background
(whether that means trying to get some editing done in Emacs during
the half hour it takes Photoshop to start, or it means playing some 
compute-intensive video game on the same processor where you're editing),
efficiency can still matter.

You might assume emacs is not a server, but one of the good effects of
merging CL and emacs might be that emacs could do more tasks that are
often relegated to other programs and that those other programs could get
some of the services emacs usually does.  So the lines might get blurred.

Re: Differences between Elisp and Lisp

[Phillip Lord]

>>>>> "Kent" == Kent M Pitman <pitman@world.std.com> writes:

  >> Perhaps I am confusing things here, but I always assumed that the
  >> problem with dynamic binding is that it makes odd things happen.

  Kent> You're saying the same thing as I was saying only in different
  Kent> words.  Both the efficiency loss and this other effect you
  Kent> cite (accessibility from outside) are effects of having the
  Kent> name be accessible from the outside. 

Yes, you are correct here. For the user within emacs, its just that
the effect on the programmer is probably more of an issue that the
optimisation. 

Obviously if fixing the former, gives you the latter for free, then
this is a good thing. 


  >> Optimisation might be an issue as well of course, but processors
  >> are fast these days! Its nice, but not essential.

  Kent> This sort of assumes a single-user machine.  Server machines
  Kent> can be overloaded regardless of capacity. 

A reasonable assumption in the context of emacs!

  Kent> You might assume emacs is not a server, but one of the good
  Kent> effects of merging CL and emacs might be that emacs could do
  Kent> more tasks that are often relegated to other programs and that
  Kent> those other programs could get some of the services emacs
  Kent> usually does.  So the lines might get blurred.

This is certainly true. I can imagine a emacs based web server would
be quite nice, as you could use all the emacs based formatting
abilities.

I think we are in furious agreement here!

Phil

Re: Differences between Elisp and Lisp

[Kai Großjohann]

Phillip Lord <p.lord@russet.org.uk> writes:

> This is certainly true. I can imagine a emacs based web server would
> be quite nice, as you could use all the emacs based formatting
> abilities.

Do you know that this exists?

-- 
file-error; Data: (Opening input file no such file or directory ~/.signature)

Re: Differences between Elisp and Lisp

[Phillip Lord]

>>>>> "Kai" == Kai Großjohann <kai.grossjohann@gmx.net> writes:

  Kai> Phillip Lord <p.lord@russet.org.uk> writes:

  >> This is certainly true. I can imagine a emacs based web server
  >> would be quite nice, as you could use all the emacs based
  >> formatting abilities.

  Kai> Do you know that this exists?

An emacs web server? I'd seen some stuff on this, I wasn't sure what
its state was. 

Phil

Re: Differences between Elisp and Lisp

[Kai Großjohann]

Phillip Lord <p.lord@russet.org.uk> writes:

> An emacs web server? I'd seen some stuff on this, I wasn't sure what
> its state was. 

Well, I'm not sure about the state, but it has been announced.  And
rumor has it that there are people actually using it...

-- 
file-error; Data: (Opening input file no such file or directory ~/.signature)

Re: Differences between Elisp and Lisp

[Kevin Rodgers]

Phillip Lord wrote:

>>>>>>"Kai" == Kai Großjohann <kai.grossjohann@gmx.net> writes:
>>>>>>
> 
>   Kai> Phillip Lord <p.lord@russet.org.uk> writes:
> 
>   >> This is certainly true. I can imagine a emacs based web server
>   >> would be quite nice, as you could use all the emacs based
>   >> formatting abilities.
> 
>   Kai> Do you know that this exists?
> 
> An emacs web server? I'd seen some stuff on this, I wasn't sure what
> its state was. 

Newsgroups: gnu.emacs.sources
Subject: httpd-serve 1.27 (for emacs-wiki)
From: John Wiegley <johnw@gnu.org>
X-Home-Page: http://www.gci-net.com/users/j/johnw/
X-Public-Key: http://pgp5.ai.mit.edu:11371/pks/lookup?op=get&search=0xF40524D0
Date: Thu, 25 Oct 2001 17:15:54 -0700
Message-ID: <m3lmhzmf2d.fsf@alice.dynodns.net>
User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1
Content-Type: text/plain; charset=us-ascii
Lines: 653
MIME-Version: 1.0
Sender: John Wiegley <johnw@gnu.org>
Mail-To-News-Contact: postmaster@nym.alias.net
Organization: mail2news@nym.alias.net
Xref: uni-berlin.de gnu.emacs.sources:10027


httpd-serve is a Python HTTP server, which uses a dedicated Emacs
process to serve Wiki pages directly.  It supports editing of pages,
dynamic search queries (if glimpse is installed), etc.

This new version supports gzip'd .html files (i.e., a reference to
foo.html will serve either foo.html or foo.html.gz).  It also fixes
several bugs, and adds a nasty LIMITATIONS section at the beginning of
the script file.

This server has been working stably on alice.dynodns.net for several
months, and is capable of serving around 100 pages/sec.  Be sure to
read the directions both in this script, and in emacs-wiki.  Send mail
to me if you have troubles getting it setup.  Maybe we can work out a
HOWTO together... :)

John Wiegley <johnw@gnu.org>

----------------------------------------------------------------------
#!/usr/bin/env python

# $Revision: 1.27 $
#
# A simple HTTP server, written in Python, that can be used to serve
# Emacs Wiki pages directly from a running Emacs process.
#
# Usage is simple:
#
#   httpd-serve --port 8080 --load ~/Emacs/startup.el /var/www
#
# This will start a dedicated Emacs session, and will listen on port
# 8080 for HTTP requests.  If the request is for a plain file, it will
# be served directly from /var/www -- without using Emacs.  If the
# request is not for a plain file, it is passed to Emacs' httpd.el.
#
# startup.el should contain any startup routines you wish to load into
# your Emacs web server.
#
# NOTE: This script has only been test on Debian GNU/Linux, using
# gnuserv 2.1alpha (with Unix domain sockets), and Python's pty
# module.  See my web page for updates or new versions:
#
#   http://www.gci-net.com/users/j/johnw/emacs.html
#
# LIMITATIONS: The only flaw known so far is that httpd-serve must
# have access to an X server.  This is not necessary on all systems,
# and sometimes a plain pty works just fine.  You can try setting
# no_wins=1 at the top of this file.  If that works, and you're able
# to serve pages, you should not need to run httpd-serve under X.
#
# John Wiegley <johnw@gnu.org>

-- 
<a href="mailto:&lt;kevin.rodgers&#64;ihs.com&gt;">Kevin Rodgers</a>

Re: Differences between Elisp and Lisp

[Oliver Scholz]

Phillip Lord <p.lord@russet.org.uk> writes:
[...]
> Optimisation might be an issue as well of course, but processors are
> fast these days! Its nice, but not essential. 
[...]

I disagree strongly. Emacs/W3 for example is sloooow, even on my 1,5
GHtz machine. I think there are a lot of possible applications for
Emacs, that would be too slow in Elisp and which—this is just a guess,
of course—nobody implements for this very reason. How about an SVG or
Postscript interpreter written in Elisp, for example? Or other fancy
stuff, that we don't even imagine right now? (I would have thought
that images are “nice, but not essential”, until D. Kastrup wrote
preview-latex. So who could guess what possible could come out, if
Elisp would be by a magnitude more efficient?)

BTW, I always wondered whether Elisp is partly to blame for the fact
that the myth of Lisp being a “slow interpreted language” continues
to live. Most of my friends which are interested into computers have
never heard about CL (until I told them, that is), but they have
heard that Emacs is partly written in Lisp.

    Oliver
-- 
10 Floréal an 211 de la Révolution
Liberté, Egalité, Fraternité!

Re: Differences between Elisp and Lisp

[Phillip Lord]

>>>>> "os" == Oliver Scholz <alkibiades@gmx.de> writes:

  os> Phillip Lord <p.lord@russet.org.uk> writes: [...]
  >> Optimisation might be an issue as well of course, but processors
  >> are fast these days! Its nice, but not essential.
  os> [...]

  os> I disagree strongly. Emacs/W3 for example is sloooow, even on my
  os> 1,5 GHtz machine.


Indeed. 

I am not arguing that optimisation is a bad thing. I was just
suggesting that there are other concerns, which might be more
pressing. 

  os> BTW, I always wondered whether Elisp is partly to blame for the
  os> fact that the myth of Lisp being a “slow interpreted language”
  os> continues to live. Most of my friends which are interested into
  os> computers have never heard about CL (until I told them, that
  os> is), but they have heard that Emacs is partly written in Lisp.

It's possible, although the idea that lisp is slow predates emacs lisp
by a reasonable time. It would certainly be interesting to see how
much faster emacs would be if it were based on one of the common lisp
machines. 

Cheers

Phil

Re: Differences between Elisp and Lisp

[Kai Großjohann]

Phillip Lord <p.lord@russet.org.uk> writes:

> If emacs just went to using lexical binding in the large, I suspect
> that it would cause lots of problems with existing packages. I have
> used dynamic scoping to achieve ends in the past, which might be a bit
> nasty, but it does work!

In fact, making use of dynamic scoping is done *very* often in Emacs.

But in almost all cases, the variables dynamically bound have
previously been defined via defvar, so making those variables behave
dynamically gives you the best of both worlds.

Michael Sperber has done a code audit of the XEmacs Lisp code, IIRC,
and found no or few problems with this approach for lexical/dynamic
scoping.

-- 
file-error; Data: (Opening input file no such file or directory ~/.signature)

Re: Differences between Elisp and Lisp

[Stefan Monnier]

>>>>> "Lars" == Lars Magne Ingebrigtsen <lmi@gnus.org> writes:
> and dispatching functions based on type would be nice.

Never heard that one.  What exactly would you like to see ?

> But there are really only two things that I think are really important.
> 1) Emacs Lisp is kinda slow.
> 2) Emacs Lisp is single threaded.

And both of those are very difficult to fix without first switching to
lexical scoping (which might be done by switching to CommonLisp, or Scheme,
or by modifying elisp, or whatever else).


        Stefan

Re: Differences between Elisp and Lisp

[Lars Magne Ingebrigtsen]

"Stefan Monnier" <monnier+gnu.emacs.help/news/@flint.cs.yale.edu> writes:

>>>>>> "Lars" == Lars Magne Ingebrigtsen <lmi@gnus.org> writes:
>> and dispatching functions based on type would be nice.
>
> Never heard that one.  What exactly would you like to see ?

The Common Lisp `defmethod' thingie.  Which is a part of CLOS, I
guess, but wouldn't have to be.  But one would need a type system.

(defmethod do-stuff ((arg string))
  ... do stuff with a string)

(defmethod do-stuff ((arg number))
  ... do stuff with a number)

And then one could just say (do-stuff whatever) here and there.

This is really just syntactical sugar on the "pattern"

(defun do-stuff (arg)
  (cond ((stringp arg)
         ... do stuff with a string)
        ((numberp arg)
         ... do stuff with a number)))

but it's really useful.  Especially when you're able to define your
own classes.  Er, types.

Perhaps eieio already provides this?
  
-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Differences between Elisp and Lisp

[Friedrich Dominicus]

Lars Magne Ingebrigtsen <lmi@gnus.org> writes:

> "Stefan Monnier" <monnier+gnu.emacs.help/news/@flint.cs.yale.edu> writes:
> 
> >>>>>> "Lars" == Lars Magne Ingebrigtsen <lmi@gnus.org> writes:
> >> and dispatching functions based on type would be nice.
> >
> > Never heard that one.  What exactly would you like to see ?
> 
> The Common Lisp `defmethod' thingie.  Which is a part of CLOS, I
> guess, but wouldn't have to be.  But one would need a type system.

> 
> (defmethod do-stuff ((arg string))
>   ... do stuff with a string)
> 
> (defmethod do-stuff ((arg number))
>   ... do stuff with a number)
What you have missed you can have dispatch on multiple parameters
(that does not work with eieio)

(defmethod (do-stuff ((arg-1 string) (arg-2 string) ....



> 
> And then one could just say (do-stuff whatever) here and there.

> 
> This is really just syntactical sugar on the "pattern"
Not fully.

> 
> Perhaps eieio already provides this?
Partly, it just allows the first parameter to be constrained.

Here and example 

;;; eieio-example.el --- Example for defmethod in eieio


(require 'eieio)
(defclass some-num ()
  ((val :accessor val :initarg :val)))


(defclass some-string ()
  ((val :accessor val :initarg :val)))


(defmethod g+ ((val some-num) val-2)
  (+ (val val) val-2))

(defmethod g+ ((val some-string) val-2)
  (concatenate 'string (val val) val-2))


usage:

(g+ (make-instance 'some-num :val 10) 10) -> 20
(g+ (make-instance 'some-string :val "foo") "bar" -> "foobar"

Not that this is a good example, but it shows how that stuff works 


Regards
Friedrich

Re: Differences between Elisp and Lisp

[Lars Magne Ingebrigtsen]

Friedrich Dominicus <frido@q-software-solutions.com> writes:

>> Perhaps eieio already provides this?
> Partly, it just allows the first parameter to be constrained.

Well, that's a lot better than having despatch on no parameters.  :-)

In my experience, I find that it's quite rare for me to despatch on
more parameters, really...  (When I'm writing Common Lisp.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Differences between Elisp and Lisp

[Kent M Pitman]

bojohan+news@dd.chalmers.se (Johan Bockgård) writes:

> From gnu.emacs.help, followup-to set to gnu.emacs.help
> 
> "Daniel R. Anderson" <dan@mathjunkies.com> writes:
> 
> > On emacswiki.org there is a "wish list". Quite a few people want
> > emacs to be based on another version of LISP. Out of curiosity, what
> > is it that makes elisp inherently bad, or why would people want it
> > to be changed?

I hope the following information is taken as constructive.  (Why does
something in the back of my mind warn me to just decline to respond?
Usenet is so unpredictable.)  It is impossible to speak on this matter
without appearing to invite controversy, but that is not my intent.
The question you have asked is clearly a call for opinions and the
notes below are just my personal opinion.  Others should presumably
share their own opinions, and doubtless some will differ from mine,
but it would be better if such conflicting opinions were offered in
response to your original question than in response to my answer.

I don't know that I think that elisp is `inherently bad' so much as
`gratuitously different'.  That is, a lot of stuff between CL and Lisp
are culturally similar, but if you were to read a book on ANSI CL, you
would be told to do a lot of stuff that when you try it in elisp
doesn't work.

A number of Lisp dialects are what they are because they represent a
desire to show a new kind of power or a new technique.  From where I
sit, elisp was not this.  It was an attempt to hold onto a vestige of
the past, when Common Lisp was emerging and Stallman didn't like it.
I urged Stallman at that time to make elisp be compatible with Common 
Lisp in its core elements so that we could share a user community, but
my recollection is that he told me CL had abandoned the dynamic nature
(special variables) that were so important to the construction of a
scripting language.

I would (probably slightly oversimplifying, but for purposes of making
a point) characterize elisp as being a dialect that began less "about
something" and more "about not-something".  For this reason, I think
it is linguistically undistinguished.  Implementationally, certainly,
it has a proud history, but I don't think that history would have gone
much differently with a different dialect of Lisp.  The key
empowerment was the set of emacs-related data structures and the tight
integration with emacs.  It would be better for Lisp overall if there
were fewer dialects [some call them languages], since there would be
more cross-play of cultures and there could be more sharing of code,
education, etc.  (The big question then becomes which dialect to merge
with.  CL and Scheme present themselves as obvious choices.)

I also think, to some degree, that this is an issue of competition
among political parties.  (My 1995 paper
http://www.nhplace.com/kent/PS/Lambda.html is a bit dated in some
ways, but addresses the issue of languages as political parties and
will clarify (for those who care) what I mean by this, if it's not
clear just from context.)  That is, Stallman may have wanted to retain
a sense of control that perhaps he felt he would lose by going with
CL, which at that time was a moving target not controlled by him.
ANSI CL is stable for nearly a decade, and being compatible with it no
longer means being hostage to a committee, so I don't see that as the
political issue it might once have been.  And certainly nothing
requires one to take all of ANSI CL--one could just subset out the
parts that are useful to elisp if there was an issue about not wanting
the entire language.  Just having the core language align would be
very helpful to the Lisp community as a whole.

At this point, my understanding is that the Emacs community has come
to understand that lexicality is good and that elisp should have gone
with it.  I know there is some pressure to go with Scheme because it's
small and simple, but I think its 'style' is more different than CL's
is, and my sense is that changing to Scheme would be a bigger change.
That is, I think elisp is more of a Lisp than a Scheme (if you think
those two are different, which I do).  For example, elisp has multiple
namespaces and it would be a point of major incompatibility to move it
to a single namespace.  Moving to a single namespace [as Scheme does]
causes, I claim, the need for a complete overhaul of the macro system.
Scheme advocates sometimes assert that their so-called "hygienic macros"
are needed by all lisps, and sometimes speak with disdain about Common
Lisp for its lack of hygiene, but the truth is that the protective divisions
among modules are achieved differently in CL (through package separations
and namespace separations), and that allows a consequentially simpler
macro system for which I'll here coin the term "aequately hygienic".

I also think that in spite of the joy that the Scheme community takes over
its 'formal semantics', the fact is that the spec is quite ill-defined
on the issue of how to manage unwind-protect exactly because it interacts
very badly with call/cc.  Because emacs relies heavily on unwind-protect
and needs to have deterministic behavior in this area, I really don't
recommend getting into the call/cc issue unless you're SURE you have
resolved this issue and I really don't see how to resolve the issue without
confronting some pretty basic problems in the Scheme design that no one
seems to want to admit are even there. See my comp.lang.lisp article
 http://groups.google.com/groups?selm=sfwn1ic516r.fsf%40world.std.com

There is the sometimes issue of tail-call elimination which sometimes
separates the CL and Scheme community.  CL does not require it, but it
does permit it.  It would be CL-compliant to make elisp, as either an
implementation or subdialect, permit so-called "proper" tail-call
elimination (assuming that care was taken not to do this across things
that necessarily push stack, like special variable bindings.  (I would
like to see this part not become a subject of major debate since I
think it can be resolved in a way that is favorable to both
communities without huge amounts of wasted hot air.)

More subjectively, I feel Scheme has an implicit element to it, which
is that 'functional programming' is fundamentally empowering.  That
is, it's not just trying to empower the programmer but also trying to
push a particular message about how one ought to feel empowered and,
implicitly, how one ought not.  Common Lisp is much more agnostic
about paradigm, by explicit intent.  It tries to offer features that
are accomodate those with 'imperative', 'functional', and 'object
oriented' styles, leaving it to the programmer to figure out how to
structure programs.  In my experience, many members of the Scheme 
community have greeted the variation of options CL provides with disdain
because (apparently) it is not about a simple set of common principles.
But I, and many CL people, see this simply as an issue of 'tolerance'.
The elisp community is very large, and while there will _surely_ be
numerous (and probably vocal) Scheme advocates among them, I don't 
imagine that every one of them wants to be forced into the functional
programming mold.  Incidentally, I have the same issue with other single
paradigm languages--Smalltalk is, like Scheme, a very pretty design but
is not how I want to structure _my_ programs, and it doesn't leave room
for my way of thinking.

One option that would allow both paradigms might be to do like AutoCad
did and separate the notion of 'library' and 'datastructures' from the
issue of 'language'.  In that way, you might be able to design a system
where you could elect to program in any of several languages using the
same stack, data, error handling as glue between them.  In that world,
both Scheme and CL (or a CL subset) could survive, as well as perhaps
other languages, if someone were interested to provide such.  I don't
really so much want to keep people from programming in Scheme [if you
can address that unwind-protect issue, which I think is a real technical
concern] as to assure that people who are used to programming in a certain
Lisp style already aren't told they no longer can.  If there's a way to
frame this as "increasing one's options" instead of "one political party
triumphing over another", that would be superior in my view.

[Incidentally, thank you for NOT having cross-posted this to multiple
 communities.  I don't think very useful dialog happens that way.
 I routinely decline to involve myself in cross-posted discussions.
   http://www.nhplace.com/kent/PFAQ/cross-posting.html
]

Re: Differences between Elisp and Lisp

[Nicolas Neuss]

Kent M Pitman <pitman@world.std.com> writes:

> [important article]

Thanks for this contribution.  I hope RMS listens, too.  So much time has
been lost already...

Only some comments to this paragraph:

> One option that would allow both paradigms might be to do like AutoCad
> did and separate the notion of 'library' and 'datastructures' from the
> issue of 'language'.  In that way, you might be able to design a system
> where you could elect to program in any of several languages using the
> same stack, data, error handling as glue between them.  In that world,
> both Scheme and CL (or a CL subset) could survive, as well as perhaps
> other languages, if someone were interested to provide such.  I don't
> really so much want to keep people from programming in Scheme [if you
> can address that unwind-protect issue, which I think is a real technical
> concern] as to assure that people who are used to programming in a certain
> Lisp style already aren't told they no longer can.  If there's a way to
> frame this as "increasing one's options" instead of "one political party
> triumphing over another", that would be superior in my view.

I want to add that such a multiple language environment should better be
based on CL than on Scheme.  At least, it is possible to imbed languages
like Scheme and Prolog [1] in CL (in contrast to what Guile can currently
do).

Maybe the best possibility would be to replace elisp with GCL (which is
C-based and should be similarly portable as gcc and emacs).

Nicolas.

[1] See Norvig's PAIP.

Re: Differences between Elisp and Lisp

[Nicolas Neuss]

Nicolas Neuss <Nicolas.Neuss@iwr.uni-heidelberg.de> writes:

> Maybe the best possibility would be to replace elisp with GCL (which is
> C-based and should be similarly portable as gcc and emacs).

Or CLISP.  This would probably result in a slower Emacs than going with
GCL, because CLISP does compile only to bytecode (as Elisp).  Best, of
course, would be to have Emacs working with both:-)

Nicolas.

Re: Differences between Elisp and Lisp

[Marco Antoniotti]

Johan Bockgård wrote:

> From gnu.emacs.help, followup-to set to gnu.emacs.help
>
> "Daniel R. Anderson"  writes:
>
>
> >On emacswiki.org there is a "wish list". Quite a few people want
> >emacs to be based on another version of LISP. Out of curiosity, what
> >is it that makes elisp inherently bad, or why would people want it
> >to be changed?


I'll skip the first one.  For the second I'd wager that people *know* 
that Common Lisp is the right answer and people would love to see RMS 
admit that he messed up royally by promoting Guile :)

Cheers

--
Marco Antoniotti

Re: Differences between Elisp and Lisp

[Phillip Lord]

>>>>> "Marco" == Marco Antoniotti <marcoxa@cs.nyu.edu> writes:

  Marco> Johan Bockgård wrote:

  >> From gnu.emacs.help, followup-to set to gnu.emacs.help
  >>
  >> "Daniel R. Anderson" writes:
  >>
  >>
  >> >On emacswiki.org there is a "wish list". Quite a few people want
  >> >emacs to be based on another version of LISP. Out of curiosity,
  >> >what is it that makes elisp inherently bad, or why would people
  >> >want it to be changed?


  Marco> I'll skip the first one.  For the second I'd wager that
  Marco> people *know* that Common Lisp is the right answer and people
  Marco> would love to see RMS admit that he messed up royally by
  Marco> promoting Guile :)


For me the issue is more simple I think. I would Emacs to be using a
lisp which was not specific to emacs, as it would probably stop so
much wheel reinvention. There is too much code in emacs, that was
written for emacs, in my own estimation. 

I'd just be happy to have a more powerful lisp that's all. Should it
be CL or scheme? From my perspective, I couldn't care that much for a
simple reason. I learnt lisp because I use emacs, rather than the
other way around. I only known elisp in detail. Which ever one emacs
goes with, will be the one that I learn!

Cheers

Phil

Re: Differences between Elisp and Lisp

[Oliver Scholz]

Phillip Lord <p.lord@russet.org.uk> writes:
[...]
> For me the issue is more simple I think. I would Emacs to be using a
> lisp which was not specific to emacs, as it would probably stop so
> much wheel reinvention. There is too much code in emacs, that was
> written for emacs, in my own estimation. 
>
> I'd just be happy to have a more powerful lisp that's all. Should it
> be CL or scheme? From my perspective, I couldn't care that much for a
> simple reason. I learnt lisp because I use emacs, rather than the
> other way around. I only known elisp in detail. Which ever one emacs
> goes with, will be the one that I learn!
[...]

Amen.

For me Elisp was the first programming language I started to use in
earnest and it is still my mother tongue.

If I had to choose between CL and Scheme, I'd prefer CL (for various
reasons; the fact that I find it easier to read CL code due to it's
similarity to Elisp not being the last one). But I won't complain if
it's Scheme. After all Emacs will provide the libraries and the
environment; so it is “Elisp-as-a-subset-of-CL vs. Escheme” rather
than “CL vs. Scheme”.


    Oliver
-- 
10 Floréal an 211 de la Révolution
Liberté, Egalité, Fraternité!

Re: Differences between Elisp and Lisp

[Kaz Kylheku]

"Daniel R. Anderson" <dan@mathjunkies.com> wrote in message news:<mailman.5343.1051607007.21513.help-gnu-emacs@gnu.org>...
> On emacswiki.org there is a "wish list".  Quite a few people want emacs
> to be based on another version of LISP.

By the way, take a look at Hemlock: http://www.cons.org/cmucl/hemlock