Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!oitnews.harvard.edu!newsfeed.rice.edu!bcm.tmc.edu!news.msfc.nasa.gov!newsfeed.internetmci.com!news.mathworks.com!tank.news.pipex.net!pipex!oleane!jussieu.fr!univ-lyon1.fr!news-rocq.inria.fr!news2.EUnet.fr!news.fnet.fr!ilog!news
From: davis@ilog.fr (Harley Davis)
Subject: Re: EuLisp status
In-Reply-To: jeff@cogsci.ed.ac.uk's message of Sun, 10 Sep 1995 19:49:38 GMT
Message-ID: <DAVIS.95Sep11131133@halles.ilog.fr>
Lines: 47
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>
Date: 11 Sep 1995 11:11:33 GMT


In article <DEpGEr.BGL@cogsci.ed.ac.uk> jeff@cogsci.ed.ac.uk (Jeff Dalton) writes:

> >    From what I read about EuLisp, it seems like functions are kept
> >    separate from methods, as is the case in common-lisp. What I mean
> >    by separate, is that a function is not considered as a method with
> >    non-specialized arguments. I kind of understood also that, just
> >    like in CL, standard operators are functions (not methods). In
> >    case I'm not totally off-track, what is the reason why EuLisp kept
> >    this CL-way of dealing with methods and functions ?
> 
> >Umm...good question, with hindsight.  One of the design codas for
> >EuLisp, at least in the early days, was to avoid gratuitous
> >incompatiblities with CL (and to a lesser extent LeLisp (v15 for
> >afficionados)).  Consequently, we adopted the CL design on this issue.
> >I expect Kent (Pitman) can provide a detailed rationale for the CL
> >decision, so I won't pre-empt him.
> 
> 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.

I think Jeff is right.  I remember discussing this issue several times
in meetings, especially in the light of the Dylan design, and each
time we decided to keep non-generic functions for pretty legitimate
reasons.

-- Harley Davis
-- 

-------------------++** 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/

