Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!oitnews.harvard.edu!purdue!lerc.nasa.gov!magnus.acs.ohio-state.edu!math.ohio-state.edu!howland.reston.ans.net!swrinde!tank.news.pipex.net!pipex!uknet!newsfeed.ed.ac.uk!edcogsci!jeff
From: jeff@cogsci.ed.ac.uk (Jeff Dalton)
Subject: Re: EuLisp status
Message-ID: <DEuBp7.Ezo@cogsci.ed.ac.uk>
Organization: Centre for Cognitive Science, Edinburgh, UK
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: Wed, 13 Sep 1995 10:55:53 GMT
Lines: 47

"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.

Also, the clever optimizations may require something from the
programmer (such as a declaration).

>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.

Patching code _can_ be a real pain.  Some systems make it impossible,
and some others make it very inefficient.  But, though this is true, 
I don't think it was a significant factor.

For a number of reasons (in which the above might play a small part),
the EuLisp definition doesn't address redefinition (eg of functions)
at all.  It was regarded as something that wasn't "part of the
language".  _Implementations_ are free to do what you suggest.

This view of redefinition eventually became fairly popular in the
Lisp community.  Indeed, towards the end, the Common Lisp standardisers
(X3J13) started to turn against the practice of defining redefinition,
even though much of CLOS is devoted to class redefinition.  The chief
effect of this turn was on the definition of defpackage.

(I am not trying to suggest that EuLisp had an influence here,
though it may have.)

-- jeff
