> A warning flag is an interesting way to deal with the issue. On the > other hand, it's not great from an ergonomic perspective; afterall, this > would mean that all users of HLint (and any other tool requiring special
Yep, this means every HLint user has to do an extra thing. I (the HLint author) now have a whole pile of "how do I disable warnings in Stack", and "what's the equivalent of this in Nix". Personally, it ups the support level significantly that I wouldn't go this route. I think it might be a useful feature in general, as new tools could use the flag to prototype new types of warning, but I imagine once a feature gets popular it becomes too much fuss. > > I think it makes a lot of sense to have a standard way for third-parties > > to attach string-y information to Haskell source constructs. While it's > > not strictly speaking necessary to standardize the syntax, doing > > so minimizes the chance that tools overlap and hopefully reduces > > the language ecosystem learning curve. > > This sounds exactly like the existing ANN pragma, which is what I've wanted > LiquidHaskell to move towards for a long time. What is wrong with using the > ANN pragma? Significant compilation performance penalty and extra recompilation. ANN pragmas is what HLint currently uses. > I'm a bit skeptical of this idea. Afterall, adding cases to the > lexer for every tool that wants a pragma seems quite unsustainable. I don't find this argument that convincing. Given the list already includes CATCH and DERIVE, the bar can't have been _that_ high to entry. And yet, the list remains pretty short. My guess is the demand is pretty low - we're just whitelisting a handful of additional words that aren't misspellings. Thanks, Neil _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
