HNOP: Haskell No Operation A first version of HNOP 0.1 is now available under a simple permissive license. This version should be considered "beta" quality, though I don't know of any bugs. http://semantic.org/hnop.tar.gz HNOP does nothing. Here's a sample session to illustrate: $ ./hnop $ The code is written entirely in plain Haskell 98 and makes no use of FFI or impure functions. The source is available in a darcs repository: darcs get http://semantic.org/hnop/ Possible applications include generated code size comparison for compilers, and as a starting point for more complex Haskell projects. -- Ashley Yakeley Seattle, WA
From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Ashley Yakeley
HNOP does nothing. Here's a sample session to illustrate:
$ ./hnop $
The code is written entirely in plain Haskell 98 and makes no use of FFI or impure functions. The source is available in a darcs repository:
darcs get http://semantic.org/hnop/
Possible applications include generated code size comparison for compilers, and as a starting point for more complex Haskell projects.
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? 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. *****************************************************************
Alistair_Bayley:
From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Ashley Yakeley
HNOP does nothing. Here's a sample session to illustrate:
$ ./hnop $
The code is written entirely in plain Haskell 98 and makes no use of FFI or impure functions. The source is available in a darcs repository:
darcs get http://semantic.org/hnop/
Possible applications include generated code size comparison for compilers, and as a starting point for more complex Haskell projects.
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. :) -- Don
In article <20060630073852.GA32118@cse.unsw.EDU.AU>, dons@cse.unsw.edu.au (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
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. I think the program could also benefit from a configure script and autotools. But it's a great start. Mike Bayley, Alistair wrote:
From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Ashley Yakeley
HNOP does nothing. Here's a sample session to illustrate:
$ ./hnop $
The code is written entirely in plain Haskell 98 and makes no use of FFI or impure functions. The source is available in a darcs repository:
darcs get http://semantic.org/hnop/
Possible applications include generated code size comparison for compilers, and as a starting point for more complex Haskell projects.
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?
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 mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
mvanier:
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.
Hmm. Sounds like you're using ghc on a machine with no split objects? With split objs, $ du -hs dist/build/hnop/hnop 192K dist/build/hnop/hnop Note the object is just: $ du -hs dist/build/hnop/hnop-tmp/Main.o 4.0K dist/build/hnop/hnop-tmp/Main.o The rest is rts and the tiny bit of the prelude hnop uses. On the mac, you can use a dynamically linked rts and base, and there hnop would be around 5k, I suppose. -- Don
<dumb question> Split objects? What's that? </dumb question> I'm running this on Linux (Debian unstable). Mike Donald Bruce Stewart wrote:
mvanier:
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.
Hmm. Sounds like you're using ghc on a machine with no split objects? With split objs, $ du -hs dist/build/hnop/hnop 192K dist/build/hnop/hnop
Note the object is just: $ du -hs dist/build/hnop/hnop-tmp/Main.o 4.0K dist/build/hnop/hnop-tmp/Main.o
The rest is rts and the tiny bit of the prelude hnop uses.
On the mac, you can use a dynamically linked rts and base, and there hnop would be around 5k, I suppose.
-- Don
In article <44A4D5FD.9050604@cs.caltech.edu>, mvanier <mvanier@cs.caltech.edu> 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
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⑈
In article <252C89C12FCAD84BA018CAD5268682FD0190C955@GBLONXMB02.corp.amvescap.net>, "Bayley, Alistair" <Alistair_Bayley@invescoperpetual.co.uk> 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
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 <ashley@semantic.org> wrote:
In article <252C89C12FCAD84BA018CAD5268682FD0190C955@GBLONXMB02.corp.amvescap.net>, "Bayley, Alistair" <Alistair_Bayley@invescoperpetual.co.uk> 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
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 <christophe.poucet@gmail.com> 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 <ashley@semantic.org> wrote:
In article <252C89C12FCAD84BA018CAD5268682FD0190C955@GBLONXMB02.corp.amvescap.net>, "Bayley, Alistair" < Alistair_Bayley@invescoperpetual.co.uk> 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
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 <garious@gmail.com>:
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 <christophe.poucet@gmail.com> 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 < ashley@semantic.org> wrote:
In article
<252C89C12FCAD84BA018CAD5268682FD0190C955@GBLONXMB02.corp.amvescap.net
,
"Bayley, Alistair" < Alistair_Bayley@invescoperpetual.co.uk> 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
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 <kr.angelov@gmail.com> 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
On Jun 30, 2006, at 1:01 AM, Ashley Yakeley wrote:
In article <252C89C12FCAD84BA018CAD5268682FD0190C955@GBLONXMB02.corp.amvescap.net
, "Bayley, Alistair" <Alistair_Bayley@invescoperpetual.co.uk> 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
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
On 30/06/06, Ashley Yakeley <ashley@semantic.org> wrote:
HNOP: Haskell No Operation
Could you perhaps write a Haskell Weekly News entry for this? It might also be worth contacting Andres Löh and seeing if we can get a late entry into the Haskell Communities and Activities Report, this seems critical enough. I also think it could perhaps run faster by using ByteStrings. -- -David House, dmhouse@gmail.com
Could you perhaps write a Haskell Weekly News entry for this? It might also be worth contacting Andres Löh and seeing if we can get a late entry into the Haskell Communities and Activities Report, this seems critical enough.
I agree that it is pretty critical, but I'll rather do a HNOP this time, and instead give it a prominent position in the November edition (if I receive a project report). Cheers, Andres
participants (12)
-
Andres Loeh -
Ashley Yakeley -
Bayley, Alistair -
Bjorn Bringert -
Christophe Poucet -
David House -
dons＠cse.unsw.edu.au -
Greg Fitzgerald -
John Meacham -
Krasimir Angelov -
mvanier -
Niklas Broberg