[Openmcl-devel] Applying sequence functions to a new type

[Andrew P. Lentvorski, Jr.]

On Mar 1, 2005, at 9:18 PM, Gary Byers wrote:

> One factor is that types like SEQUENCE (and LIST, and NUMBER, and 
> FIXNUM)
> existed for a long time before CLOS did; large bodies of code had and
> continue to have very concrete ideas about what it means for something
> to be a NUMBER or a SEQUENCE or a FIXNUM or a BIT or a PACKAGE or ...

Ah, that wasn't clear to me.  I presumed that sequence was purely a 
type that made its appearance with CLOS.

> At the other extreme, some BUILT-IN-CLASSes are pretty concrete; it'd
> arguably be less of a good idea to make INTEGER extensible:
>
> (defgeneric integerp (x)
>   :documentation
>    "It's an integer if I say it is! (and if I define a few methods.)")

I'm not so concerned about inheriting from built-in types.  I was more 
interested in allowing people to use the Common Lisp functions on new 
types.  Many of the modern dynamic languages sort of use what the 
Python folks call "Duck typing".  If it waddles like a duck, swims like 
a duck, and quacks like a duck then it can be used like a duck.  That 
fact that it might actually be a mutant chicken is not necessarily 
relevant. ;)

> When CLOS was introduced into CL, someone could have said "You know,
> CL's notion of what a SEQUENCE is is too restrictive; someday, users
> may think of a SEQUENCE as being an abstract data type, and we should
> change the language to allow that."  (David Gray -did- say almost
> exactly that about STREAM in that time frame.)  As far as I know and
> remember, no one said that.  I think that it would have been a hard
> sell, since there was already a lot of code which had a pretty clear
> (rigid) idea of what it meant for something to be of type CL:SEQUENCE,
> and of what it meant for something -not- to be of that type.  I'm not
> sure if it'd be an easier sell today.

Probably not.  Given that both the sequence types and the sequence 
functions predate the standard and CLOS, fiddling with them is probably 
not a good idea.

> if people read my message earlier today and were left with the 
> impression
> that CLOS contains a "nasty limitation" through lack of foresight
> or sophistication on the part of its designers or adopters (or that
> no one thought about these issues deeply 15 years ago, or that there
> wasn't any debate or consideration given to other approaches ...) well,
> I may have been a little too terse.

Well, the limitation exists even if it *was* a conscious design choice. 
  My query was more a question as to whether it was simply an historical 
artifact that could be removed with some coding or whether it would 
have to be left alone.  Your response pretty much validates that it has 
to be left alone.

> I personally believe that the
> decision to make large parts of the type/class hierarchy closed (non-
> extensible) was more right than wrong, and I wish that I could be a
> little more succinct in explaining why I believe that.

There are lots of people in the Java community who hate this type of 
finalization.

> People may be left with the impression that Common lisp really should
> have an extensible abstract protocol for defining SEQUENCE-like methods
> on SEQUENCE-like objects.  There is not (and never has been) anything
> stopping anyone from developing such a library, aside from the fact 
> that
> designing something general and usable is hard.

Well, it also winds up not being a basic part of Common Lisp.  It winds 
up being like the Standard Template Library for C++.  That only took 
*how* many years before it's existence could actually be assumed?  
Fortunately, Common Lisp does not have the same level of baseline 
incompatibility problems that the C++ compilers had.

Thanks for taking the time to write such a detailed explanation,
-a