Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!rochester!cornellcs!travelers.mail.cornell.edu!news.kei.com!news.mathworks.com!tank.news.pipex.net!pipex!news.sprintlink.net!in2.uu.net!EU.net!julienas!news.fnet.fr!ilog!news
From: davis@ilog.fr (Harley Davis)
Subject: Re: EuLisp status
In-Reply-To: "Stefan Monnier"'s message of 12 Sep 1995 09:14:57 GMT
Message-ID: <DAVIS.95Sep13164856@halles.ilog.fr>
Lines: 82
Sender: news@ilog.fr
Nntp-Posting-Host: halles
Organization: Ilog SA, Gentilly, France
References: <9509051545.aa14389@mc.lcs.mit.edu> <DEpGEr.BGL@cogsci.ed.ac.uk>
	<431i3p$q32@info.epfl.ch> <DAVIS.95Sep11184050@halles.ilog.fr>
	<433j2h$an9@info.epfl.ch>
Date: 13 Sep 1995 14:48:55 GMT


In article <433j2h$an9@info.epfl.ch> "Stefan Monnier" <stefan.monnier@epfl.ch> writes:

> In article <DAVIS.95Sep11184050@halles.ilog.fr>,
> Harley Davis <davis@ilog.fr> wrote:
> ] When you start discussing this possibility, those of us who are
> ] efficiency freaks complain because you have to have an extra
> ] indirection to call functions even when there is only one global
> ] method.  The response is to think of clever optimizations like Dylan's
> ] sealing which will avoid this cost in certain cases.  But all of those
> ] optimizations require clever compilers, and one of EuLisp's explicit
> ] goals is to allow simple *and* efficient implementations.
> 
> How about:
> 
> the first defmethod is assumed to be a defun: you just create a
> plain function.  when the function is extended by another defmethod,
> create a brand new generic function (without reusing the old
> function) and patch the old plain function so that it immediately
> jumps to the new generic one (this is a like a forwarding pointer,
> but for code rather than data-structure. And you might later avoid
> the overhead of the forwarding pointer by having the GC redirect
> pointers to the old plain function to point to the new generic
> function). This doesn't look hard to implement except it requires
> being able to patch existing code. It doesn't impact the efficiency
> of "defuns", and only impacts the efficiency of defmethods if you
> take the closure and keep it somewhere between definition of the
> first and the second method.

I think this deserves a longer and more general response than I have
time for.  Let me just make the point that your suggestion is exactly
the kind of implementation complexity that I, anyway, would like to
avoid.  As I said, I would like to see both simple *and* efficient
implementations, and forwarding pointers in the GC do not count as
simple.  When I mean simple, I mean compared with C implementations,
not Common Lisp implementations.

Simplicity in the implementation is important to me for several
reasons.  Let me cite just two:

1. Most implementations of niche languages (indeed, any language) are
   severely resource-constrained, both in human and computational
   terms.  Time spent implemented sophisticated abstractions for
   marginal features is usually not a good investment; the time is
   better spent on fixing bugs, adding useful libraries,
   documentation, publicity, etc.

2. This kind of complexity generally has unexpected and undesirable
   side-effects.  I would imagine, for instance, that a system that
   has a GC which fiddles with pointers as you suggest will have an
   impact on other features which many people would value more than a
   unified defun/defmethod, such as easy-to-use FFIs and efficient
   hash tables.

If I were writing the more general reply that I would like, I would
develop these points to indicate why I think that Lispers in general
need to rethink their basic assumptions about good language design if
they want Lisp to have any kind of success in today's world.  Some of
this argument is shared with Gabriel's "worse-is-better" argument, but
I think it is possible to integrate elegance, functionality,
practicality, and simplicity without the result being "worse" in any
normal sense, and I would consider many aspects of EuLisp to be a
proof of this.

> And don't forget that the end result of having defun and defmethod
> separate is that the implementor assumes the user uses defun when he
> doesn't need the full power of defmethod, which means that using
> defmethods in cases where defun would have been sufficient will not
> be as efficient, and hence people will keep on using defuns, ...

One way to make defmethod as efficient as defun is to always add the
extra indiretion in defun functions, even though they don't need it...

-- Harley
-- 

-------------------++** Ilog has moved! **++----------------------------
Harley Davis                            net: davis@ilog.fr
Ilog S.A.                               tel: +33 1 49 08 35 00
9, rue de Verdun, BP 85                 fax: +33 1 49 08 35 10
94253 Gentilly Cedex, France            url: http://www.ilog.com/

