This is solely because GHC 6.6 doesn't like them (it complains about the type
variable already being in scope -- which it is, but there's nothing I can do
about that!). This doesn't lose any safety; if you try to write a
transformation for something that's not Data you'll find out when you try to
pass it to one of the application functions.
We now have three kinds of canned tree traversals, all of which are smart about
which types they're applied to: explicit-descent transformations,
implicit-descent transformations, and implicit-descent checks. I've only
provided depth-first application of the latter two, but we could do
breadth-first in the future if necessary.
This provides gmapMFor and gmapMFor2, which are like gmapM, but know what
they're looking for, and can therefore avoid going down branches of the tree
that won't contain any interesting types.
The basic approach is quite similar to Uniplate's PlateData: there's a function
(containsType) that'll tell you whether one type is contained somewhere within
another. However, unlike Uniplate, we build a static IntMap IntSet of the types
we need to know about, which allows rather quicker lookups. (I did try using
PlateData first.)
The result is that applyDepthM is now much quicker than it was before.
applyDepthM2 is a bit less impressive, which I assume is because it can't
really prune the tree much if it's looking for two types.
Future enhancements:
- convert more passes to use applyDepthM*;
- make gmapMFor* aware of constructors rather than just types, which should
allow a bit more pruning.
This is so that constant folding gets done early; it's important that it
doesn't happen after anything that tries to pull values into variables later
on.
Now that I have begun moving all the _sizes stuff forward into proper compiler passes, much of the code for handling arrays in the backends is going to become redundant:
- The tockArrayView class should eventually disappear; now that _sizes are pulled forward, there's no advantage of having this extra class (compared to just doing C and C++ arrays in the same, C-based, style)
- The declaration and use of the _sizes array everywhere should go, now that it is inserted in an earlier pass
I haven't removed as much as I should from the C backend; I am wary to touch it when Adam is about to move it over to the new CIF anyway
