Deforesting racket/list

[countvajhula]

@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*

[countvajhula]

As part of this effort, we'd likely want to include the other interfaces mentioned in St-Amour's writeup:
unfoldr, zip and average.

[countvajhula]

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.

[countvajhula]

Another note from meetings: review the use of contracts (vs manually constructed exceptions or blame objects) in deforestation for any additional performance gains.

[countvajhula]

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).