[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
predicates
- To: "Meehan@YALE-RES" at YALE
- Subject: predicates
- From: Jonathan Rees <Rees at YALE>
- Date: Thu ,8 Jul 82 17:50:00 EDT
- Cc: T-Discussion at YALE
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
predicate.
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 ...) ...)
to
(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.