Deforesting racket/list
countvajhula opened this issue · comments
@dzoep made a survey of racket/list and identified these APIs as candidates for deforestation (after the initial compiler release merging #74 ).
Consumers:
- cadr, caddr, cadddr, caddddr, cadddddr
- list-ref
- length
- reverse (like foldX)
- findf
- assoc
- assw
- assv
- assq
- assf
- empty? / null?
- pair? / cons?
- index-of
- index-where
- count
- argmin
- argmax
Producers:
- map
- ormap
- andmap
- append
- append*
- inclusive-range
Transformers:
- ormap
- andmap
- list-tail, drop
- remove
- remq
- remv
- remw
- remove*
- remq*
- remv*
- remw*
- member (tail can continue to be processed)
- memw
- memv
- memq
- memf
- cdr, cddr, cdddr, cddddr, cdddddr, rest
- list-update
- list-set
- indexes-of
- indexes-where
- take
- takef
- dropf
- add-between
- filter-map
- filter-not
- remf
- remf*
As part of this effort, we'd likely want to include the other interfaces mentioned in St-Amour's writeup:
unfoldr, zip and average.
Also as discussed in Qi meetings, it may make sense to prototype map1 (analogous to compose1) for possible addition to Racket, as part of this effort.
Another note from meetings: review the use of contracts (vs manually constructed exceptions or blame objects) in deforestation for any additional performance gains.
Another thing to follow up on: Should Qi provide a map utility that supports multiple (or zero) return values? E.g. (map (flow (when positive? (-< _ _))) (list 1 2 3 4 5).