Re: Lisp collections

From: Pascal Costanza (costanza_at_web.de)
Date: 09/21/04 

Date: Tue, 21 Sep 2004 17:57:46 +0200

Chris C apel wrote:

> It's OK for Lisp to be different. But being able to treat certain kind
> of collection as having a minimal, common set of properties makes it
> easy to write functions dealing with just those aspects of what a
> collection /is/. That way collections that don't fit entirely into the
> mold can still be used in some places. It's about separating the
> implementation of the collection from its representation, and letting
> the programmer have a simpler conceptual model of working with it.

Sure, in theory this sounds very nice. I can only see one or two
operations, though, that would benefit from such a generality and that
are currently missing in Common Lisp. The one is a generalized derefence
operation (combining aref, gethash, assoc, getf, and so on), and the
other one I don't remember anymore. ;)

It's trivial to implement these two operations as a generic function.
Just a few lines of code. That's all. The important point here is: Since
you don't need to squeeze such generic functions into a class hierarchy,
you don't have a real problem here. In Java and C#, when you don't have
a method in a class, you basically lose. Not so in Common Lisp (or, for
example, Smalltalk and Objective-C that also allow you to add methods
after the fact).

Note that AspectJ and the likes don't help because you cannot add
methods into the core API, only to your own classes. The same thing
probably also for partial types in C#.

So again, just add the few generic functions that you personally would
like to see in your code and you're done. (Another important lesson that
takes time to grasp is that there is no need to force your own
preferences on others!)

> LOOP may be nice, but the functionality it encapsulates should
> probably be much more orthogonal. Instead of LOOP having an iterator
> for various built-in types, there should be a generic iterator-concept
> (probably a superclass) that can be used by *anything*. There should
> be a collection concept that inherits that (that supports count, and
> copying, as well as iterators). There should be a list concept that
> inherits from the collection that supports indexing, adding, and
> removing.
>
> I'm sorry if I've repeated myself, but I just don't see how lisp
> offers this level of abstraction from the data structures of its
> collections.

Go ahead and try to implement such a collection API. Make sure that it
provides the same functionality that is already offered by Common Lisp's
data structures. I have tried to do that as a Gedankenexperiment in the
past and I have come to the conclusion that a) it's too hard because the
features don't really fit in a hierarchy and b) it's probably not worth
it because there is no real gain here. However, I don't know how to
communicate that experience, so either you have to live through that
same experience or someone else can explain this better than I can. (Of
course, maybe you do come up with a workable solution, and I would be
very happy about such a result.)

>>You seem to be a newcomer to Lisp. There's a transition time in which
>>you expect things to work like they did in other languages. Soon you
>>will expect things to work like they do in Lisp elsewhere. ;)
>
> But until then, I think I need some convincing. Lisp is a much better
> language than C# in general, but there are two are three things about
> the Framework library that I think CL could use. It's nice that CL
> will allow this to be done is a really useful and neat way, but I do
> think it needs to be done. I'm unhappy with Lisp collections. I just
> can't see myself ever seeing the power in the current system.
>
> I think that, while Lisp is a much higher-level language than most
> .NET languages, Lisp collections are lower-level than .NET
> collections. That's the core of my argument. All the primitives are
> there, but they need to be organized, fleshed out, and made more
> consistent.

In my Java past (until about 2.5 years ago) I have tried the JGL (which
I have been told is modeled after the C++ STL library), the Java
Collection API and the C# collection API. JGL was very good, the Java
Collection API ok (and the first example of Sun acting like Microsoft, -
they didn't just adopt the JGL without any good technical reasons), and
the C# collection API was just total ***. If you really take it
seriously to program against interface and not against concrete classes,
the C# design just didn't work because you always had to cast things
around just to get at that particular operation you just need. It may
work well with concrete classes, but then what's the point?

(Of course, this was a very early version of C# and maybe they have
improved the design in the meantime. Or I just didn't get it. I don't
really care anymore...)

Pascal 

-- 
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."