[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


There is a comment in the manual (p. 27) which expresses (rather poorly)
my dissatisfaction with the MEM/ASS/... series of things.  It is quite
true that an underlying LAMBDA is being hidden, and the whole thing is
misleading and inappropriately modularized.  I had planned to think
about these iterators more thoroughly later this summer; another hard
problem I've punted on.  No endorsement implied.

The basic operations of interest here go basically like this:

DEL - filter - give me a sequence, same as original, with objects (or
first object) answering true to predicate, removed.

MEM - tail - find me a tail of the sequence satisfying some predicate.

ASS/RASS - locate - find me a component of the sequence satisfying some

POS - position - give me the index of a component satisfying a predicate.

Problem is that the predicate wants to be a closure, but we don't want
to cons it.

Two kinds of things would make it easier to approach the problem
and explore possible solutions:

(a) Stack-allocated procedures.  I might have done something more
general earlier if I hadn't had to worry about closure consing.

(b) Related to this, and quite a bit harder, is automatically tranforming

	(FOO (LAMBDA (X) ... Y ...) ...)


	(FOO-PRIME Y (LAMBDA (X Y) ... Y ...) ...),

to avoid consing the closure (whether in the heap or the stack).  (The
problem is more general than than that even; spreading the components of
what ought to be an aggregate on the stack, rather than passing an
aggregate, is the same kind of situation.  (FOO (CONS X Y) ...) vs.
(FOO-PRIME X Y ...).)

You're not overreacting; I just should have made my dissatisfactions and
future plans more explicit in the manual.  I've tried to do this
elsewhere, with limited success.