"Simon Peyton-Jones"
| The one that causes me the most hoop jumping is the type parameters to | some of the TH datastructures. For example, I have some code like this:
It's all to do with Tim's "two-level types" scheme, but I do agree with you that it seems more trouble than its worth.
Tim: how vigorously do you want to defend this? If not, can we let Ian remove the parameterisation?
I'd be in favour of removing it, too. Moreover, I would like to propose the following: * Use a naming scheme for the functions that avoids having to suffix some with "E" or "D" and some not. Example: we have "cond", but "letE". Better *uniformly* use a single suffix for all functions of the same class; eg, "condExp" and "letExp" (or "condE" and "letE" if you desperately want to save letters). * Get rid of the intriguing (but IMHO impractical) idea of using mnemonics of a particular length for variants data types. Example: we have "Mat" and "Mtch" as well as "Rhs" and "Rihs", where the four letter variant is in the Q monad. The distinction between "Mat" and "Match" etc will vanish once we get rid of the two-level type scheme. Then we can just have "Match" and "MatchQ" together with "Rhs" and "RhsQ" and so on. The rational for the change is that such sophisticated naming schemes may be easy to remember for the inventor, but other people just always have to look the names up in the definition. Cheers, Manuel