[comp.object] Heterogeneous lists

adam@visix.com (04/15/91)

In article <1989:Apr1206:29:5291@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:

|> ... My point in the heterogenous-list discussion was that
|> people only use heterogeneous lists as (a) union types; (b) objects, to
|> which a FIXED set of operations will be applied.

This (b) part has been bothering me for a while.

How exactly would you write a MAPCAR or ACCUMULATE function?
I see these functions as capturing fundamental abstractions,
and I see uses for them everywhere.

Now, at one level of abstraction, you could say that there is indeed
a fixed operation being applied here, namely the operation
"do the operations identified by parameter X".
(This is analogous to the statement that Smalltalk has no
heterogeneous lists because everything in Smalltalk is an Object.)

But I think that for the user of MAPCAR, and perhaps even the
implementor, it is easier to say there is no fixed set of operations,
since the actual functions called are tightly coupled to "parameter X".
The actual functions called may not be defined (or even imagined!)
at compile time, so I think it unnatural to claim they are "fixed".

Abstractly, every list is heterogeneous (the items must differ somehow,
else why have more than one?) and every list is homogeneous (the items
must have something in common, else why group them together?).

The MAPCAR example is from the more heterogeneous side, in that
the only thing the objects necessarily have in common is
"they all have the operation identified by parameter X, which
takes as argument the object itself and returns another object"
(not even that if you want MAPCAR to catch failures!)

You could, of course, build a solution in C around that fact,
creating a list of anonymous monadic functions for each application
of MAPCAR.

|> ---Dan

Adam

lgm@cbnewsc.ATT.COM (lawrence.g.mayka) (04/17/91)

In article <1991Apr14.211215.1818@visix.com> adam@visix.com writes:
   The MAPCAR example is from the more heterogeneous side, in that
   the only thing the objects necessarily have in common is
   "they all have the operation identified by parameter X, which
   takes as argument the object itself and returns another object"
   (not even that if you want MAPCAR to catch failures!)

   You could, of course, build a solution in C around that fact,
   creating a list of anonymous monadic functions for each application
   of MAPCAR.

Actually, Common Lisp MAPCAR is more flexible than this.  It takes one
*or more* lists as arguments, and applies the given operation to
corresponding elements of those lists.  Moreover, the operation itself
does not necessarily take a fixed number of arguments, either.  Thus:

(MAPCAR #'LIST '(A B)) => ((A) (B))

(MAPCAR #'LIST '(A B) '(C D)) => ((A C) (B D))

(MAPCAR #'LIST '(A B) '(C D) '(E F)) => ((A C E) (B D F))

MAPCAR is indeed a reusable abstraction.


	Lawrence G. Mayka
	AT&T Bell Laboratories
	lgm@iexist.att.com

Standard disclaimer.