My congratulations to the development team; this is an important contribution to the community. You might want to use {-# OPTIONS_GHC #-} rather than {-# OPTIONS #-}, unless compatibility with older versions of GHC is a goal. Still, the pragma only turns on warnings, so it's harmless. Ashley Yakeley wrote:
One interesting line of development would be to spin off the core functionality into a separate library, to provide no-op services to other Haskell applications. I'm thinking something like this:
noop :: IO () -- generalise to other Monads?
Only IO makes sense really, since by definition every non-IO expression does nothing, so the only interesting way to do nothing is in the IO monad. I imagine this interface would be relatively stable. I'm not sure at this stage where in the module hierarchy we should place it, though. Cheers, Simon
Simon Marlow wrote:
My congratulations to the development team; this is an important contribution to the community.
Thanks!
You might want to use {-# OPTIONS_GHC #-} rather than {-# OPTIONS #-}, unless compatibility with older versions of GHC is a goal. Still, the pragma only turns on warnings, so it's harmless.
Applied, thanks. At some point I want to do equivalent things for other compilers. I generally like to be pretty strict about warnings, especially as one can selectively disable them if needed.
noop :: IO () -- generalise to other Monads?
Only IO makes sense really, since by definition every non-IO expression does nothing, so the only interesting way to do nothing is in the IO monad.
Agreed. The concept of "doing nothing" is best understood within the conceptual domain of "doing things" in the IO sense. I shall also be resisting any calls for an unsafe version (unsafeNoOp :: ()). I'm currently considering possible unit tests, since right now I rely solely on code inspection. One possibility would be to simply time the function to show that it didn't have time to do anything really long at least. But that's not very satisfactory, since that is strictly a performance test, not a functionality test. It's like any other Haskell function: I want to implement it as efficiently as possible, but I don't guarantee any particular performance. Ideally I would have tests like these: * Verify noop does nothing with the file system. * Verify noop does no networking activity. * Verify noop makes no use of stdin/stdout/stderr. * Verify noop does not modify any external IORefs. etc. Actually, I think the fourth one may be unnecessary, given that we don't have global mutable state. The third might not be too hard. It's not clear how to do the others, however. I should hate to discover that a bug in my implementation was accidentally causing it to behave as a secure distributed HTTP-addressable digital media semantic content management system. -- Ashley Yakeley Seattle WA
On Jun 30, 2006, at 2:52 PM, Ashley Yakeley wrote:
Simon Marlow wrote:
My congratulations to the development team; this is an important contribution to the community.
Thanks!
You might want to use {-# OPTIONS_GHC #-} rather than {-# OPTIONS #-}, unless compatibility with older versions of GHC is a goal. Still, the pragma only turns on warnings, so it's harmless.
Applied, thanks. At some point I want to do equivalent things for other compilers. I generally like to be pretty strict about warnings, especially as one can selectively disable them if needed.
noop :: IO () -- generalise to other Monads? Only IO makes sense really, since by definition every non-IO expression does nothing, so the only interesting way to do nothing is in the IO monad.
Agreed. The concept of "doing nothing" is best understood within the conceptual domain of "doing things" in the IO sense. I shall also be resisting any calls for an unsafe version (unsafeNoOp :: ()).
I'm currently considering possible unit tests, since right now I rely solely on code inspection. One possibility would be to simply time the function to show that it didn't have time to do anything really long at least. But that's not very satisfactory, since that is strictly a performance test, not a functionality test. It's like any other Haskell function: I want to implement it as efficiently as possible, but I don't guarantee any particular performance.
Ideally I would have tests like these:
* Verify noop does nothing with the file system.
* Verify noop does no networking activity.
* Verify noop makes no use of stdin/stdout/stderr.
* Verify noop does not modify any external IORefs.
etc.
Actually, I think the fourth one may be unnecessary, given that we don't have global mutable state. The third might not be too hard. It's not clear how to do the others, however. I should hate to discover that a bug in my implementation was accidentally causing it to behave as a secure distributed HTTP-addressable digital media semantic content management system.
You may also want to verify that nothing is actually returned. What if there is a bug that makes it return bottom instead of nothing? This would mean that it would work fine for simple uses like your example run, but could crash your program if it actually uses the nothing (for example if HNOP is converted to a library as suggested by others). I guess this is related to the issue of exception handling. What if the program is interrupted when it's halfway through doing nothing? Ideally we would like to guarantee that it does nothing atomically. /Björn
On Fri, 2006-06-30 at 21:20 -0700, Bjorn Bringert wrote: . . .
I guess this is related to the issue of exception handling. What if the program is interrupted when it's halfway through doing nothing? Ideally we would like to guarantee that it does nothing atomically.
This may be difficult to guarantee. Consider: 1. If it does nothing atomically then it does nothing atomically. 2. But if it does nothing atomically then it is false that it does nothing atomically. 3. Ergo it is false that it does nothing atomically, from (1) and (2) by Reductio ad Absurdum. -- Bill Wood
On Fri, Jun 30, 2006 at 02:52:54PM -0700, Ashley Yakeley wrote:
I'm currently considering possible unit tests, since right now I rely solely on code inspection. One possibility would be to simply time the function to show that it didn't have time to do anything really long at least. But that's not very satisfactory, since that is strictly a performance test, not a functionality test. It's like any other Haskell function: I want to implement it as efficiently as possible, but I don't guarantee any particular performance.
Ideally I would have tests like these:
* Verify noop does nothing with the file system.
* Verify noop does no networking activity.
* Verify noop makes no use of stdin/stdout/stderr.
* Verify noop does not modify any external IORefs.
etc.
I think the best approach for this kind of verification would be to break the IO monad up into classes, and then write a polymorphic function, as this would allow you to verify that your noop function behaves as expected, class Monad m => FileWriteMonad m where writeFile :: FilePath -> String -> m () ... class Monad m => FileReadMonad m where readFile :: FilePath -> m String openFileRead :: FilePath -> M Handle -- would be more general with AT ... class Monad m => NetworkMonad m where withSocketsDo :: m a -> m a ... class Monad m => RefMonad m where -- note, this could be more general with AT newIORef :: a -> m (IORef a) And then we could catch bugs in the noop function simply by looking at its type. e.g. when we saw noop :: FileReadMonad m => m () we'd have a strong suspicion that noop is actually trying to read from the filesystem, but if the type is just noop :: m () we'd have a high degree of confidence (assuming no unsafePerformIO is going on) that noop is bug-free. Unfortunately, even this isn't sufficient to show that noop will never return bottom... -- David Roundy
participants (5)
-
Ashley Yakeley -
Bill Wood -
Bjorn Bringert -
David Roundy -
Simon Marlow