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!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: <DEpGEr.BGL@cogsci.ed.ac.uk>
Organization: Centre for Cognitive Science, Edinburgh, UK
References: <9509051545.aa14389@mc.lcs.mit.edu>
Date: Sun, 10 Sep 1995 19:49:38 GMT
Lines: 43

jap@maths.bath.ac.UK writes:

>    To: scheme@mc.lcs.mit.edu
>    Date: 4 Sep 1995 12:51:37 GMT
>    From: Stefan Monnier <stefan.monnier@epfl.ch>
>    Subject: EuLisp status

>    In article <9509031630.aa04646@mc.lcs.mit.edu>,  <jap@maths.bath.ac.UK> wrote:
>    [...something about EuLisp...]

>    That reminds me:

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

-- jeff
