Re: Closures versus objects

On 20 Feb 2007, at 17:13, James Y Knight wrote:

> On Feb 20, 2007, at 2:49 AM, Pascal Costanza wrote:
>> On 20 Feb 2007, at 04:58, Dave Roberts wrote:
>>> Which brings up a good point. Given this observation, why wasn't  
>>> LENGTH
>>> made a GF when CL was specified? Was CLOS such a late addition and
>>> everybody was afraid of the possible performance impact? Surely,  
>>> there
>>> was not technical reason that it couldn't have been made generic,  
>>> as you
>>> say; all old code would have continued working, no?
>>>
>>> Over the past couple years, I have really learned to appreciate  
>>> CLOS and
>>> this is one of those examples where it seems like a good idea wasn't
>>> taken far enough.
>>
>> Here is a quote from http://groups.google.com/group/comp.lang.lisp/ 
>> msg/3cad948789e116e9
>>
>> "The reason many operators are not generic [in Common Lisp] is  
>> that deciding how to do
>> them generically is tricky and people disagree on the definition. I
>> recall the NIL project (JonL White, Jonathan Rees, and Rick Bryan)  
>> ran
>> afoul of a generic definition for LENGTH enough that let us worry.  
>> Consider:
>>  (defmethod length ((x cons)) (+ 1 (length (cdr x))))
>>  (defmethod length ((x null)) 0)
>>  (defmethod length ((x string)) (array-dimension x 0))
>> Now think about
>>  (length '(a b . "foo"))
>> The point is that often independent definitions invite what I'll  
>> call the
>> "modularity problem" where definitions look ok in isolation but  
>> surprising
>> effects happen in combination.  Similar to what
>>  (+ 1 2 "foo")
>> might do if we allowed + to be generic."
>
> This seems like a bit of a strange argument. Consider that length,  
> as currently defined, does indeeed work on lists and strings. An  
> obvious implementation not using generic functions would be:
>
> (defun length (x)
>  (typecase x
>   (null 0)
>   (cons (+ 1 (length (cdr x))))
>   (string (array-dimension x 0))))
>
> which, of course, has the exact same behavior as the generic length  
> above. That choice of behavior is simply a choice in specification,  
> and really has very little to do with whether you use a generic  
> function or not.

I don't think the actual issue is whether and how length should be  
generic or not. Turning one specific function into a generic one is,  
of course, relatively easy. However, the actual issue is: which of  
all the already existing non-generic functions in Common Lisp should  
be turned into generic ones, and what are the resulting desired and/ 
or undesired interactions.

More specifically, I don't think that turning 'length into a generic  
function would be so interesting without thinking about sequences and  
collections in more general terms at the same time.

As far as I can tell, Dylan made some good progress in that regard.  
But I don't think Dylan fell from the sky in one day. ;)

(That's also the main point of Kent Pitman's remark: It's not that it  
is impossible to do this, but that it's hard.)


Pascal

-- 
Pascal Costanza, mailto:[email protected], http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium