[Haskell] Re: ANNOUNCE: HNOP 0.1
On Jun 30, 2006, at 1:01 AM, Ashley Yakeley wrote: In article [EMAIL PROTECTED] , Bayley, Alistair [EMAIL PROTECTED] wrote: Cool, that's awesome. But I don't see any Haddock docs? Or a Cabal Setup.hs? Would it be much trouble to add them? Bear in mind HNOP compiles just to an executable file, so it doesn't really have a Haskell API. 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? This would actually not be too hard to write, given my existing work, and then of course the executable would simply be a thin wrapper. As suggested above, this patch moves the core functionality to a library module, Control.Nop. Furthermore, the nop function is generalized to a polyvariadic function, so that you can now write for example: import Control.Nop main :: IO () main = nop Hello World! and still get the expected lack of results. /Björn control-nop.patch Description: Binary data ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: ANNOUNCE: HNOP 0.1
bringert:
noop :: IO () -- generalise to other Monads?
This would actually not be too hard to write, given my existing work,
and then of course the executable would simply be a thin wrapper.
As suggested above, this patch moves the core functionality to a
library module, Control.Nop. Furthermore, the nop function is
generalized to a polyvariadic function, so that you can now write for
example:
Ah, great. Now we can write a fast nop using ByteStrings for speed.
import Data.ByteString.Char8
import Control.Nop
-- | main, do nothing quickly
main :: IO ()
main = nop (pack do nothing)
Demo patch for fast-hnop attached.
-- Don
New patches:
[Moved the definition of the nop function to a library module, Control.Nop.
Reimplemented Main.hs using Control.Nop. Generalized the nop function to a
polyvariadic function.
[EMAIL PROTECTED] {
adddir ./Control
addfile ./Control/Nop.hs
hunk ./Control/Nop.hs 1
+-
+-- |
+-- Module : Control.Nop
+-- Copyright : Copyright 2006, Bjorn Bringert ([EMAIL PROTECTED])
+-- License : BSD3
+--
+-- Maintainer : Bjorn Bringert [EMAIL PROTECTED]
+-- Stability : experimental
+-- Portability : portable
+--
+-- This is a generalization of Ashley Yakeley's original HNOP
+-- program to a polyvariadic function, which still does nothing.
+-- The result is either an IO action which does nothing,
+-- or pure nothingness.
+--
+-
+module Control.Nop where
+
+-- | The class of functions which do nothing.
+class Nop a where
+-- | Do nothing.
+-- The most useful familiy of 'nop' functions is probably:
+-- @nop :: a1 - ... - an - IO ()@
+nop :: a
+
+instance Nop () where
+nop = ()
+
+instance Nop a = Nop (IO a) where
+nop = return nop
+
+instance Nop b = Nop (a - b) where
+nop _ = nop
+
hunk ./Main.hs 4
+import Control.Nop
+
hunk ./Main.hs 8
-main = return ()
+main = nop
hunk ./hnop.cabal 6
+Exposed-modules: Control.Nop
}
[Add demo fast-hnop, using Data.ByteString for speed
Don Stewart [EMAIL PROTECTED]**20060701083508] {
addfile ./Fast.hs
hunk ./Fast.hs 1
+module Main where
+
+import Data.ByteString.Char8
+import Control.Nop
+
+-- | main, do nothing quickly
+main :: IO ()
+main = nop (pack do nothing)
hunk ./hnop.cabal 5
-build-depends: base
+build-depends: base, fps
hunk ./hnop.cabal 11
+Executable: fast-hnop
+Main-Is: Fast.hs
+
}
Context:
[remove unnecessary Makefile
Ashley Yakeley [EMAIL PROTECTED]**20060630191533]
[use correct GHC options pragma
Ashley Yakeley [EMAIL PROTECTED]**20060630191505]
[fix up cabal file
Ashley Yakeley [EMAIL PROTECTED]**20060630075323]
[haddock-ise hnop
[EMAIL PROTECTED]
[cabalise hnop
[EMAIL PROTECTED]
[initial version
Ashley Yakeley [EMAIL PROTECTED]**20060630034031]
Patch bundle hash:
8ba09d4b5f29d8136032effcf004a4a47cf274c1
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: ANNOUNCE: HNOP 0.1
Now we just need the Godot version, in which nothing happens twice. Oops. That should have been ... in which nothing happens, twice. Alternatively I just need a type checker for my English. Paul. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: ANNOUNCE: HNOP 0.1
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. Actually this would be useful, and probably belongs in Control.Monad (although I'd call it noOp rather than noop). I was recently working on code that took monadic actions as parameters, so that under the right circumstances the appropriate action would be executed. On several occasions I had to pass return () as a null action. Having an explicit noOp :: Monad m = m () would have made the code shorter and clearer. Paul. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: ANNOUNCE: HNOP 0.1
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Donald Bruce Stewart) wrote: Cool, that's awesome. But I don't see any Haddock docs? Or a Cabal Setup.hs? Would it be much trouble to add them? Done. See attached patch. :) Applied, thanks. -- Ashley Yakeley Seattle WA ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: ANNOUNCE: HNOP 0.1
In article [EMAIL PROTECTED], Bayley, Alistair [EMAIL PROTECTED] wrote: Cool, that's awesome. But I don't see any Haddock docs? Or a Cabal Setup.hs? Would it be much trouble to add them? Bear in mind HNOP compiles just to an executable file, so it doesn't really have a Haskell API. 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? This would actually not be too hard to write, given my existing work, and then of course the executable would simply be a thin wrapper. -- Ashley Yakeley Seattle WA ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: ANNOUNCE: HNOP 0.1
In article [EMAIL PROTECTED], mvanier [EMAIL PROTECTED] wrote: Incidentally, on my machine the compiled code is 2759360 bytes long unstripped and 1491240 stripped. One has to wonder what all those bytes are doing. I hope this doesn't sound petty; I love haskell and ghc, but 2.8 meg for a no-op program seems a bit excessive. What platform are you running? On my Mac hnop compiles to 293848 bytes (221980 stripped), while on Linux it compiles to 241376 (164320 stripped). It would be interesting to compile it with John Meacham's Jhc, which claims to leave very little overhead in its executables. I know the current Jhc has a limit on total program size, but the current HNOP at least may slip under the wire (and I don't make any use of arrays, so it shouldn't be too slow). I think the program could also benefit from a configure script and autotools. But it's a great start. Thanks! -- Ashley Yakeley Seattle WA ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: ANNOUNCE: HNOP 0.1
I do think that refactoring this to a library would be a much better idea. That way we can see how this scales to multithreaded applications. Will there be a HNOP 2.0 that takes advantage of such fancy features such as MPTC or FD? It would be interesting to see how this problem reduces when one uses these advanced Haskell features. Perhaps as showcase to show that MPTC and FD definitely improve code-readability and design-abstraction/ Cheers,Christophe (vincenz)On 6/30/06, Ashley Yakeley [EMAIL PROTECTED] wrote: In article[EMAIL PROTECTED], Bayley, Alistair [EMAIL PROTECTED] wrote: Cool, that's awesome. But I don't see any Haddock docs? Or a Cabal Setup.hs? Would it be much trouble to add them? Bear in mind HNOP compiles just to an executable file, so it doesn'treally have a Haskell API.One interesting line of development would be to spin off the corefunctionality 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?This would actually not be too hard to write, given my existing work,and then of course the executable would simply be a thin wrapper. --Ashley YakeleySeattle WA___Haskell mailing listHaskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: ANNOUNCE: HNOP 0.1
I once worked for a company at which HNOP could be used as a drop-in replacement for half the programmers.-GregOn 6/30/06, Christophe Poucet [EMAIL PROTECTED] wrote: I do think that refactoring this to a library would be a much better idea. That way we can see how this scales to multithreaded applications. Will there be a HNOP 2.0 that takes advantage of such fancy features such as MPTC or FD? It would be interesting to see how this problem reduces when one uses these advanced Haskell features. Perhaps as showcase to show that MPTC and FD definitely improve code-readability and design-abstraction/ Cheers,Christophe (vincenz)On 6/30/06, Ashley Yakeley [EMAIL PROTECTED] wrote: In article[EMAIL PROTECTED] , Bayley, Alistair [EMAIL PROTECTED] wrote: Cool, that's awesome. But I don't see any Haddock docs? Or a Cabal Setup.hs? Would it be much trouble to add them? Bear in mind HNOP compiles just to an executable file, so it doesn'treally have a Haskell API.One interesting line of development would be to spin off the corefunctionality 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?This would actually not be too hard to write, given my existing work,and then of course the executable would simply be a thin wrapper. --Ashley YakeleySeattle WA___Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___Haskell mailing listHaskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: ANNOUNCE: HNOP 0.1
There was lots of suggestions for the future development of HNOP. Is it too late to propose Google SoC project for it? At least it will be a good candidate for the next summer. Cheers, Krasimir 2006/6/30, Greg Fitzgerald [EMAIL PROTECTED]: I once worked for a company at which HNOP could be used as a drop-in replacement for half the programmers. -Greg On 6/30/06, Christophe Poucet [EMAIL PROTECTED] wrote: I do think that refactoring this to a library would be a much better idea. That way we can see how this scales to multithreaded applications. Will there be a HNOP 2.0 that takes advantage of such fancy features such as MPTC or FD? It would be interesting to see how this problem reduces when one uses these advanced Haskell features. Perhaps as showcase to show that MPTC and FD definitely improve code-readability and design-abstraction/ Cheers, Christophe (vincenz) On 6/30/06, Ashley Yakeley [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED] , Bayley, Alistair [EMAIL PROTECTED] wrote: Cool, that's awesome. But I don't see any Haddock docs? Or a Cabal Setup.hs? Would it be much trouble to add them? Bear in mind HNOP compiles just to an executable file, so it doesn't really have a Haskell API. 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? This would actually not be too hard to write, given my existing work, and then of course the executable would simply be a thin wrapper. -- Ashley Yakeley Seattle WA ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: ANNOUNCE: HNOP 0.1
Well, we did have a serious SoC suggestion about the industrial Hello World application, by Isaac Jones. I guess the industrial noop would be just as good. /Niklas On 6/30/06, Krasimir Angelov [EMAIL PROTECTED] wrote: There was lots of suggestions for the future development of HNOP. Is it too late to propose Google SoC project for it? At least it will be a good candidate for the next summer. Cheers, Krasimir ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: ANNOUNCE: HNOP 0.1
Now we just need the Godot version, in which nothing happens twice. Or are Godots considered harmful? Paul. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: ANNOUNCE: HNOP 0.1
On Fri, Jun 30, 2006 at 01:12:39AM -0700, Ashley Yakeley wrote: It would be interesting to compile it with John Meacham's Jhc, which claims to leave very little overhead in its executables. I know the current Jhc has a limit on total program size, but the current HNOP at least may slip under the wire (and I don't make any use of arrays, so it shouldn't be too slow). ; jhc -v Main.hs ; strip hs.out ; ls -al hs.out -rwxr-xr-x 1 john john 6008 Jun 30 14:37 hs.out 6k or so. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] Re: [Haskell] Re: ANNOUNCE: HNOP 0.1
[moved to cafe] On Jun 30, 2006, at 4:01 AM, Ashley Yakeley wrote: In article [EMAIL PROTECTED] , Bayley, Alistair [EMAIL PROTECTED] wrote: Cool, that's awesome. But I don't see any Haddock docs? Or a Cabal Setup.hs? Would it be much trouble to add them? Bear in mind HNOP compiles just to an executable file, so it doesn't really have a Haskell API. 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 sorry; I know this is a serious discussion (either that or everyone involved in this discussion has a more subtle sense of humor than I), but this sentence made me laugh out loud... :-) no-op services? That's just great! I'm thinking something like this: noop :: IO () -- generalise to other Monads? This would actually not be too hard to write, given my existing work, and then of course the executable would simply be a thin wrapper. -- Ashley Yakeley Seattle WA Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: [Haskell] Re: ANNOUNCE: HNOP 0.1
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Dockins [moved to cafe] On Jun 30, 2006, at 4:01 AM, Ashley Yakeley wrote: In article [EMAIL PROTECTED] scap.net , Bayley, Alistair [EMAIL PROTECTED] wrote: Cool, that's awesome. But I don't see any Haddock docs? Or a Cabal Setup.hs? Would it be much trouble to add them? Bear in mind HNOP compiles just to an executable file, so it doesn't really have a Haskell API. 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 sorry; I know this is a serious discussion (either that or everyone involved in this discussion has a more subtle sense of humor than I), but this sentence made me laugh out loud... :-) no-op services? That's just great! Initially I assumed it was just a joke, and my response was meant to be tongue-in-cheek (why would you need Haddock docs for this!?), but there has been a semi-serious thread about the executable size, so who knows anymore... Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
