Re: ANNOUNCE: HNOP 0.1

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: HNOP 0.1

Simon Marlow-5
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
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: HNOP 0.1

Ashley Yakeley
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

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: ANNOUNCE: HNOP 0.1

Ashley Yakeley
In reply to this post by Simon Marlow-5
> Now we just need the Godot version, in which nothing happens twice.

You may have to wait for that.

--
Ashley Yakeley
Seattle WA

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: ANNOUNCE: HNOP 0.1

Bjorn Bringert-2
In reply to this post by Ashley Yakeley
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
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: ANNOUNCE: HNOP 0.1

Bjorn Bringert-2
In reply to this post by Ashley Yakeley
On Jun 30, 2006, at 2:58 PM, Ashley Yakeley wrote:

>> Now we just need the Godot version, in which nothing happens twice.
>
> You may have to wait for that.

Now, thanks to the polyvariadic nop, the wait is over:

import Control.Nop

main :: IO ()
main = nop "Yes, let's do something."
               (nop "Well, shall we do something?" :: IO ())

/Björn_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: ANNOUNCE: HNOP 0.1

David Roundy-2
In reply to this post by Ashley Yakeley
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
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: ANNOUNCE: HNOP 0.1

Bill Wood-3
In reply to this post by Bjorn Bringert-2
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


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe