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: <DEuCCs.FDy@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>
Date: Wed, 13 Sep 1995 11:10:02 GMT
Lines: 76

"Stefan Monnier" <stefan.monnier@epfl.ch> writes:

>In article <DEpGEr.BGL@cogsci.ed.ac.uk>,
>Jeff Dalton <jeff@cogsci.ed.ac.uk> wrote:
>] Julian -- what do you understand by "functions kept separate
>] from methods"?  I can think of three possibilities right away:
>] 
>]   1. Functions aren't *called* methods -- EuLisp doesn't use
>]      Dylan terminology on that point.
>] 
>]   2. Method objects are not functions (their class is not
>]      a subclass of function and they aren't callable).
>] 
>]   3. Some functions aren't generic.
>] 
>] For each, I can recall reasons *other than* avoiding gratuitous
>] incompatiblities with CL; and I think they were more important
>] than any considerations that involved CL.

>What I meant (don't know exactly what Julian understood) is that

>	(defun toto (x y)
>		...)

>Is not the same as

>	(defmethod toto (x y)
>		...)

>Because, for example you cannot later say

>	(defmethod toto ((x integer) (y list))
>		...)

Ok, that's essentially my number 3.  Thanks for the explanation.

>and I fail to see what is the reason of such a distinction.

Harley's given some efficiency/simplicity reasons, but I think
there are also some "conceptual" ones.  To put it over simply:
Procedures are a well-understood, useful construct, and a
useful primitive.  One reasonable kind of language design
aims for a small number of very general constructs; but it's
not the only reasonable kind.  For instance, it can also
make sense to provide good primitives as well as the "right"
higher-level constructs.  Also, in many cases a programmer
will want an ordinary procedure and not a generic (dispatching)
one.  By distinguishing between ordinary and generic functions,
EuLisp allows the programmer to express this in a simple and
natural way.

>On another hand, it would be really useful to be able to extend the
>standard CL functions to work in other circumstances by just using a
>defmethod.  For instance, if you create a 'set' datatype, yu might
>want to use the 'union', 'intersection' and 'difference' names so that
>you can use the same names if you use lists as sets or if you use
>'real' sets.

But such functions in EuLisp are probably generic.  And if they
aren't, someone could easily provide a module that supplies ones
that are.

>Basically the current situation forces you to create a new 'set-union'
>function (well, a generic function anyway since you're supposed to be
>"smart" enough to understand that if you implement it as a plain
>function you're doing the exact same mistake that you're trying to
>circumvent). that delegates to the 'union' function in case the
>argument is a list. And this is like reimplementing the dynamic
>dispatch by hand with all the related problems:

Come on, (defmethod set-union (...) (common-lisp:union ...)) is not
very like reimplementing the dynamic dispatch by hand.

-- jeff


