Petr Rockai <[email protected]> writes: > this is an alternative "hlint" patch, that actually replaces > haskell_policy. It only catches and reports actual errors, so there's > no issue with huge output. It also provides a ratification mechanism, > so it is possible to make the test pass (we need to use the unsafe > functions from time to time).
I note that the ratification technique Petr employs can only be used to ratify module hiding-type errors. For example, if we wanted hlint to complain about only *new* code that didn't use camelCase, we wouldn't be able to use it to ratify existing not_camel_case functions. For that reason I'm a little unhappy about that particular technique, but as 1) I don't have a better suggestion; and 2) it gives the same functionality that we had in the old haskell_policy, I'll give my approval of it. I suggest filing a wishlist bug against hlint for some sort of generalized ratification mechanism, since it seems like something that'd be useful for ALL hlint users, not just Darcs. > Nevertheless, even though the test passes now, it should probably wait > till the hlint cpp issue [1] is fixed. > > [1]: http://code.google.com/p/ndmitchell/issues/detail?id=137 I had forgotten about this one. Do you know offhand how many files in the Darcs tree will bork current hlint in this way? Ah, you say in the ticket: >> about 30 or so files fail to parse due to CPP. Or, about one in five source files (19%). _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
