I also wanted such a feature but eventually I just went with: __todo :: String -> a {-# WARNING __todo "TODO" #-} __todo msg = error $ "TODO: " ++ msg __fixme :: a -> a {-# WARNING __fixme "FIXME" #-} __fixme = id Cheers, Zilin On 18/05/15 12:47, Richard Eisenberg wrote:

-1

I like the idea of having GHC spit out warnings and such of this form, but this is so straightforward to do with Template Haskell:

$([] <$ reportWarning "Fix this function!")

You could do something similar in terms, spitting out `id` instead of an empty list of declarations. (You'd have to be careful where you do this, admittedly.)

If it's this easy to do in userland without affecting the compiler, let's do it that way. And, even better, with some library support, you could customize this behavior in all sorts of ways.

Richard

On May 17, 2015, at 4:10 PM, Roman Cheplyaka wrote:

...

On 17/05/15 19:42, Christopher Done wrote:

...

What's the feeling on having a FIXME pragma so that I can attach warnings to unfinished things?

|{-# FIXME foo "Reasons here." #-}|

I would use the WARNING pragma but that doesn't work within a module and only triggers on use. Compiler errors are the one thing I and everyone else pays attention to, it would be very handy to have more control over things GHC reports to the developer to aid development. +1. I actively use WARNING in such cases, and I'd prefer the warning to be reported at the definition site.

It'd also be great to allow this pragma anywhere in the code, but I realize it'd complicate the parser.

Roman

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

---

Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

Hi,

...

I also wanted such a feature but eventually I just went with:

__todo :: String -> a {-# WARNING __todo "TODO" #-} __todo msg = error $ "TODO: " ++ msg

__fixme :: a -> a {-# WARNING __fixme "FIXME" #-} __fixme = id

I found WARNING fell short because it doesn't work on module-local definitions, and only triggers on use.

Maybe I am missing things, but `__todo` should generate a warning at use site which _is_ the module definition of the thing using it. Cheers, Tobi(as Florek)

Yes, my __todo and __fixme are just trivial tricks that work slightly better than -- FIXME and -- TODO as comments. I think I did miss some message from your initial post: could you elaborate how/why {-# WARNING ... #-} does not work within a module? About use-site and definition-site problem, _todo function itself need not be warned., but the functions defined in terms of it are the one we care about. So in that sense, it's still warned at definition site (i.e., __todo becomes the trigger). Cheers, Zilin On Mon, May 18, 2015 at 7:58 PM, Christopher Done wrote:

I found WARNING fell short because it doesn't work on module-local definitions, and only triggers on use.

On 18 May 2015 at 08:25, Zilin Chen wrote:

...

I also wanted such a feature but eventually I just went with:

__todo :: String -> a {-# WARNING __todo "TODO" #-} __todo msg = error $ "TODO: " ++ msg

__fixme :: a -> a {-# WARNING __fixme "FIXME" #-} __fixme = id

Cheers, Zilin

On 18/05/15 12:47, Richard Eisenberg wrote:

-1

I like the idea of having GHC spit out warnings and such of this form, but this is so straightforward to do with Template Haskell:

$([] <$ reportWarning "Fix this function!")

You could do something similar in terms, spitting out `id` instead of an empty list of declarations. (You'd have to be careful where you do this, admittedly.)

If it's this easy to do in userland without affecting the compiler, let's do it that way. And, even better, with some library support, you could customize this behavior in all sorts of ways.

Richard

On May 17, 2015, at 4:10 PM, Roman Cheplyaka wrote:

On 17/05/15 19:42, Christopher Done wrote:

What's the feeling on having a FIXME pragma so that I can attach warnings to unfinished things?

|{-# FIXME foo "Reasons here." #-}|

I would use the WARNING pragma but that doesn't work within a module and only triggers on use. Compiler errors are the one thing I and everyone else pays attention to, it would be very handy to have more control over things GHC reports to the developer to aid development.

+1. I actively use WARNING in such cases, and I'd prefer the warning to be reported at the definition site.

It'd also be great to allow this pragma anywhere in the code, but I realize it'd complicate the parser.

Roman

_______________________________________________ Haskell-Cafe mailing listHaskell-Cafe@haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing listHaskell-Cafe@haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

Nice idea! I didn't know reportWarning existed. Very cool. On 18 May 2015 at 04:47, Richard Eisenberg wrote:

-1

I like the idea of having GHC spit out warnings and such of this form, but this is so straightforward to do with Template Haskell:

$([] <$ reportWarning "Fix this function!")

You could do something similar in terms, spitting out `id` instead of an empty list of declarations. (You'd have to be careful where you do this, admittedly.)

If it's this easy to do in userland without affecting the compiler, let's do it that way. And, even better, with some library support, you could customize this behavior in all sorts of ways.

Richard

On May 17, 2015, at 4:10 PM, Roman Cheplyaka wrote:

...

On 17/05/15 19:42, Christopher Done wrote:

...

What's the feeling on having a FIXME pragma so that I can attach warnings to unfinished things?

|{-# FIXME foo "Reasons here." #-}|

I would use the WARNING pragma but that doesn't work within a module and only triggers on use. Compiler errors are the one thing I and everyone else pays attention to, it would be very handy to have more control over things GHC reports to the developer to aid development.

+1. I actively use WARNING in such cases, and I'd prefer the warning to be reported at the definition site.

It'd also be great to allow this pragma anywhere in the code, but I realize it'd complicate the parser.

Roman

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe