By: Tom Sydney Kerckhove <syd@cs-syd.eu>
Report an error type that is prose with a name on it A signature reported for its String is answered by naming the String: write type ParseError = Text, or wrap it in a newtype, and the rule that asked for a type of its own is satisfied by a type that is still one undifferentiated message. Both are now reported, read off the declaration's name, which is the one thing that says a type is meant as a failure. A wrapper counts only when its constructor is the type's name over again, with or without Mk. That is the shape a reader learns nothing from, and its renderer is id: renderNarInfoParseError (NarInfoParseError s) = s. A constructor that names the failure is a different thing even when it is the only one. UnknownRepoType !Text holds the input nobody understood rather than words about it, and what a reader is told comes from the renderer that matches on the name. The narrowing is the whole of the difference between a rule worth having and one worth turning off. Over nix-ci8, smos, salsa, kronor, sydtest, validity and graphql-engine, reporting every one-constructor wrapper found seventeen, and fourteen of them were that second shape, written deliberately. Reporting only the echo finds three, and all three have a renderer that hands back what it was given. good.hs holds the shape that is left alone. A data declaration with two constructors is the fix, so it is never reported.