Re: Re: Generic Length (was: Closures versus objects)

>>     But what about the times you want to iterate over the "well known"
>> interpretation of the number of elements in an object, and want to use
>> one generic to do it?  This could still work, if you recognize that
>> the *initial* dispatch based on type selects the *kind* of length to
>> apply recursively to the rest of the object.  Then once you have
>> started looking at an object in terms of collection-length, it would
>> be a logic error to switch to string-length for the tail of the
>> object.  Thus a single generic would give well-defined answers for
>> proper lists, strings, and improper lists ending in strings.
>
> That is exactly how a generic length should behave, with the caveat you
> added:
>
>>     Note that it may not be immediately intuitive what the answer is in
>> the last case though

    It may be only a matter of semantic disagreement.  The definition of
'length' you support implies that string lengths are a different kind
of thing than list lengths.  For if you substitute a string-tail with
a cons-tail, the list is converted from improper to proper and
'length' now works on it.  If string arrays were the same sort of
thing as lists, 'length' and other primitives that iterate over
collections would not see a transition where the two objects meet.