From oleg at pobox.com Tue May 1 00:12:07 2007 From: oleg at pobox.com (oleg@pobox.com) Date: Tue May 1 00:10:59 2007 Subject: [Haskell-cafe] Type-level programming problem Message-ID: <20070501041207.CCECEAD3E@Adric.metnet.fnmoc.navy.mil> Thomas Schilling wrote: > data T > class Foo ns a b c | ns -> a, ns -> b, ns -> c where > mkFoo :: ns > defaultA :: a > defaultB :: c -> IO b > defaultC :: [T] -> c > f :: c -> b -> a -> (b, Int) > data DefaultA > instance Foo ns a b c => Apply DefaultA ns a where > apply _ _ = defaultA > > but I get: > > Could not deduce (Foo ns1 a b1 c1) > from the context (Apply MakeAs ns a, Foo ns a b c) > arising from use of `defaultA' Indeed. Let us examine the inferred type of defaultA: *Main> :t defaultA defaultA :: (Foo ns a b c) => a We see it is a value polymorphic over four type variables: ns, a, b, and c. The type variable 'a' is also the type of the value, so we have a way to instantiate it. There is no direct way to instantiate the remaining three. If there were a functional dependency a -> ns, a->b, a->c, we could have instantiated the remaining variables. But there are no such dependencies. So, there is really no way we can ever instantiate the type variables ns, b and c -- and so the typechecker will complain. So, we need either a functional dependency a -> ns in the definition of Foo, or defaultA should have a signature defaultA :: ns -> a (and ditto for other defaults). As I understand, the function 'defaultA' can be present in different components, identified by ns. When we write 'defaultA' however, how can we say that we mean defaultA of component X rather than of component Y? There isn't any way to name the desired component... Incidentally, if we represent components by records data XRec = XRec { defaultA :: XA } then the type of defaultA is Xref -> XA. It is the function from the type of the `namespace'. This seems to suggest the signature of defaultA should be ns -> a ... BTW, there are other ways to add the name of the namespace to the signature of defaultA. For example: newtype TaggedT ns a = TaggedT a class Foo ns a b c | ... defaultA :: TaggedT ns a or class Foo ns a b c | ... defaultA :: ns a etc. From magnus at therning.org Tue May 1 04:34:04 2007 From: magnus at therning.org (Magnus Therning) Date: Tue May 1 04:31:31 2007 Subject: [Haskell-cafe] Cabal, lib and exe in one Message-ID: <20070501083404.GD3718@die.therning.org> I'm trying to create a single cabal file containing specs for both a library and an executable using that library. I'm not having much luck though :( This is what I have so far: name: foo version: 0.1 exposed-modules: Foo.Bar other-modules: Foo.Qux Foo.C2HS hs-source-dirs: src include-dirs: csrc c-sources: csrc/qux.c extensions: ForeignFunctionInterface build-depends: base, haskell98 executable: foo hs-source-dirs: test-src main-is: foo.hs other-modules: Foo.Bar When built this is the message I get: test-src/foo.hs:5:7: Could not find module `Foo.Bar': Use -v to see a list of the files searched for. How do I specify that Foo.Bar is found where cabal puts it (./dist/build/)? /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus@therning.org Jabber: magnus.therning@gmail.com http://therning.org/magnus Software is not manufactured, it is something you write and publish. Keep Europe free from software patents, we do not want censorship by patent law on written works. Finagle's Fifth Law: Always draw your curves, then plot your readings. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20070501/ee2a831c/attachment.bin From Alistair_Bayley at invescoperpetual.co.uk Tue May 1 05:09:45 2007 From: Alistair_Bayley at invescoperpetual.co.uk (Bayley, Alistair) Date: Tue May 1 05:07:07 2007 Subject: [Haskell-cafe] FIT for Haskell In-Reply-To: <463625AF.1050506@gmail.com> Message-ID: <125EACD0CAE4D24ABDB4D148C4593DA901BDFA10@GBLONXMB02.corp.amvescap.net> > From: haskell-cafe-bounces@haskell.org > [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Philipp Volgger > > Who wrote FIT for Haskell on http://darcs.haskell.org/FIT/? > Does anybody know if the version is stable? Hello Philipp, That would be me. It's not finished or stable, and I don't think it'll work with GHC-6.6 on Windows because it uses hs-plugins. I figured I'd better save the code somewhere, because I lost some work when my laptop died last year. It's not finished in the sense that I haven't implemented all of the test suite; I got as far as the Music Example in the standard tests (http://fit.c2.com/wiki.cgi?MusicExample) but I have not implemented RowFixture, which the Music Example requires. Also, the Algol-derivative-language implementations of FIT (Java, C#, etc) use static class variables (i.e. global mutable state) in the Music Example, so there's some redesign work to get it to run in Haskell. I'd be happy to explain how it works if you're interested in contributing. 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. ***************************************************************** From polyomino at f2s.com Tue May 1 05:20:26 2007 From: polyomino at f2s.com (DavidA) Date: Tue May 1 05:18:05 2007 Subject: [Haskell-cafe] Re: 'Proper' use of the State monad References: <608932c00704301416i39543a2bg2dd677004dd06ffe@mail.gmail.com> Message-ID: > 1) Using State GameState r and then call execState for each game event > (i.e. user input) so I can do IO > 2) Using StateT GameState IO () and have the entire game live in one > big execStateT call. (I note XMonad does something similar.) I'm also interested in the answer to this question. One concern I would have about option 2 is that it looks like it "breaks encapsulation", to use a phrase from OOP. What I mean is, it seems like good design would mean that you could write and test the game logic totally independently of any IO. Game functions such as "makeMove" ought to have type signatures that don't involve any IO. Can this be achieved in option 2? From tphyahoo at gmail.com Tue May 1 05:42:37 2007 From: tphyahoo at gmail.com (Thomas Hartman) Date: Tue May 1 05:39:59 2007 Subject: [Haskell-cafe] what exactly does "deriving (Functor, Monad, MonadIO)" do? Message-ID: <910ddf450705010242w7d412bc4y71bb1788fe9d3901@mail.gmail.com> I was trying to follow the reasoning in Don's article on using haskell for shell scripting http://cgi.cse.unsw.edu.au/~dons/blog/2007/03/10 In the source listing at the end we is newtype Shell a = Shell { runShell :: ErrorT String IO a } deriving (Functor, Monad, MonadIO) and I don't understand it what "deriving" is doing here, nor have I been able to find documentation on it. http://en.wikibooks.org/wiki/Haskell/Class_declarations claims: "You can only use deriving with a limited set of built-in classes. They are: Eq Ord Enum Bounded Show Read " But, here we are deriving classes not in that list. So, is this a recently added feature? Or something that came in from {-# OPTIONS -fglasgow-exts #-} ? I would just like to understand this, and I can't figure out how to begin. Thanks for any help! thomas. From dons at cse.unsw.edu.au Tue May 1 05:47:45 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Tue May 1 05:45:12 2007 Subject: [Haskell-cafe] what exactly does "deriving (Functor, Monad, MonadIO)" do? In-Reply-To: <910ddf450705010242w7d412bc4y71bb1788fe9d3901@mail.gmail.com> References: <910ddf450705010242w7d412bc4y71bb1788fe9d3901@mail.gmail.com> Message-ID: <20070501094745.GB25239@cse.unsw.EDU.AU> tphyahoo: > I was trying to follow the reasoning in Don's article on using haskell > for shell scripting > > http://cgi.cse.unsw.edu.au/~dons/blog/2007/03/10 > > In the source listing at the end we is > > newtype Shell a = Shell { runShell :: ErrorT String IO a } > deriving (Functor, Monad, MonadIO) > > and I don't understand it what "deriving" is doing here, nor have I > been able to find documentation on it. That's 'cunning newtype deriving, my new favourite ghc language extension. http://www.haskell.org/ghc/docs/latest/html/users_guide/type-extensions.html#newtype-deriving We also use it in xmonad, newtype X a = X (ReaderT XConf (StateT XState IO) a) deriving (Functor, Monad, MonadIO, MonadState XState, MonadReader XConf) :-) -- Don From simonmarhaskell at gmail.com Tue May 1 05:55:11 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Tue May 1 05:52:37 2007 Subject: [Haskell-cafe] Re: Poor first impression In-Reply-To: <20070501013505.GA957@laptop.gateway.2wire.net> References: <52733fad0704270228i1d36813fpe751b15d34764e9d@mail.gmail.com> <52733fad0704270300x351ff135p1d4dda3334184443@mail.gmail.com> <20070427130935.1cc98d32@greenrd.ucd.ie> <1177803879.28288.43.camel@localhost.localdomain> <4633E17D.3040600@gmail.com> <20070430152927.GA895@jobbicycle.corp.yahoo.com> <20070430191547.GA2480@jobbicycle.corp.yahoo.com> <46365732.5020003@btinternet.com> <20070501013505.GA957@laptop.gateway.2wire.net> Message-ID: <46370E7F.5030401@microsoft.com> brad clawsie wrote: > On Mon, Apr 30, 2007 at 09:53:06PM +0100, Andrew Coppin wrote: >> brad clawsie wrote: >>> installing a modern linux on this box is a thirty minute exercise. >> Ah - a volunteer! :-) > > absolutely! for the low cost of one round-trip business-class seat from > san jose to wherever this box is, and i will happily insert a recent > ubuntu cd and click the install icon. Well, no way is it a 30 minute job to upgrade the OS on a production multi-user Linux system. Surely I don't need to go into details here. A better solution would be to use someone else's box via BuildBot. I think someone offered to donate a couple of FC boxes for the builds recently. Cheers, Simon From tphyahoo at gmail.com Tue May 1 06:05:26 2007 From: tphyahoo at gmail.com (Thomas Hartman) Date: Tue May 1 06:02:47 2007 Subject: [Haskell-cafe] what exactly does "deriving (Functor, Monad, MonadIO)" do? In-Reply-To: <20070501094745.GB25239@cse.unsw.EDU.AU> References: <910ddf450705010242w7d412bc4y71bb1788fe9d3901@mail.gmail.com> <20070501094745.GB25239@cse.unsw.EDU.AU> Message-ID: <910ddf450705010305v6fe622feydf64444052f5f1e5@mail.gmail.com> Thanks Dons. There's also a short and sweet explanation here. http://hackage.haskell.org/trac/haskell-prime/wiki/NewtypeDeriving I am going to try and wrap my head around this, as I am very interested in solutions for haskell / shell interaction. Are there are any good examples of code written without this extension, alongside code condensed by using this extension. That would be helpful for understanding what's going on. Thomas. 2007/5/1, Donald Bruce Stewart : > tphyahoo: > > I was trying to follow the reasoning in Don's article on using haskell > > for shell scripting > > > > http://cgi.cse.unsw.edu.au/~dons/blog/2007/03/10 > > > > In the source listing at the end we is > > > > newtype Shell a = Shell { runShell :: ErrorT String IO a } > > deriving (Functor, Monad, MonadIO) > > > > and I don't understand it what "deriving" is doing here, nor have I > > been able to find documentation on it. > > That's 'cunning newtype deriving, my new favourite ghc language > extension. > > http://www.haskell.org/ghc/docs/latest/html/users_guide/type-extensions.html#newtype-deriving > > We also use it in xmonad, > > newtype X a = X (ReaderT XConf (StateT XState IO) a) > deriving (Functor, Monad, MonadIO, MonadState XState, MonadReader XConf) > > :-) > > -- Don > From josef.svenningsson at gmail.com Tue May 1 06:24:59 2007 From: josef.svenningsson at gmail.com (Josef Svenningsson) Date: Tue May 1 06:22:21 2007 Subject: [Haskell-cafe] Bloom Filter In-Reply-To: <20070430223928.qe70ggo4soss8sgw@webmail.spamcop.net> References: <83d2d2f80704300727q1265cc62sf3505f42d52b59ad@mail.gmail.com> <20070430223928.qe70ggo4soss8sgw@webmail.spamcop.net> Message-ID: <8dde104f0705010324x635e7698j80e13442b7ff1665@mail.gmail.com> Hi, Just a small comment on one of the comments. On 5/1/07, ajb@spamcop.net wrote: > Also, rather than this: > > add :: Bloom a -> a -> Bloom a > > a better argument order is this: > > insert :: a -> Bloom a -> Bloom a > > That way, you can use it with foldr. > Hmmm. If you want to create a Bloom using a fold wouldn't it make more sense to use foldl'? I think the argument order is fine. Cheers, Josef From duncan.coutts at worc.ox.ac.uk Tue May 1 07:02:18 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 1 07:12:22 2007 Subject: [Haskell-cafe] Cabal, lib and exe in one In-Reply-To: <20070501083404.GD3718@die.therning.org> References: <20070501083404.GD3718@die.therning.org> Message-ID: <1178017338.6211.113.camel@localhost> On Tue, 2007-05-01 at 09:34 +0100, Magnus Therning wrote: > I'm trying to create a single cabal file containing specs for both a > library and an executable using that library. I'm not having much luck > though :( > > This is what I have so far: > > name: foo > version: 0.1 > exposed-modules: Foo.Bar > other-modules: Foo.Qux Foo.C2HS > hs-source-dirs: src > include-dirs: csrc > c-sources: csrc/qux.c > extensions: ForeignFunctionInterface > build-depends: base, haskell98 > > executable: foo > hs-source-dirs: test-src > main-is: foo.hs > other-modules: Foo.Bar > > When built this is the message I get: > test-src/foo.hs:5:7: > Could not find module `Foo.Bar': > Use -v to see a list of the files searched for. > > How do I specify that Foo.Bar is found where cabal puts it > (./dist/build/)? But surely Foo.Bar is in src, it is afterall exactly the same module as the one you're using in the library, no? So if foo.hs is in test-src and Foo/Bar.hs is in src then I think you just need: hs-source-dirs: test-src, src You cannot specify that things are found in dist/build since that dir can placed anywhere by the user. But I don't see that you'd want to, I can't see how it makes any sense. Duncan From sebastian.sylvan at gmail.com Tue May 1 07:21:30 2007 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Tue May 1 07:18:52 2007 Subject: [Haskell-cafe] Re: 'Proper' use of the State monad In-Reply-To: References: <608932c00704301416i39543a2bg2dd677004dd06ffe@mail.gmail.com> Message-ID: <3d96ac180705010421o5d329fa5l8cb7b1ec685b23e3@mail.gmail.com> On 5/1/07, DavidA wrote: > > > 1) Using State GameState r and then call execState for each game event > > (i.e. user input) so I can do IO > > 2) Using StateT GameState IO () and have the entire game live in one > > big execStateT call. (I note XMonad does something similar.) > > I'm also interested in the answer to this question. One concern I would > have > about option 2 is that it looks like it "breaks encapsulation", to use a > phrase > from OOP. > > What I mean is, it seems like good design would mean that you could write > and > test the game logic totally independently of any IO. Game functions such > as "makeMove" ought to have type signatures that don't involve any IO. Can > this > be achieved in option 2? You could, of course, do both. I do think it's a good idea to write your own "game monad" which encapsulates all of the unsafe functions that you might want to do in an application specific approprate way, rather than just having your "unsafe skin" be the IO monad. So for example, if you want to spawn an actor in the game world and attach an AI thread to govern its behaviour you'd need a function which interanlly uses forkIO, sets up a bunch of TVars for messaging etc., but from the Game monad's pespective that can be encapsulated. There *are* things which are just inherently imperative in nature, and are easier to do like that (threads with message passing, for example, is not necessarily bad, sometimes they are the Right Abstraction -- actor AI is probably a good example), but you can make it a lot nicer and less unsafe by writing your own "unsafe skin" which supplies slightly safer encapsulations tailored for your specific application. But of course, you could have another monad which ONLY deals with pure changes to the game state that you then evaluate from the underlying monad. So the GameEngine monad is the "unsafe skin", and then you have the Game monad which just does a pure computation on the game state. Then you'd have a function like: game :: Game a -> GameEngine a game g = do state <- get gstate <- gameState state let ( res, gstate' ) = runState g put ( state{ gameState = gstate' } ) return res Which simply runs a game action on the game part of the GameEngine state. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20070501/7a497e81/attachment.htm From allbery at ece.cmu.edu Tue May 1 07:57:21 2007 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Tue May 1 07:54:45 2007 Subject: [Haskell-cafe] what exactly does "deriving (Functor, Monad, MonadIO)" do? In-Reply-To: <910ddf450705010305v6fe622feydf64444052f5f1e5@mail.gmail.com> References: <910ddf450705010242w7d412bc4y71bb1788fe9d3901@mail.gmail.com> <20070501094745.GB25239@cse.unsw.EDU.AU> <910ddf450705010305v6fe622feydf64444052f5f1e5@mail.gmail.com> Message-ID: <07043AB4-7FBC-4067-88C1-4C9658B82A43@ece.cmu.edu> On May 1, 2007, at 6:05 , Thomas Hartman wrote: > Are there are any good examples of code written without this > extension, alongside code condensed by using this extension. That > would be helpful for understanding what's going on. I think all this does is save you from having to write a bunch of wrappers that unwrap the contained value, do something to it, and rewrap the result. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From dmhouse at gmail.com Tue May 1 09:44:17 2007 From: dmhouse at gmail.com (David House) Date: Tue May 1 09:41:39 2007 Subject: [Haskell-cafe] what exactly does "deriving (Functor, Monad, MonadIO)" do? In-Reply-To: <07043AB4-7FBC-4067-88C1-4C9658B82A43@ece.cmu.edu> References: <910ddf450705010242w7d412bc4y71bb1788fe9d3901@mail.gmail.com> <20070501094745.GB25239@cse.unsw.EDU.AU> <910ddf450705010305v6fe622feydf64444052f5f1e5@mail.gmail.com> <07043AB4-7FBC-4067-88C1-4C9658B82A43@ece.cmu.edu> Message-ID: On 01/05/07, Brandon S. Allbery KF8NH wrote: > I think all this does is save you from having to write a bunch of > wrappers that unwrap the contained value, do something to it, and > rewrap the result. Exactly. Basically what newtype deriving does is if you have a declaration like the following: newtype T = TConstructor M And M instantiates some class (like Monad, Functor etc), you can derive that class for T. For example, here's how the Functor instance would look for the following newtype: newtype MyMaybe a = MM (Maybe a) deriving (Functor) -- The instance looks like this: instance Functor MyMaybe where fmap f (MM a) = MM (fmap f a) The instance just unwraps and rewraps the newtype constructor. -- -David House, dmhouse@gmail.com From simonpj at microsoft.com Tue May 1 11:57:13 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue May 1 11:54:37 2007 Subject: [Haskell-cafe] Displaying infered type signature of 'offside' functions In-Reply-To: References: Message-ID: | I like the strong static type system of Haskell for various | reasons. One reason is, that it makes easier to understand new | code. I.e. when I read code I type ':t foo' in ghci/hugs from | time to time, to check my own idea of the type signature, if it | is not included in the source code. The principal difficulties here are to do with "what do we want" rather the implementation challenges. 1. Should the compiler print the type of every declaration? Should GHCi allow you to ask the type of a local decl? 2. How should the variables be identified? There may be many local bindings for 'f', so you can't say just ":t f". Ditto if dumping all local bindings. 3. Do you want all locally-bound variables (including those bound by lambda or case), or just letrec/where bound ones? I think 'all', myself, but there are a lot of them. 4. (This is the trickiest one.) The type of a function may mention type variables bound further out. Consider f :: [a] -> Int f xs = let v = head xs in ... The type of 'v' is simply 'a'. Not 'forall a. a', but rather 'if xs:[a] then *that* a!' In general there may also be existential type variables bound by an enclosing pattern match too. So it's not easy to see how to report v's type. In general there is no type signature for f, which only makes matters worse, since there is no name to use for the in-scope type variable. These are all user-interface issues. If some people would like to thrash out a design, and put it on the Wiki, I think there is a good chance that someone (possibly even me) would implement it. Simon From rich.neswold at gmail.com Tue May 1 14:00:28 2007 From: rich.neswold at gmail.com (Rich Neswold) Date: Tue May 1 13:57:48 2007 Subject: [Haskell-cafe] Getting the number of seconds since epoch from System.Time.ClockTime In-Reply-To: <4630B4F2.6090508@martinpercossi.com> References: <4630B4F2.6090508@martinpercossi.com> Message-ID: <14cf844b0705011100x24464c0cqe36741edfe7b844b@mail.gmail.com> On 4/26/07, Martin Percossi wrote: > In System.Time, > > data ClockTime = TOD Integer Integer > > , where the first integer represents the number of seconds since epoch, > and the other represents the number of picoseconds. Is there a way of > retrieving the first part? (In Haskell 98, the ClockTime type is abstract). I usually pattern match the constructor: do { TOD epoch _ <- getClockTime ; putStrLn $ "epoch is " ++ show epoch } -- Rich AIM : rnezzy ICQ : 174908475 Jabber: rich@neswold.homeunix.net -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20070501/9af9d3aa/attachment.htm From nominolo at googlemail.com Tue May 1 15:19:27 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Tue May 1 15:16:53 2007 Subject: [Haskell-cafe] Re: Type-level programming problem In-Reply-To: <20070501041207.CCECEAD3E@Adric.metnet.fnmoc.navy.mil> References: <20070501041207.CCECEAD3E@Adric.metnet.fnmoc.navy.mil> Message-ID: <031B5B36-7275-4D38-9373-D9B6BBD184D4@googlemail.com> On 1 maj 2007, at 06.12, oleg@pobox.com wrote: > > We see it is a value polymorphic over four type variables: ns, a, b, > and c. The type variable 'a' is also the type of the value, so we have > a way to instantiate it. There is no direct way to instantiate the > remaining three. If there were a functional dependency a -> ns, a->b, > a->c, we could have instantiated the remaining variables. But there > are no such dependencies. So, there is really no way we can > ever instantiate the type variables ns, b and c -- and so the > typechecker > will complain. > > So, we need either a functional dependency a -> ns in the definition > of Foo, or defaultA should have a signature defaultA :: ns -> a > (and ditto for other defaults). In fact I had this signature for a while, but then I had already changed the definition of Foo to a different signature. Good to know that I wasn't too far off.. > As I understand, the function > 'defaultA' can be present in different components, identified by > ns. When we write 'defaultA' however, how can we say that we mean > defaultA of component X rather than of component Y? There isn't any > way to name the desired component... > > Incidentally, if we represent components by records > data XRec = XRec { defaultA :: XA } > then the type of defaultA is Xref -> XA. It is the function from the > type of the `namespace'. This seems to suggest the > signature of defaultA should be ns -> a ... > > BTW, there are other ways to add the name of the namespace to the > signature of defaultA. For example: > newtype TaggedT ns a = TaggedT a > class Foo ns a b c | ... > defaultA :: TaggedT ns a > or > class Foo ns a b c | ... > defaultA :: ns a > > etc. Thank you for your quick and helpful response. I'll look into what works best for my purposes. Thanks, / Thomas From ndmitchell at gmail.com Tue May 1 15:37:09 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Tue May 1 15:34:28 2007 Subject: [Haskell-cafe] Hugs/nhc getting progressively slower Message-ID: <404396ef0705011237xd432910ibb511d5a619917bd@mail.gmail.com> Hi, I like to develop on Hugs, because its a nice platform to work with, and provides WinHugs, auto-reloading, sub-second compilation etc. Unfortunately some of the newer libraries (ByteString/Binary in particular) have been optimised to within an inch of their lives on GHC, at the cost of being really really slow on Hugs. Taking the example of Yhc Core files, which are stored in binary. Using a very basic hPutChar sequence is miles faster (10x at least) than all the fancy ByteString/Binary trickery. Taking the example of nobench, Malcolm told me he reimplemented ByteString in terms of [Char] and gained a massive performance increase (6000x springs to mind, but that seems way too high to be true) using nhc. Could we have a collective thought, and decide whether we wish to either kill off all compilers that don't start with a G, or could people at least do minimal benchmarking on Hugs? I'm not quite sure what the solution is, but it probably needs some discussion. Thanks Neil From pvolgger at gmail.com Tue May 1 15:51:37 2007 From: pvolgger at gmail.com (Philipp Volgger) Date: Tue May 1 15:49:11 2007 Subject: [Haskell-cafe] Is Hs-Plugins dead? Message-ID: <46379A49.8060904@gmail.com> Is Hs-Plugins still under develeopment; is there still somebody who is updating it? From dominic.steinitz at blueyonder.co.uk Tue May 1 16:19:35 2007 From: dominic.steinitz at blueyonder.co.uk (Dom) Date: Tue May 1 16:33:17 2007 Subject: [Haskell-cafe] Bloom Filter References: 20070430223928.qe70ggo4soss8sgw@webmail.spamcop.net Message-ID: <4637A0D7.5010109@blueyonder.co.uk> > > Reminds me of this code from Data.Binary: > > unroll :: Integer -> [Word8] > unroll = unfoldr step > where > step 0 = Nothing > step i = Just (fromIntegral i, i `shiftR` 8) > > roll :: [Word8] -> Integer > roll = foldr unstep 0 > where > unstep b a = a `shiftL` 8 .|. fromIntegral b > > Which is a bit stream-fusion inspired, I must admit. > But better than what is in Codec.Utils: > toBase x = > map fromIntegral . > reverse . > map (flip mod x) . > takeWhile (/=0) . > iterate (flip div x) > > -- | Take a number a convert it to base n as a list of octets. > > toOctets :: (Integral a, Integral b) => a -> b -> [Octet] > toOctets n x = (toBase n . fromIntegral) x > powersOf n = 1 : (map (*n) (powersOf n)) > -- | Take a list of octets (a number expressed in base n) and convert it > -- to a number. > > fromOctets :: (Integral a, Integral b) => a -> [Octet] -> b > fromOctets n x = > fromIntegral $ > sum $ > zipWith (*) (powersOf n) (reverse (map fromIntegral x)) It seems a shame that everyone has to roll their own. Dominic. From duncan.coutts at worc.ox.ac.uk Tue May 1 16:43:14 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 1 16:53:17 2007 Subject: [Haskell-cafe] Hugs/nhc getting progressively slower In-Reply-To: <404396ef0705011237xd432910ibb511d5a619917bd@mail.gmail.com> References: <404396ef0705011237xd432910ibb511d5a619917bd@mail.gmail.com> Message-ID: <1178052194.9770.19.camel@localhost> On Tue, 2007-05-01 at 20:37 +0100, Neil Mitchell wrote: > Hi, > > I like to develop on Hugs, because its a nice platform to work with, > and provides WinHugs, auto-reloading, sub-second compilation etc. > Unfortunately some of the newer libraries (ByteString/Binary in > particular) have been optimised to within an inch of their lives on > GHC, at the cost of being really really slow on Hugs. > > Taking the example of Yhc Core files, which are stored in binary. > Using a very basic hPutChar sequence is miles faster (10x at least) > than all the fancy ByteString/Binary trickery. > > Taking the example of nobench, Malcolm told me he reimplemented > ByteString in terms of [Char] and gained a massive performance > increase (6000x springs to mind, but that seems way too high to be > true) using nhc. That does not surprise me. > Could we have a collective thought, and decide whether we wish to > either kill off all compilers that don't start with a G, or could > people at least do minimal benchmarking on Hugs? I'm not quite sure > what the solution is, but it probably needs some discussion. I don't think doing minimal benchmarking on hugs will help at all unless we are prepared to act on it and I'm pretty sure anything we do to improve hugs performance will be detrimental to the GHC performance. We're optimising for totally different sets of primitives. With GHC we're optimising for machine code and thinking about branch prediction and cache misses. We're also writing high level combinators that are quite inefficient to execute directly but we rely on inlining and rewrite rules to combine then expand them to efficient low level code. With hugs/yhc/nhc I assume the optimisation technique is simply to minimise the number of primitive reduction steps. This is really totally different. I don't see any obvious way of reconciling the two in a single implementation of an interface. Having totally different implementations of an interface for different Haskell systems is an option though it has obvious disadvantages. So I don't know what to do. We're not stopping out quest for high performance idiomatic code because it doesn't play nicely with interpreters. Duncan From magnus at therning.org Tue May 1 17:29:20 2007 From: magnus at therning.org (Magnus Therning) Date: Tue May 1 17:26:46 2007 Subject: [Haskell-cafe] Cabal, lib and exe in one In-Reply-To: <1178017338.6211.113.camel@localhost> References: <20070501083404.GD3718@die.therning.org> <1178017338.6211.113.camel@localhost> Message-ID: <20070501212920.GA3838@die.therning.org> On Tue, May 01, 2007 at 12:02:18 +0100, Duncan Coutts wrote: >On Tue, 2007-05-01 at 09:34 +0100, Magnus Therning wrote: >> I'm trying to create a single cabal file containing specs for both a >> library and an executable using that library. I'm not having much luck >> though :( >> >> This is what I have so far: >> >> name: foo >> version: 0.1 >> exposed-modules: Foo.Bar >> other-modules: Foo.Qux Foo.C2HS >> hs-source-dirs: src >> include-dirs: csrc >> c-sources: csrc/qux.c >> extensions: ForeignFunctionInterface >> build-depends: base, haskell98 >> >> executable: foo >> hs-source-dirs: test-src >> main-is: foo.hs >> other-modules: Foo.Bar >> >> When built this is the message I get: >> test-src/foo.hs:5:7: >> Could not find module `Foo.Bar': >> Use -v to see a list of the files searched for. >> >> How do I specify that Foo.Bar is found where cabal puts it >> (./dist/build/)? > >But surely Foo.Bar is in src, it is afterall exactly the same module as >the one you're using in the library, no? Yes. >So if foo.hs is in test-src and Foo/Bar.hs is in src then I think you >just need: > >hs-source-dirs: test-src, src No, that's not enough, I also have to add the following lines to make the executable compile and link: extensions: ForeignFunctionInterface c-sources: csrc/ptrace.c That is, I end up compiling the library a second time! Can't I get the executable to link against the library that was just created? >You cannot specify that things are found in dist/build since that dir >can placed anywhere by the user. But I don't see that you'd want to, I >can't see how it makes any sense. I was just expecting to not have to repeat myself in the cabal file. Not such a strange thing to expect from a build system, I think :-) Also, I don't really see what you mean by "that dir can be placed anywhere by the user". That dir is created as part of the build process and it's location is, AFAICS, always going to be ./dist/build. Finding the library after installation is another matter, but that problem should be taken care of during the `./Setup.hs configure` stage. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus@therning.org Jabber: magnus.therning@gmail.com http://therning.org/magnus -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20070501/a61494a0/attachment.bin From gale at sefer.org Tue May 1 18:10:51 2007 From: gale at sefer.org (Yitzchak Gale) Date: Tue May 1 18:08:13 2007 Subject: [Haskell-cafe] Re: 'Proper' use of the State monad In-Reply-To: References: <608932c00704301416i39543a2bg2dd677004dd06ffe@mail.gmail.com> Message-ID: <2608b8a80705011510h13256278s7d27f2475fc89c2f@mail.gmail.com> DavidA wrote: > What I mean is, it seems like good design would mean that you could write and > test the game logic totally independently of any IO. Game functions such > as "makeMove" ought to have type signatures that don't involve any IO. Can this > be achieved in option 2? Here is one way: For functions that do not need IO, use types that look like: MonadState GameState m => ... -> m a For functions that only do IO without refering to the game state, use: MonadIO m => ... -> m a For functions that do both, use: (MonadIO m, MonadState GameState m) => ... -> m a Testing of the pure game functions can use State GameState, testing of pure IO functions can use IO, and production can use StateT GameState IO. -Yitz From stefanor at cox.net Tue May 1 18:27:53 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Tue May 1 18:25:14 2007 Subject: [Haskell-cafe] Is Hs-Plugins dead? In-Reply-To: <46379A49.8060904@gmail.com> References: <46379A49.8060904@gmail.com> Message-ID: <20070501222753.GA2912@localhost.localdomain> On Tue, May 01, 2007 at 09:51:37PM +0200, Philipp Volgger wrote: > Is Hs-Plugins still under develeopment; is there still somebody who is > updating it? Not really. It works perfectly and fills its niche. Mature software is not under development! It is still maintained by Don Stewart. Stefan From duncan.coutts at worc.ox.ac.uk Tue May 1 19:33:18 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue May 1 19:43:21 2007 Subject: [Haskell-cafe] Cabal, lib and exe in one In-Reply-To: <20070501212920.GA3838@die.therning.org> References: <20070501083404.GD3718@die.therning.org> <1178017338.6211.113.camel@localhost> <20070501212920.GA3838@die.therning.org> Message-ID: <1178062398.9770.31.camel@localhost> On Tue, 2007-05-01 at 22:29 +0100, Magnus Therning wrote: > >So if foo.hs is in test-src and Foo/Bar.hs is in src then I think you > >just need: > > > >hs-source-dirs: test-src, src > > No, that's not enough, I also have to add the following lines to make > the executable compile and link: > > extensions: ForeignFunctionInterface > c-sources: csrc/ptrace.c > > That is, I end up compiling the library a second time! Can't I get the > executable to link against the library that was just created? > I was just expecting to not have to repeat myself in the cabal file. > Not such a strange thing to expect from a build system, I think :-) Yes this is an interesting question about what it means to have programs in the same cabal package as an executable. Currently having a executable and a library inside a cabal package is not the same thing as having a library package and separate package that contains only that executable. The difference is that when the executable is in the same cabal package it merely has access to the same modules, it doesn't 'depend' on that library package exactly. So for example it can access modules which are not exposed by the library and indeed it can compile those same modules with completely different build flags. So currently those modules will be built twice. It's not clear to me that this is the right meaning, or indeed that we should allow multiple entries in a single .cabal file. I think it might be better to just have multiple .cabal files (possibly in the same directory). Then we could be explicit and state that an executable depends on the library or if we want to use different build flags, or use modules that are not exposed by the lib then we can do that and only in that case do we build those modules twice. > Also, I don't really see what you mean by "that dir can be placed > anywhere by the user". That dir is created as part of the build > process and it's location is, AFAICS, always going to be ./dist/build. Actually it's location can be set at configure time with --scratchdir= so that for example you could put it in a temp dir or something. Duncan From ajb at spamcop.net Tue May 1 20:22:22 2007 From: ajb at spamcop.net (ajb@spamcop.net) Date: Tue May 1 20:19:42 2007 Subject: [Haskell-cafe] Bloom Filter In-Reply-To: <4637A0D7.5010109@blueyonder.co.uk> References: 20070430223928.qe70ggo4soss8sgw@webmail.spamcop.net <4637A0D7.5010109@blueyonder.co.uk> Message-ID: <20070501202222.dmr4sssgsk444k4g@webmail.spamcop.net> G'day all. Quoting Dom : > But better than what is in Codec.Utils: [deletia] > It seems a shame that everyone has to roll their own. That and integer log base 2. Cheers, Andrew Bromage From ajb at spamcop.net Tue May 1 20:28:02 2007 From: ajb at spamcop.net (ajb@spamcop.net) Date: Tue May 1 20:25:21 2007 Subject: [Haskell-cafe] Bloom Filter In-Reply-To: <8dde104f0705010324x635e7698j80e13442b7ff1665@mail.gmail.com> References: <83d2d2f80704300727q1265cc62sf3505f42d52b59ad@mail.gmail.com> <20070430223928.qe70ggo4soss8sgw@webmail.spamcop.net> <8dde104f0705010324x635e7698j80e13442b7ff1665@mail.gmail.com> Message-ID: <20070501202802.lmego8wkg8g0og0w@webmail.spamcop.net> G'day all. I wrote: > > insert :: a -> Bloom a -> Bloom a > > > > That way, you can use it with foldr. Quoting Josef Svenningsson : > Hmmm. If you want to create a Bloom using a fold wouldn't it make more > sense to use foldl'? I think the argument order is fine. You're right that foldl' makes more sense than foldr in this case. Nevertheless, the usual Haskell convention is that insert-like functions have the same argument order as the cons operator (:). Haskell libraries have a real problem with the proliferation of conventions for various things. This order is the usual convention, so follow it. If you don't like it, there's always "flip". Cheers, Andrew Bromage From dons at cse.unsw.edu.au Tue May 1 20:40:01 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Tue May 1 20:37:25 2007 Subject: [Haskell-cafe] Is Hs-Plugins dead? In-Reply-To: <46379A49.8060904@gmail.com> References: <46379A49.8060904@gmail.com> Message-ID: <20070502004001.GA26667@cse.unsw.EDU.AU> pvolgger: > Is Hs-Plugins still under develeopment; is there still somebody who is > updating it? It's in stasis. It will likely get a little bit more updating when I finish my phd. It's needed for lambdabot in #haskell, so that's enough pressure to keep it working :-) For the longer term, a more maintainable approach is to provide an hs-plugins api over the ghc-api, in my opinion. Then the bits of hs-plugins that break when compiler versions change (.hi file parsing and package file parsing), won't break. -- Don From dons at cse.unsw.edu.au Tue May 1 21:39:07 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Tue May 1 21:36:33 2007 Subject: [Haskell-cafe] Hugs/nhc getting progressively slower In-Reply-To: <404396ef0705011237xd432910ibb511d5a619917bd@mail.gmail.com> References: <404396ef0705011237xd432910ibb511d5a619917bd@mail.gmail.com> Message-ID: <20070502013907.GC26667@cse.unsw.EDU.AU> ndmitchell: > Hi, > > I like to develop on Hugs, because its a nice platform to work with, > and provides WinHugs, auto-reloading, sub-second compilation etc. > Unfortunately some of the newer libraries (ByteString/Binary in > particular) have been optimised to within an inch of their lives on > GHC, at the cost of being really really slow on Hugs. > > Taking the example of Yhc Core files, which are stored in binary. > Using a very basic hPutChar sequence is miles faster (10x at least) > than all the fancy ByteString/Binary trickery. > > Taking the example of nobench, Malcolm told me he reimplemented > ByteString in terms of [Char] and gained a massive performance > increase (6000x springs to mind, but that seems way too high to be > true) using nhc. > > Could we have a collective thought, and decide whether we wish to > either kill off all compilers that don't start with a G, or could > people at least do minimal benchmarking on Hugs? I'm not quite sure > what the solution is, but it probably needs some discussion. I'm not sure how we can optimise both for interpreters, and compilers. The Binary and ByteString stuff pays close attention to the hardware: cache misses, branch prediction. And there's no option to abandon high performance compiled Haskell, to help out the interpreters. Interestingly, the techniques we use for, say, Data.ByteString, seem to also produce very good results in MLton. So it really is a matter of optimising for compiled native code, versus bytecode interpreters. I don't know if there's anything that can be done here. -- Don From bos at serpentine.com Wed May 2 02:24:10 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Wed May 2 02:24:22 2007 Subject: [Haskell-cafe] ANN: FileManip 0.1, an expressive file manipulation library Message-ID: <46382E8A.1070106@serpentine.com> The FileManip package provides expressive functions and combinators for searching, matching, and manipulating files. It provides three modules. System.FilePath.Find lets you search a filesystem hierarchy efficiently: find always (extension ==? ".rb") >>= mapM_ remove System.FilePath.GlobPattern lets you perform glob-style pattern matching, without going through a regexp engine: "foo.c" ~~ "*.c" ==> True System.FilePath.Manip lets you rename files procedurally, edit files in place, or save old copies as backups: modifyWithBackup (<.> "bak") (unlines . map (takeWhile (/= ',')) . lines) "myPoorFile.csv" From bos at serpentine.com Wed May 2 02:25:58 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Wed May 2 02:26:09 2007 Subject: [Haskell-cafe] ANN: FileManip 0.1, an expressive file manipulation library In-Reply-To: <46382E8A.1070106@serpentine.com> References: <46382E8A.1070106@serpentine.com> Message-ID: <46382EF6.8070504@serpentine.com> Bryan O'Sullivan wrote: > The FileManip package provides expressive functions and combinators for > searching, matching, and manipulating files. As seems to be my habit, I forgot something important, namely where to get FileManip from. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/FileManip-0.1 Online docs: http://darcs.serpentine.com/filemanip/dist/doc/html/FileManip/ Darcs repo: darcs get http://darcs.serpentine.com/filemanip From claus.reinke at talk21.com Wed May 2 04:59:17 2007 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed May 2 04:56:40 2007 Subject: [Haskell-cafe] ANN: FileManip 0.1, an expressive file manipulationlibrary References: <46382E8A.1070106@serpentine.com> <46382EF6.8070504@serpentine.com> Message-ID: <005601c78c98$2b5c85f0$22418351@cr3lt> >> The FileManip package provides expressive functions and combinators for >> searching, matching, and manipulating files. hi Brian, i'm a fan of find | xargs, so a portable haskell replacement unencumbered by viral licenses would be very welcome. i have no intention to participate in yet-another-licencing-discussion, i would just like to ask whether those limitations of your offering are an accident or intended? claus From simonmarhaskell at gmail.com Wed May 2 05:08:41 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed May 2 05:06:02 2007 Subject: [Haskell-cafe] Cabal, lib and exe in one In-Reply-To: <1178062398.9770.31.camel@localhost> References: <20070501083404.GD3718@die.therning.org> <1178017338.6211.113.camel@localhost> <20070501212920.GA3838@die.therning.org> <1178062398.9770.31.camel@localhost> Message-ID: <46385519.1030804@microsoft.com> Duncan Coutts wrote: > On Tue, 2007-05-01 at 22:29 +0100, Magnus Therning wrote: > >>> So if foo.hs is in test-src and Foo/Bar.hs is in src then I think you >>> just need: >>> >>> hs-source-dirs: test-src, src >> No, that's not enough, I also have to add the following lines to make >> the executable compile and link: >> >> extensions: ForeignFunctionInterface >> c-sources: csrc/ptrace.c >> >> That is, I end up compiling the library a second time! Can't I get the >> executable to link against the library that was just created? > >> I was just expecting to not have to repeat myself in the cabal file. >> Not such a strange thing to expect from a build system, I think :-) > > Yes this is an interesting question about what it means to have programs > in the same cabal package as an executable. > > Currently having a executable and a library inside a cabal package is > not the same thing as having a library package and separate package that > contains only that executable. The difference is that when the > executable is in the same cabal package it merely has access to the same > modules, it doesn't 'depend' on that library package exactly. So for > example it can access modules which are not exposed by the library and > indeed it can compile those same modules with completely different build > flags. So currently those modules will be built twice. > > It's not clear to me that this is the right meaning, or indeed that we > should allow multiple entries in a single .cabal file. I think it might > be better to just have multiple .cabal files (possibly in the same > directory). Then we could be explicit and state that an executable > depends on the library or if we want to use different build flags, or > use modules that are not exposed by the lib then we can do that and only > in that case do we build those modules twice. Right at the front of the Cabal docs it says: "However having both a library and executables in a package does not work very well; if the executables depend on the library, they must explicitly list all the modules they directly or indirectly import from that library." IMO we shouldn't allow both a library and an exe in the same package. I think I argued against this originally, and my understanding is that doing this is deprecated, although perhaps not visibly enough. Whenever the question of what to do about lib+exe packages arises, the discussion tends to spiral out of control into what we should do about collections of packages in general. For now, the simple story is that each package should have either a single library or a single executable (even multiple executables in a package is questionable; if they share some code it shoud be in a package). Cheers, Simon From duncan.coutts at worc.ox.ac.uk Wed May 2 05:02:55 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed May 2 05:12:56 2007 Subject: [Haskell-cafe] ANN: FileManip 0.1, an expressive file manipulationlibrary In-Reply-To: <005601c78c98$2b5c85f0$22418351@cr3lt> References: <46382E8A.1070106@serpentine.com> <46382EF6.8070504@serpentine.com> <005601c78c98$2b5c85f0$22418351@cr3lt> Message-ID: <1178096575.9770.45.camel@localhost> On Wed, 2007-05-02 at 09:59 +0100, Claus Reinke wrote: > >> The FileManip package provides expressive functions and combinators for > >> searching, matching, and manipulating files. > > hi Brian, > > i'm a fan of find | xargs, so a portable haskell replacement unencumbered > by viral licenses would be very welcome. i have no intention to participate > in yet-another-licencing-discussion, i would just like to ask whether those > limitations of your offering are an accident or intended? http://hackage.haskell.org/cgi-bin/hackage-scripts/package/FileManip-0.1 Apparently it's under the *L*GPL not the GPL, so it's not the "viral" license that you were thinking of perhaps? Duncan From ndmitchell at gmail.com Wed May 2 06:48:16 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed May 2 06:45:36 2007 Subject: [Haskell-cafe] Hugs/nhc getting progressively slower In-Reply-To: <1178052194.9770.19.camel@localhost> References: <404396ef0705011237xd432910ibb511d5a619917bd@mail.gmail.com> <1178052194.9770.19.camel@localhost> Message-ID: <404396ef0705020348of75875ew170de36b6b29f7a9@mail.gmail.com> Hi > > Could we have a collective thought, and decide whether we wish to > > either kill off all compilers that don't start with a G, or could > > people at least do minimal benchmarking on Hugs? I'm not quite sure > > what the solution is, but it probably needs some discussion. > > I don't think doing minimal benchmarking on hugs will help at all unless > we are prepared to act on it and I'm pretty sure anything we do to > improve hugs performance will be detrimental to the GHC performance. #ifdef? Malcolm has a ByteString implementation that runs much faster under nhc, and I suspect would also run faster under Hugs. Why not have a big #ifdef around the difference? > With hugs/yhc/nhc I assume the optimisation technique is simply to > minimise the number of primitive reduction steps. This is really totally > different. I don't see any obvious way of reconciling the two in a > single implementation of an interface. Having totally different > implementations of an interface for different Haskell systems is an > option though it has obvious disadvantages. I can see that two implementations are undesirable, but at the moment people have a choice: to write fast GHC and slow Hugs (ByteString), or to write slow GHC and fast Hugs (String). If we could make ByteString the "right answer" always, then I think its a much nicer choice. For the particular case of ByteString, type ByteString=String means you roughly import Data.List - not that much additional work or maintenance. > So I don't know what to do. We're not stopping out quest for high > performance idiomatic code because it doesn't play nicely with > interpreters. Indeed, and you shouldn't! Your quest for nice idiomatic code has saved countless programmers from low-level IO prodding, and for that we salute you! However, if you could at least give a nod in the direction of Hugs, even if you get to 50% slower than before, it keeps Hugs at least useable with the new API's. Thanks Neil From claus.reinke at talk21.com Wed May 2 07:00:23 2007 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed May 2 06:57:45 2007 Subject: [Haskell-cafe] ANN: FileManip 0.1, an expressive filemanipulationlibrary References: <46382E8A.1070106@serpentine.com> <46382EF6.8070504@serpentine.com><005601c78c98$2b5c85f0$22418351@cr3lt> <1178096575.9770.45.camel@localhost> Message-ID: <009901c78ca9$16301500$22418351@cr3lt> >> i'm a fan of find | xargs, so a portable haskell replacement unencumbered >> by viral licenses would be very welcome. i have no intention to participate >> in yet-another-licencing-discussion, i would just like to ask whether those >> limitations of your offering are an accident or intended? > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/FileManip-0.1 > > Apparently it's under the *L*GPL not the GPL, so it's not the "viral" > license that you were thinking of perhaps? no, i browsed the license file before asking my question (no non-restrictive license needs to be longer than a page). if i wanted to use that library for anything i want to distribute, my only chance to avoid the source re-distribution and advertising clauses would be dynamic linking - the same reasons why some of us a looking forward to the gmp replacement. i'd rather roll my own find than look at the sources under the current license, which may or may not have been the author's intention when choosing that particular license. hence my question. similarly for the unix dependency - it could be inherent in the design, or an accident of the author's current platform. platform-independent haskelling if i may take this opportunity for a message to other haskell authors: haskell makes it possible to write portable code. there are some cases where platform dependencies are unavoidable, and where one might write code for one platform, hoping that others add the branches for their platforms. there are even fewer cases where the functionality provided does not apply to other platforms. but for the majority of code, the trick is simply not to use platform-specific tricks. a small price to pay for not being exclusive. ;-) claus From lemming at henning-thielemann.de Wed May 2 07:02:53 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed May 2 07:00:38 2007 Subject: [Haskell-cafe] 'Proper' use of the State monad In-Reply-To: <608932c00704301416i39543a2bg2dd677004dd06ffe@mail.gmail.com> References: <608932c00704301416i39543a2bg2dd677004dd06ffe@mail.gmail.com> Message-ID: On Mon, 30 Apr 2007, Denis Volk wrote: > Hello all, > > I am trying to make a (turn-based) game in Haskell and need to pass > around quite a bit of information, so using the State monad seems most > appropriate. My question is, which is a better idea: The famous "Why functional programming matters" contains an example for game programming. In this paper the complete tree of all possible games is constructed lazily, but only selected branches are visited. http://www.math.chalmers.se/~rjmh/Papers/whyfp.html From lemming at henning-thielemann.de Wed May 2 07:10:01 2007 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed May 2 07:07:25 2007 Subject: [Haskell-cafe] Bloom Filter In-Reply-To: <20070430223928.qe70ggo4soss8sgw@webmail.spamcop.net> References: <83d2d2f80704300727q1265cc62sf3505f42d52b59ad@mail.gmail.com> <20070430223928.qe70ggo4soss8sgw@webmail.spamcop.net> Message-ID: On Mon, 30 Apr 2007 ajb@spamcop.net wrote: > In bloom: > > Function guards are your friends! This: > > bloom hf sz hc = if condition > then b > else error "Badness" > > is almost always better expressed as: > > bloom hf sz hc > | condition = b > | otherwise = error "Badness" Why replacing the almost-function 'if' by a special syntactic construct? Why replacing the two-branch decision 'if' by a multi-branch construct (similar to "switch") with two-branches? Express simple things the simple way! From troy.taillefer at lmco.com Wed May 2 07:15:45 2007 From: troy.taillefer at lmco.com (Taillefer, Troy (EXP)) Date: Wed May 2 07:13:34 2007 Subject: FW: [Haskell-cafe] RE:Cross-over from Haskell.org [Haskell] Re: Newbie: what are the advantages of Haskell? Message-ID: These Haskell lists seems to have a problem of having to many elitist pricks on it admittedly I am probably in this category as well so I will help you guys and by eliminating one prick and remove myself from the list good luck with the rest of them Troy -----Original Message----- From: u.stenzel@web.de [mailto:u.stenzel@web.de] Sent: Tuesday, May 01, 2007 5:35 PM To: Taillefer, Troy (EXP) Subject: Re: [Haskell-cafe] RE:Cross-over from Haskell.org [Haskell] Re: Newbie: what are the advantages of Haskell? Taillefer, Troy (EXP) wrote: > I really dislike Perl as a programming language but I have to strongly > disagree about your statements about CPAN and the quality of its > contents. Consider Sturgeon's Law: 90% of everything is crap. It's true of CPAN, too, which is only a stand in for any large collection of libraries. We don't gain anything from wrapping or reimplementing the crap, therefore, if you like some particular library, you should ask for *that* library, nor for more libraries in general. no need to get all touchy-feely about this. > Perl is popular so it must have some merit. So is Crack. I still won't smoke it, though. > I don't subscribe to the > flawed reasoning that Perl Hackers just don't know any better or that > they are dumb, or intellectual inferior in some way. Well, I didn't make that point in the mail you're replying to, but I subscribe to it. Perl *is* unadultered crap, it *is* a bad idea carried to perfection, a shoddy language that teaches bad habits, rewards stupidity and encourages you to attack every problem with the same blunt old tool, the regex, and most Perl Hackers, those who voluntarily use it to solve actual problem, *are* in fact dumb, don't want to know any better and are resistant to education. Perl is in every way the opposite of Haskell, and I happen to like Haskell. Imitating Perl is even worse than imitating C++. ...but I don't even wan't to discuss this, neither in private nor on a mailing list. If you want to argue, ask Google for Erik Naggum; nothing more needs to be said about it. > ... I am pro choice. And I *choose* to belittle Perl Hackers as much as I want. If that stops anyone from using Perl, it's their *choice*. And you can *choose* to hate me for belittling you, jackass. Political Correctness is even more misguided than Perl. From duncan.coutts at worc.ox.ac.uk Wed May 2 07:04:19 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed May 2 07:14:19 2007 Subject: [Haskell-cafe] ANN: FileManip 0.1, an expressive filemanipulationlibrary In-Reply-To: <009901c78ca9$16301500$22418351@cr3lt> References: <46382E8A.1070106@serpentine.com> <46382EF6.8070504@serpentine.com><005601c78c98$2b5c85f0$22418351@cr3lt> <1178096575.9770.45.camel@localhost> <009901c78ca9$16301500$22418351@cr3lt> Message-ID: <1178103859.9770.50.camel@localhost> On Wed, 2007-05-02 at 12:00 +0100, Claus Reinke wrote: > >> i'm a fan of find | xargs, so a portable haskell replacement unencumbered > >> by viral licenses would be very welcome. i have no intention to participate > >> in yet-another-licencing-discussion, i would just like to ask whether those > >> limitations of your offering are an accident or intended? > > > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/FileManip-0.1 > > > > Apparently it's under the *L*GPL not the GPL, so it's not the "viral" > > license that you were thinking of perhaps? > > no, i browsed the license file before asking my question (no non-restrictive > license needs to be longer than a page). if i wanted to use that library for > anything i want to distribute, my only chance to avoid the source re-distribution > and advertising clauses would be dynamic linking Ah ok. Well remember that we will be getting dynamic linking in future and the solution at the moment with static linking is to distribute static libraries to allow the user to relink. This allows closed source apps and complies with the LGPL. Of course if you simply don't like licenses longer than a page there's not much anyone can do to help :-) Duncan From ttmrichter at gmail.com Wed May 2 07:37:46 2007 From: ttmrichter at gmail.com (Michael T. Richter) Date: Wed May 2 07:40:26 2007 Subject: FW: [Haskell-cafe] RE:Cross-over from Haskell.org [Haskell] Re: Newbie: what are the advantages of Haskell? In-Reply-To: References: Message-ID: <1178105866.24254.15.camel@localhost.localdomain> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20070502/eb02c18f/attachment-0001.bin From ndmitchell at gmail.com Wed May 2 07:57:25 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Wed May 2 07:54:43 2007 Subject: [Haskell-cafe] ANN: FileManip 0.1, an expressive filemanipulationlibrary In-Reply-To: <1178103859.9770.50.camel@localhost> References: <46382E8A.1070106@serpentine.com> <46382EF6.8070504@serpentine.com> <005601c78c98$2b5c85f0$22418351@cr3lt> <1178096575.9770.45.camel@localhost> <009901c78ca9$16301500$22418351@cr3lt> <1178103859.9770.50.camel@localhost> Message-ID: <404396ef0705020457v3bceaff1vf0e719c18f9b3725@mail.gmail.com> Hi > > no, i browsed the license file before asking my question (no non-restrictive > > license needs to be longer than a page). if i wanted to use that library for > > anything i want to distribute, my only chance to avoid the source re-distribution > > and advertising clauses would be dynamic linking > > Ah ok. Well remember that we will be getting dynamic linking in future > and the solution at the moment with static linking is to distribute > static libraries to allow the user to relink. This allows closed source > apps and complies with the LGPL. Remember than Yhc and Hugs both don't link the code together, so you can have more freedom with licenses. Of course, distributing your closed source app under Hugs isn't that sensible... Thanks Neil From tom at almostobsolete.net Wed May 2 08:21:50 2007 From: tom at almostobsolete.net (tom) Date: Wed May 2 08:19:12 2007 Subject: [Haskell-cafe] Bloom Filter In-Reply-To: <20070430223928.qe70ggo4soss8sgw@webmail.spamcop.net> References: <83d2d2f80704300727q1265cc62sf3505f42d52b59ad@mail.gmail.com> <20070430223928.qe70ggo4soss8sgw@webmail.spamcop.net> Message-ID: <83d2d2f80705020521v3b73c31esf6abae7ceed96b99@mail.gmail.com> Hi Andrew, Thanks for the comments, it really helps to have someone else's opinion on my code. I'll be applying what you've said as soon as I get a chance and I'm sure I'll have some more questions then. I'll certainly look more closely at the Set interface and try and duplicate all the parts which make sense. I've been using Darcs for a while with non-haskell projects as well as this project, however it seems that cabal strips out the darcs meta-data when making up a distribution tar file. Is there an option to have it include the darcs stuff? it seems like it could be quite useful and I can't really see a downside. If you're interested the Darcs repository is at: http://www.almostobsolete.net/bloom/ Tom On 5/1/07, ajb@spamcop.net wrote: > G'day. > > Quoting tom : > > > I'm pretty new to Haskell, I've been working on a Bloom filter[1] > > implementation as a learning exercise. > > Excellent! Sounds like a fun test. > > > I'd really appreciate it if someone more experienced would comment on > > the code. I'm sure there's plenty of places where I'm doing things in > > silly or overly complex ways. > > Sure. > > All in all, very well done. It works, and it looks pretty efficient. > My quibbles are mostly stylistic or syntactic in nature. Please > understand that the relative triviality of my quibbles is a sign that > there are really no major problems. > > This is not a criticism, but more an advertisement: What are you using > for source control here? Darcs is nice, and as a bonus, it's trivially > browsable from a web browser, which saves downloading and unpacking. > > General comments: > > You overuse parentheses. A lot. Definitions like this: > > ary = (listArray (0, wordc-1) (repeat 0)) > > don't need parentheses around them, and just add to the general noise > level. > > And (.&. ((size b)-1)) is much more cleanly expressed as (.&. (size b - 1)). > > Rather than carrying around a hash function, it might be better to use > a type class: > > class BloomHash k where > bloomHash :: k -> [Word8] > > In wordsize: > > You don't need to hard-code this. You can use: > > wordsize = bitSize (undefined::Word32) -- Or Int, of course! > > bitSize is defined in Data.Bits. > > In splitup: > > I got a bit confused by the local binding names. It's usual, especially > in generic code, to use "xs", "ys" etc for a list of "x" and "y". > Something like this might be more idiomatic: > > splitup n xs = let (xs1, xs2) = splitAt n xs > in xs1 : splitup n xs2 > > In indexes: > > (fromIntegral $ x `div` wordsize, fromIntegral $ x .&. (wordsize-1)) > > Seems intuitively wasteful. Either use divMod or bit operations. > > Similarly, (hashfunc b) key is the same as hashfunc b key. But even > better is: > > split bytecount . hashfunc b $ key > > That makes it obvious that it's a pipeline of functions applied to the key. > > This looks cool: > > bytes2int = foldr ((. (256 *)) . (+)) 0 . (map toInteger) > > but I'm not smart enough to parse it. This is both more readable and > shorter: > > bytes2int = foldr (\x r -> r*256 + fromInteger x) 0 > > Integer log2's are probably better done using integers only, or at least > abstracted out into a separate function. > > In bloom: > > Function guards are your friends! This: > > bloom hf sz hc = if condition > then b > else error "Badness" > > is almost always better expressed as: > > bloom hf sz hc > | condition = b > | otherwise = error "Badness" > > You can now inline b. (I can see why you put it in a where clause; now > you don't have to.) > > wordc, again, only needs integral arithmetic: > > wordc = ceiling ((fromIntegral a) / (fromIntegral b :: Double)) > > is more or less: > > wordc = (a+b-1) `div` b > > And drop the parentheses around the definition of ary. > > In add: > > Try to use function names that are close to names in existing libraries, > like Data.Set. "insert" sounds better here. > > Also, rather than this: > > add :: Bloom a -> a -> Bloom a > > a better argument order is this: > > insert :: a -> Bloom a -> Bloom a > > That way, you can use it with foldr. > > In test: > > Again, probably misnamed. Data.Set calls this "member". And again, > arguably the wrong argument ordering. > > Once again, well done. > > Cheers, > Andrew Bromage > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From allbery at ece.cmu.edu Wed May 2 08:59:27 2007 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Wed May 2 08:56:46 2007 Subject: [Haskell-cafe] ANN: FileManip 0.1, an expressive filemanipulationlibrary In-Reply-To: <009901c78ca9$16301500$22418351@cr3lt> References: <46382E8A.1070106@serpentine.com> <46382EF6.8070504@serpentine.com><005601c78c98$2b5c85f0$22418351@cr3lt> <1178096575.9770.45.camel@localhost> <009901c78ca9$16301500$22418351@cr3lt> Message-ID: On May 2, 2007, at 7:00 , Claus Reinke wrote: > my question. similarly for the unix dependency - it could be > inherent in the > design, or an accident of the author's current platform. The Haskell libraries don't currently provide a platform-independent way to do most file tests. I discovered this while working on the file test operators in Pugs: aside from some very basic tests, everything interesting requires the POSIX hierarchy (hence the unix package). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From magnus at therning.org Wed May 2 08:58:53 2007 From: magnus at therning.org (Magnus Therning) Date: Wed May 2 08:58:12 2007 Subject: [Haskell-cafe] Cabal, lib and exe in one In-Reply-To: <46385519.1030804@microsoft.com> References: <20070501083404.GD3718@die.therning.org> <1178017338.6211.113.camel@localhost> <20070501212920.GA3838@die.therning.org> <1178062398.9770.31.camel@localhost> <46385519.1030804@microsoft.com> Message-ID: <20070502125853.GC15079@die.therning.org> On Wed, May 02, 2007 at 10:08:41 +0100, Simon Marlow wrote: [..] >IMO we shouldn't allow both a library and an exe in the same package. >I think I argued against this originally, and my understanding is that >doing this is deprecated, although perhaps not visibly enough. >Whenever the question of what to do about lib+exe packages arises, the >discussion tends to spiral out of control into what we should do about >collections of packages in general. > >For now, the simple story is that each package should have either a >single library or a single executable (even multiple executables in a >package is questionable; if they share some code it shoud be in a >package). So, you are saying that I should split my library and its test app(s) into separate packages? That would also mean that I have to install the library before compiling and running the tests, right? Hmmm, if that's the case then I have to say that cabal won't suit me very well. Are there any options to cabal? /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus@therning.org Jabber: magnus.therning@gmail.com http://therning.org/magnus -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org/pipermail/haskell-cafe/attachments/20070502/1cb99bcf/attachment.bin From bulat.ziganshin at gmail.com Wed May 2 10:55:42 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Wed May 2 10:56:42 2007 Subject: [Haskell-cafe] Hugs/nhc getting progressively slower In-Reply-To: <404396ef0705020348of75875ew170de36b6b29f7a9@mail.gmail.com> References: <404396ef0705011237xd432910ibb511d5a619917bd@mail.gmail.com> <1178052194.9770.19.camel@localhost> <404396ef0705020348of75875ew170de36b6b29f7a9@mail.gmail.com> Message-ID: <303844825.20070502185542@gmail.com> Hello Neil, Wednesday, May 2, 2007, 2:48:16 PM, you wrote: > the "right answer" always, then I think its a much nicer choice. For > the particular case of ByteString, type ByteString=String means you > roughly import Data.List - not that much additional work or > maintenance. then Binary library want to access ByteString at low level, imports Data.ByteString.Base and discovers that all great low-level functions defined there can't work with lists :) btw, i has the same problem with my Streams/AltBinary lib. once i missed one INLINE pragma and got 200x slower computation even with "ghc -O2"! -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bos at serpentine.com Wed May 2 10:59:54 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Wed May 2 11:00:04 2007 Subject: [Haskell-cafe] ANN: FileManip 0.1, an expressive file manipulationlibrary In-Reply-To: <005601c78c98$2b5c85f0$22418351@cr3lt> References: <46382E8A.1070106@serpentine.com> <46382EF6.8070504@serpentine.com> <005601c78c98$2b5c85f0$22418351@cr3lt> Message-ID: <4638A76A.206@serpentine.com> Claus Reinke wrote: > i have no intention to participate > in yet-another-licencing-discussion, i would just like to ask whether > those limitations of your offering are an accident or intended? I didn't use the LGPL by accident. However, I might be amenable to persuasion, perhaps more so if you climb down from that thing that looks awfully like a high horse from here. References: <46382E8A.1070106@serpentine.com> <46382EF6.8070504@serpentine.com><005601c78c98$2b5c85f0$22418351@cr3lt> <1178096575.9770.45.camel@localhost> <009901c78ca9$16301500$22418351@cr3lt> Message-ID: <4638AA7F.4050503@serpentine.com> Claus Reinke wrote: > if i wanted to use that library > for > anything i want to distribute, my only chance to avoid the source > re-distribution > and advertising clauses would be dynamic linking I believe that the magical protective properties of dynamic linking amount to no more than folklore. So you might not want to bet your proprietary farm on that distinction without first seeking legal advice. > the unix dependency - it could be inherent in > the > design, or an accident of the author's current platform. Unfortunately, the standard libraries do not provide portable ways to check file status. Much of what's currently in the unix library would in fact compile and work fine on Windows, and could usefully be moved from unix to a more portable posix library. Regarding your soapbox, the FileManip library uses Neil Mitchell's new filepath library for precisely the purpose of portable file name handling. References: Message-ID: <4638AFC3.2060003@jellybean.co.uk> Simon Peyton-Jones wrote: > | I like the strong static type system of Haskell for various > | reasons. One reason is, that it makes easier to understand new > | code. I.e. when I read code I type ':t foo' in ghci/hugs from > | time to time, to check my own idea of the type signature, if it > | is not included in the source code. > > The principal difficulties here are to do with "what do we want" rather the implementation challenges. > > 1. Should the compiler print the type of every declaration? Should GHCi allow you to ask the type of a local decl? > IMO, ghci should definitely allow you to ask. This comes up for me every time that I write any haskell code (and in general I end up hoisting local definitions to the top level, which is a real pain if there is local scope, data or type, to hoist with it). > 2. How should the variables be identified? There may be many local bindings for 'f', so you can't say just ":t f". Ditto if dumping all local bindings. > > I think this is a hard question. I was imagining some kind of hierarchical system like foo.f, in the case that f is locally defined inside foo. (Yes I know we can't easily use '.' for that). There might be might be multiple fs inside the definition of foo; indeed there might even be multiple fs nested inside each other. I suspect the happy medium, rather than a formal way of accessing every possible position, is a contextually intelligent system which allows the user to disambiguate. So 'foo.f' will show all the fs inside foo if there are, say, fewer than 5, or otherwise ask for more guidance. > 3. Do you want all locally-bound variables (including those bound by lambda or case), or just letrec/where bound ones? I think 'all', myself, but there are a lot of them. > > All, I think. (It's very common in multiple cases for the same name to be used repeatedly at the same type; this could be conveniently indicated concisely, perhaps). > 4. (This is the trickiest one.) The type of a function may mention type variables bound further out. Consider > f :: [a] -> Int > f xs = let v = head xs in ... > > The type of 'v' is simply 'a'. Not 'forall a. a', but rather 'if xs:[a] then *that* a!' In general there may also be existential type variables bound by an enclosing pattern match too. > I think you're going to have to give the type context, in such cases. (a :: *) |- v : a ... possibly with some way to access information about where the binding site for 'a' is. > These are all user-interface issues. If some people would like to thrash out a design, and put it on the Wiki, I think there is a good chance that someone (possibly even me) would implement it That would be a good idea; my comments above do not a design make though. Can anyone else elaborate further? Jules From claus.reinke at talk21.com Wed May 2 11:36:49 2007 From: claus.reinke at talk21.com (Claus Reinke) Date: Wed May 2 11:34:12 2007 Subject: [Haskell-cafe] ANN: FileManip 0.1, an expressive file manipulationlibrary References: <46382E8A.1070106@serpentine.com> <46382EF6.8070504@serpentine.com><005601c78c98$2b5c85f0$22418351@cr3lt> <4638A76A.206@serpentine.com> Message-ID: <017701c78ccf$b480d750$22418351@cr3lt> >> i have no intention to participate >> in yet-another-licencing-discussion, i would just like to ask whether >> those limitations of your offering are an accident or intended? > > I didn't use the LGPL by accident. However, I might be amenable to > persuasion, perhaps more so if you climb down from that thing that looks > awfully like a high horse from here. no horses here, apart from hobby-horses;-) some people write closed software, some people write freed software, some people write free software. authors choose their licenses, potential users use or stay away. the somewhat pained tone of that email was because this was a library i might have liked to use, hindered by two all too typical issues. licensing is a question i don't want to be drawn into again. it was predictable that some would be tempted to restart that thread (it has been a recurring topic not just in haskell land, but many haskellers have shown themselves flexible enough to converge, on bsd-style short-and-sweet, with about two exceptions -readline and gmp- remaining out of haskellers' control in the main libraries, and more under similar external constraints in gui contexts:-), but as for myself, i only wanted an answer to base my decision on, such as the one you've just given. portability is another matter, because here it has proven a lot easier to avoid non-portable features from the word go than to write for one's most familiar platform first, then worry about porting. where that is not yet possible or easy, those limitations need to be raised, so that they can be worked on, filepath being a recent example. don't put me on a high horse just because i'd prefer another license and am terribly tired of the discussion that tends to raise (i've been there on all sides for hugs/ghc/../programatica/hare/.. !-). claus From rfhayes at reillyhayes.com Wed May 2 12:07:23 2007 From: rfhayes at reillyhayes.com (R Hayes) Date: Wed May 2 12:04:48 2007 Subject: [Haskell-cafe] Cabal, lib and exe in one In-Reply-To: <46385519.1030804@microsoft.com> References: <20070501083404.GD3718@die.therning.org> <1178017338.6211.113.camel@localhost> <20070501212920.GA3838@die.therning.org> <1178062398.9770.31.camel@localhost> <46385519.1030804@microsoft.com> Message-ID: I think Simon is right, and not just from a Haskell point of view. Allowing a package to contain a both a library and an executable makes the behavior of the package system less obvious. That's not to say that it can't behave "correctly", but that it can't behave both "correctly" and in a way that is easy to understand. Yes, it makes installation of an executable package more complicated if you have to install its library package as well. But making this simple should be handled by a layer above the cabal package files (Hackage?). In my experience, the best packaging systems distinguish between dependency assurance and dependency satisfaction. For example, the Debian packaging system has two layers. dpkg deals with package files, installing a single package, and assuring that dependencies are met prior to installation. apt-get retrieves packages from repositories with their pre-reqs (based on the dependency) and invokes dpkg on the retrieved packages. I know the problem is not identical to the one cabal is trying to solve, but I think there is a great deal to be learned by looking at the Debian packaging system and its conventions. In any event, solid naming conventions could go a long way to making this obvious. If foo has a useful exposed library, but primarily consists of an executable, dividing it into foo-bin and foo-lib could serve to clarify. I would propose that, since the bulk of existing packages seem to be libraries, we use a naming convention to distinguish packages that build executables and leave the names of library packages unannotated. -r On May 2, 2007, at 2:08 AM, Simon Marlow wrote: > Duncan Coutts wrote: >> On Tue, 2007-05-01 at 22:29 +0100, Magnus Therning wrote: >>>> So if foo.hs is in test-src and Foo/Bar.hs is in src then I >>>> think you >>>> just need: >>>> >>>> hs-source-dirs: test-src, src >>> No, that's not enough, I also have to add the following lines to >>> make >>> the executable compile and link: >>> >>> extensions: ForeignFunctionInterface >>> c-sources: csrc/ptrace.c >>> >>> That is, I end up compiling the library a second time! Can't I >>> get the >>> executable to link against the library that was just created? >>> I was just expecting to not have to repeat myself in the cabal file. >>> Not such a strange thing to expect from a build system, I think :-) >> Yes this is an interesting question about what it means to have >> programs >> in the same cabal package as an executable. >> Currently having a executable and a library inside a cabal package is >> not the same thing as having a library package and separate >> package that >> contains only that executable. The difference is that when the >> executable is in the same cabal package it merely has access to >> the same >> modules, it doesn't 'depend' on that library package exactly. So for >> example it can access modules which are not exposed by the library >> and >> indeed it can compile those same modules with completely different >> build >> flags. So currently those modules will be built twice. >> It's not clear to me that this is the right meaning, or indeed >> that we >> should allow multiple entries in a single .cabal file. I think it >> might >> be better to just have multiple .cabal files (possibly in the same >> directory). Then we could be explicit and state that an executable >> depends on the library or if we want to use different build flags, or >> use modules that are not exposed by the lib then we can do that >> and only >> in that case do we build those modules twice. > > Right at the front of the Cabal docs it says: > > "However having both a library and executables in a package does > not work very well; if the executables depend on the library, they > must explicitly list all the modules they directly or indirectly > import from that library." > > IMO we shouldn't allow both a library and an exe in the same > package. I think I argued against this originally, and my > understanding is that doing this is deprecated, although perhaps > not visibly enough. Whenever the question of what to do about lib > +exe packages arises, the discussion tends to spiral out of control > into what we should do about collections of packages in general. > > For now, the simple story is that each package should have either a > single library or a single executable (even multiple executables in > a package is questionable; if they share some code it shoud be in a > package). > > Cheers, > Simon > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From kahl at cas.mcmaster.ca Wed May 2 12:16:57 2007 From: kahl at cas.mcmaster.ca (kahl@cas.mcmaster.ca) Date: Wed May 2 12:14:14 2007 Subject: [Haskell-cafe] Displaying infered type signature of 'offside' functions In-Reply-To: <4638AFC3.2060003@jellybean.co.uk> (message from Jules Bean on Wed, 02 May 2007 16:35:31 +0100) References: <4638AFC3.2060003@jellybean.co.uk> Message-ID: <20070502161657.27721.qmail@schroeder.cas.mcmaster.ca> Jules Bean wrote, concerning the problem of getting at the types of local definitions: > Simon Peyton-Jones wrote: > The principal difficulties here are to do with "what do we want" > rather the implementation challenges. > > > 1. Should the compiler print the type of every declaration? Should GHCi allow you to ask the type of a local decl? > > > > IMO, ghci should definitely allow you to ask. This comes up for me every > time that I write any haskell code (and in general I end up hoisting > local definitions to the top level, which is a real pain if there is > local scope, data or type, to hoist with it). > > > 2. How should the variables be identified? There may be many local bindings for 'f', so you can't say just ":t f". Ditto if dumping all local bindings. > > > > > > I think this is a hard question. I was imagining some kind of > hierarchical system like foo.f, in the case that f is locally defined > inside foo. (Yes I know we can't easily use '.' for that). There might > be might be multiple fs inside the definition of foo; indeed there might > even be multiple fs nested inside each other. I just wanted to contribute a PRACTICAL TRICK I use: * If the local definition is a pattern binding f = ... then I just add f :: Ordering * If the local definition is a, say binary, function binding f p1 p2 = ... then I just add f :: Float -> Double -> Ordering (Type does not matter for the number of function arrows you need to put; only the syntactic arity of the bindings matters here.) This relies on the fact that the types Float, Double, and Ordering very rarely occur in my code --- pick your own. Now the compiler gives you wonderful error messages ``cannot match type `x y z' against Ordering'' --- so you replace ``Ordering'' with ``x y z''. If there are type variables in ``x y z'' that come from the context, take care that you have {-# LANGUAGE ScopedTypeVariables #-} at the beginning of your module (after the {-# OPTIONS ...#-} line, which should, as a matter of style, NOT contain -fglasgow-exts ) and the necessary ``forall ty1 ty2 ...'' in front of your the type in the type signature of the enclosing definition. At the cost of a re-compilation, this works wonderfully for me, and is much less painful than hoisting AND exporting local definitions. But even I still have some wishes open: * It would be nice if this worked inside the do-notation, too: do x :: Ordering x <- m (This is curently a syntax error.) * It would be nice if {-# LANGUAGE ScopedTypeVariables #-} brought in no other extensions, and if GHC would recommend the appropriate LANGUAGE pragmas instead of -fglasgow-exts when it determines that the user might have wanted some extension. (What is the right Language.Extension for GADTs?) Wolfram From duncan.coutts at worc.ox.ac.uk Wed May 2 12:22:24 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Wed May 2 12:32:28 2007 Subject: [Haskell-cafe] Cabal, lib and exe in one In-Reply-To: <20070502125853.GC15079@die.therning.org> References: <20070501083404.GD3718@die.therning.org> <1178017338.6211.113.camel@localhost> <20070501212920.GA3838@die.therning.org> <1178062398.9770.31.camel@localhost> <46385519.1030804@microsoft.com> <20070502125853.GC15079@die.therning.org> Message-ID: <1178122944.9770.73.camel@localhost> On Wed, 2007-05-02 at 13:58 +0100, Magnus Therning wrote: > So, you are saying that I should split my library and its test app(s) > into separate packages? That would also mean that I have to install the > library before compiling and running the tests, right? No, I don't think that's very practical at the moment. At the moment I'd just keep it in one .cabal file and just add all the src dirs and .c files etc that you need into each program section. It's not very pretty but it's not completely unwieldy. What we should probably do is make it easier to deal with a collection of packages including registering packages in-place and then it'd become quite practical to have multiple .cabal files, one for each lib and binary in your system. And you'd be able to express the proper dependencies between them. This is the kind of thing that people have been thinking about for a while, but there are some tricky issues and it's also quite a lot of work. > Hmmm, if that's the case then I have to say that cabal won't suit me > very well. Are there any options to cabal? Nothing easy. Duncan From dmhouse at gmail.com Wed May 2 12:45:53 2007 From: dmhouse at gmail.com (David House) Date: Wed May 2 12:43:11 2007 Subject: [Haskell-cafe] Displaying infered type signature of 'offside' functions In-Reply-To: <20070502161657.27721.qmail@schroeder.cas.mcmaster.ca> References: <4638AFC3.2060003@jellybean.co.uk> <20070502161657.27721.qmail@schroeder.cas.mcmaster.ca> Message-ID: On 2 May 2007 16:16:57 -0000, kahl@cas.mcmaster.ca wrote: > * It would be nice if this worked inside the do-notation, too: > > do x :: Ordering > x <- m > > (This is curently a syntax error.) I think the following works with -fglasgow-exts: do (x :: Ordering) <- m -- -David House, dmhouse@gmail.com From kahl at cas.mcmaster.ca Wed May 2 12:51:20 2007 From: kahl at cas.mcmaster.ca (kahl@cas.mcmaster.ca) Date: Wed May 2 12:48:38 2007 Subject: [Haskell-cafe] Displaying infered type signature of 'offside' functions In-Reply-To: (dmhouse@gmail.com) References: <4638AFC3.2060003@jellybean.co.uk> <20070502161657.27721.qmail@schroeder.cas.mcmaster.ca> Message-ID: <20070502165120.27747.qmail@schroeder.cas.mcmaster.ca> > > > * It would be nice if this worked inside the do-notation, too: > > > > do x :: Ordering > > x <- m > > > > (This is curently a syntax error.) > > I think the following works with -fglasgow-exts: > > do (x :: Ordering) <- m I know, but it is not as nice! ;-) Wolfram From list at phaedrusdeinus.org Wed May 2 17:14:12 2007 From: list at phaedrusdeinus.org (John Melesky) Date: Wed May 2 17:12:08 2007 Subject: [Haskell-cafe] Any Haskellers in Chicagoland? Message-ID: <0E443BF0-40CE-4843-911E-81228B5046EC@phaedrusdeinus.org> I'd love to post an ANN: Chicago Haskell user group, but i want to make sure there's more than one of me. -johnnnnnnn From derek.a.elkins at gmail.com Wed May 2 18:31:23 2007 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Wed May 2 18:29:31 2007 Subject: [Haskell-cafe] Displaying infered type signature of 'offside' functions In-Reply-To: <20070502161657.27721.qmail@schroeder.cas.mcmaster.ca> References: <4638AFC3.2060003@jellybean.co.uk> <20070502161657.27721.qmail@schroeder.cas.mcmaster.ca> Message-ID: <4639113B.6030904@gmail.com> kahl@cas.mcmaster.ca wrote: > Jules Bean wrote, > concerning the problem of getting at the types of local definitions: > > > Simon Peyton-Jones wrote: > > The principal difficulties here are to do with "what do we want" > > rather the implementation challenges. > > > > > 1. Should the compiler print the type of every declaration? Should GHCi allow you to ask the type of a local decl? > > > > > > > IMO, ghci should definitely allow you to ask. This comes up for me every > > time that I write any haskell code (and in general I end up hoisting > > local definitions to the top level, which is a real pain if there is > > local scope, data or type, to hoist with it). > > > > > 2. How should the variables be identified? There may be many local bindings for 'f', so you can't say just ":t f". Ditto if dumping all local bindings. > > > > > > > > > > I think this is a hard question. I was imagining some kind of > > hierarchical system like foo.f, in the case that f is locally defined > > inside foo. (Yes I know we can't easily use '.' for that). There might > > be might be multiple fs inside the definition of foo; indeed there might > > even be multiple fs nested inside each other. > > > I just wanted to contribute a PRACTICAL TRICK I use: > > > * If the local definition is a pattern binding > > f = ... > > then I just add > > f :: Ordering > > * If the local definition is a, say binary, function binding > > f p1 p2 = ... > > then I just add > > f :: Float -> Double -> Ordering > > (Type does not matter for the number of function arrows you need to put; > only the syntactic arity of the bindings matters here.) > > > This relies on the fact that the types Float, Double, and Ordering > very rarely occur in my code --- pick your own. Why not just declare a type you don't use? From stefanor at cox.net Wed May 2 18:39:20 2007 From: stefanor at cox.net (Stefan O'Rear) Date: Wed May 2 18:36:37 2007 Subject: [Haskell-cafe] Displaying infered type signature of 'offside' functions In-Reply-To: <20070502161657.27721.qmail@schroeder.cas.mcmaster.ca> References: <4638AFC3.2060003@jellybean.co.uk> <20070502161657.27721.qmail@schroeder.cas.mcmaster.ca> Message-ID: <20070502223920.GA2987@localhost.localdomain> On Wed, May 02, 2007 at 04:16:57PM -0000, kahl@cas.mcmaster.ca wrote: > Now the compiler gives you wonderful error messages > ``cannot match type `x y z' against Ordering'' --- > so you replace ``Ordering'' with ``x y z''. You could just use a rigid type variable: foo :: a foo = ... > (What is the right Language.Extension for GADTs?) There is none. Stefan From ajb at spamcop.net Wed May 2 21:55:00 2007 From: ajb at spamcop.net (ajb@spamcop.net) Date: Wed May 2 21:52:15 2007 Subject: FW: [Haskell-cafe] RE:Cross-over from Haskell.org [Haskell] Re: Newbie: what are the advantages of Haskell? In-Reply-To: <1178105866.24254.15.camel@localhost.localdomain> References: <1178105866.24254.15.camel@localhost.localdomain> Message-ID: <20070502215500.fikw8kk8wogcswwc@webmail.spamcop.net> G'day all. Quoting "Michael T. Richter" : > Ummm... Udo? Just what the fuck did you hope to accomplish with this > kind of talk? Guys, could we keep it civil on the list, please? And for the record: http://www.perl.com/pub/2000/12/advocacy.html Cheers, Andrew Bromage From dons at cse.unsw.edu.au Wed May 2 22:04:28 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Wed May 2 22:01:47 2007 Subject: FW: [Haskell-cafe] RE:Cross-over from Haskell.org [Haskell] Re: Newbie: what are the advantages of Haskell? In-Reply-To: <20070502215500.fikw8kk8wogcswwc@webmail.spamcop.net> References: <1178105866.24254.15.camel@localhost.localdomain> <20070502215500.fikw8kk8wogcswwc@webmail.spamcop.net> Message-ID: <20070503020428.GF30455@cse.unsw.EDU.AU> ajb: > G'day all. > > Quoting "Michael T. Richter" : > > > Ummm... Udo? Just what the fuck did you hope to accomplish with this > > kind of talk? > > Guys, could we keep it civil on the list, please? > > And for the record: > > http://www.perl.com/pub/2000/12/advocacy.html > I'd like to second Andrew here. This is really not appropriate for a Haskell list -- in fact, its pretty much a first I think :/ Please keep it friendly guys ! -- Don P.S. we have some other resources on actively building and maintaining a community here: http://haskell.org/haskellwiki/Protect_the_community From ajb at spamcop.net Wed May 2 23:21:35 2007 From: ajb at spamcop.net (ajb@spamcop.net) Date: Wed May 2 23:18:51 2007 Subject: [Haskell-cafe] Bloom Filter In-Reply-To: References: <83d2d2f80704300727q1265cc62sf3505f42d52b59ad@mail.gmail.com> <20070430223928.qe70ggo4soss8sgw@webmail.spamcop.net> Message-ID: <20070502232135.3lhwsswg4cssc80o@webmail.spamcop.net> G'day all. Quoting Henning Thielemann : > Why replacing the almost-function 'if' by a special syntactic construct? In a sense, this is entirely stylistic. One works just as well as the other. But I think it's superior in this case (obviously not all cases) because this is at the top-level (i.e. on the RHS of a top-level function definition), and one "arm" of the if-then-else is a call to "error", that is, a precondition/domain/sanity check. These pre-checks are almost always different from the "real" business that the function performs. Using guards makes the separation that much more obvious. Cheers, Andrew Bromage From vvv at umc.com.ua Thu May 3 10:11:50 2007 From: vvv at umc.com.ua (Valery V. Vorotyntsev) Date: Thu May 3 10:09:05 2007 Subject: [Haskell-cafe] 'Proper' use of the State monad In-Reply-To: <608932c00704301416i39543a2bg2dd677004dd06ffe@mail.gmail.com> (Denis Volk's message of "Mon, 30 Apr 2007 23:16:47 +0200") References: <608932c00704301416i39543a2bg2dd677004dd06ffe@mail.gmail.com> Message-ID: <871whydmjd.fsf@umc.com.ua> "Denis Volk" writes: > I am trying to make a (turn-based) game in Haskell and need to pass > around quite a bit of information, so using the State monad seems most > appropriate. My question is, which is a better idea: Have you read `Theseus and the Zipper'[1] yet? 1. http://en.wikibooks.org/wiki/Haskell/Zippers -vvv From nominolo at googlemail.com Thu May 3 10:15:03 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Thu May 3 10:12:27 2007 Subject: [Haskell-cafe] Listing package dependencies from GHC In-Reply-To: <2d3641330704270311p737c9324u5968f1998093af38@mail.gmail.com> References: <2d3641330704270311p737c9324u5968f1998093af38@mail.gmail.com> Message-ID: > If I'm doing development between ghci and vim, all the different > dependencies I need get linked in when required without me asking. > Similarly if I call "ghc --make" from the command line. But I have to > write them in manually to my *.cabal file otherwise the compilation > process will fail. > > Until now I've just loaded the program in to ghci and noted down all > the dependencies it links in. Am I missing a trick? There must be an > easier way, especially for multiple source files. I once used this perl script to determine the files I was actually used (to have proper LOC stats). It uses ghc -M which usually outputs the dependencies as makefile targets, and then grep over this to get all the .hs files. If you have different file types you might want to modify this: #!/usr/bin/env perl # Prints the .hs files that are actually used to STDOUT $tmpfile = '/tmp/deps'; $mainfile = 'Foo.hs'; $ghc_deps = `ghc -M $mainfile -optdep-f -optdep$tmpfile`; die "ghc -M failed\n" if $? != 0; open(INF, "< $tmpfile") || die "Could not open $tempfile\n"; @files = (); while () { m/(\w+\.hs)/; push(@files, $1); } close (INF); undef %saw; @nodups = grep(!$saw{$_}++, @files); # remove duplictes print join(' ',@nodups), "\n"; From mempko at gmail.com Thu May 3 10:35:18 2007 From: mempko at gmail.com (Maxim Khailo) Date: Thu May 3 10:33:07 2007 Subject: [Haskell-cafe] Re: Any Haskellers in Chicagoland? In-Reply-To: <0E443BF0-40CE-4843-911E-81228B5046EC@phaedrusdeinus.org> References: <0E443BF0-40CE-4843-911E-81228B5046EC@phaedrusdeinus.org> Message-ID: John Melesky wrote: > I'd love to post an ANN: Chicago Haskell user group, but i want to make > sure there's more than one of me. > > -johnnnnnnn Hey, I am a new haskeller in chicago. I would certainly join a user group. -max From ithika at gmail.com Thu May 3 10:35:57 2007 From: ithika at gmail.com (Dougal Stanton) Date: Thu May 3 10:33:13 2007 Subject: [Haskell-cafe] Listing package dependencies from GHC In-Reply-To: References: <2d3641330704270311p737c9324u5968f1998093af38@mail.gmail.com> Message-ID: <2d3641330705030735q7d1cd848lf99e5df9163f434f@mail.gmail.com> On 03/05/07, Thomas Schilling wrote: > > I once used this perl script to determine the files I was actually > used (to have proper LOC stats). It uses ghc -M which usually > outputs the dependencies as makefile targets, and then grep over this > to get all the .hs files. If you have different file types you might > want to modify this: Sorry, maybe I didn't express myself properly. By dependencies I meant, library packages that GHC knows about. For example, if I load something simple like > import System.Posix.Files > main = touchFile "example" into GHCi and execute ":main" it prints > Loading package unix-1.0 ... linking ... done. But if I try the same by compiling with a ./Setup build (ie cabal) the build system complains that it "could not find X, it is a member of unix". My problem is that the only way I can get from a template cabal file to a fully working one is by iteration - add dependency to "Build-depends", recompile, fail, repeat. It's obvious GHC knows how to find all the right dependencies. It does it in GHCi. It can even be done from the command line with "--make". But can I get it to *tell* me the information that cabal needs? Cheers, Dougal. From nominolo at googlemail.com Thu May 3 10:49:55 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Thu May 3 10:47:32 2007 Subject: [Haskell-cafe] Listing package dependencies from GHC In-Reply-To: <2d3641330705030735q7d1cd848lf99e5df9163f434f@mail.gmail.com> References: <2d3641330704270311p737c9324u5968f1998093af38@mail.gmail.com> <2d3641330705030735q7d1cd848lf99e5df9163f434f@mail.gmail.com> Message-ID: > By dependencies I > meant, library packages that GHC knows about. > > For example, if I load something simple like > >> import System.Posix.Files >> main = touchFile "example" > > into GHCi and execute ":main" it prints > >> Loading package unix-1.0 ... linking ... done. > Oh, right. Well, then please file it as a bug report on Cabal. I'll be working on Cabal configs as my Summer of Code project; this is clearly related. With a bit of luck it'll be done before end of August. / Thomas From ithika at gmail.com Thu May 3 10:58:18 2007 From: ithika at gmail.com (Dougal Stanton) Date: Thu May 3 10:55:37 2007 Subject: [Haskell-cafe] Listing package dependencies from GHC In-Reply-To: References: <2d3641330704270311p737c9324u5968f1998093af38@mail.gmail.com> <2d3641330705030735q7d1cd848lf99e5df9163f434f@mail.gmail.com> Message-ID: <2d3641330705030758q3789fa5esb204b2616539376@mail.gmail.com> On 03/05/07, Thomas Schilling wrote: > Oh, right. Well, then please file it as a bug report on Cabal. I'll > be working on Cabal configs as my Summer of Code project; this is > clearly related. With a bit of luck it'll be done before end of August. Okay. It seemed like a feature, but just one that made things more difficult than they could be. D. From duncan.coutts at worc.ox.ac.uk Thu May 3 11:53:01 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Thu May 3 12:02:59 2007 Subject: [Haskell-cafe] Listing package dependencies from GHC In-Reply-To: References: <2d3641330704270311p737c9324u5968f1998093af38@mail.gmail.com> <2d3641330705030735q7d1cd848lf99e5df9163f434f@mail.gmail.com> Message-ID: <1178207581.9770.123.camel@localhost> On Thu, 2007-05-03 at 16:49 +0200, Thomas Schilling wrote: > > By dependencies I > > meant, library packages that GHC knows about. > > > > For example, if I load something simple like > > > >> import System.Posix.Files > >> main = touchFile "example" > > > > into GHCi and execute ":main" it prints > > > >> Loading package unix-1.0 ... linking ... done. > > > > Oh, right. Well, then please file it as a bug report on Cabal. I'll > be working on Cabal configs as my Summer of Code project; this is > clearly related. With a bit of luck it'll be done before end of August. This is not a Cabal bug. By design, Cabal does not just pick up any packages from the environment like --make does. One of the main points of Cabal is to be able to explicitly track dependencies of a package, so we do require that they all be listed explicitly. Cabal then tells ghc to *only* look in those listed packages and ignore all others even if they happen to be installed. Now certainly it would be nicer if ghc+cabal could be more helpful and tell you all the missing packages that you need to list in the "build-depends" field in the .cabal file, rather than currently where you have to do it one by one. This feature could be implemented in GHC, or it could actually be implemented in Cabal. To do it in cabal requires that cabal gain an infrastructure for doing dependency analysis of modules. We don't have that yet. We do need this infrastructure anyway though, since for example some pre-processors (notably c2hs) need to be called in dependency order. It would also allow other nice things like having cabal work out for you exactly which pre-processors and build tools are required, and make partial and parallel rebuilds possible. I'm not sure that's in scope for this SoC project but if anyone wants to volunteer to look at this project then that'd be a great service to the community. There's quite a bit of existing code to look at, in ghc, yhc, jhc and hmake which already do some kind of dependency chasing. We'd need that plus make it extensible to arbitrary pre-processors (eg using suffix rules, .y -> .hs, .hs.pp -> .hs) Duncan From jmvilaca at di.uminho.pt Thu May 3 12:47:17 2007 From: jmvilaca at di.uminho.pt (=?iso-8859-1?Q?Jos=E9_Miguel_Vila=E7a?=) Date: Thu May 3 12:44:36 2007 Subject: [Haskell-cafe] outputing .hs file without comments Message-ID: <20070503164434.71B1D32420C@www.haskell.org> Hi all, Is there a simple tool or command to remove all comments from a Haskell file, i.e. something that outputs the input file but without any comments on it? Best Miguel Vila?a -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20070503/53c5b96e/attachment.htm From sciolizer at gmail.com Thu May 3 13:26:33 2007 From: sciolizer at gmail.com (Joshua Ball) Date: Thu May 3 13:23:56 2007 Subject: [Haskell-cafe] Any Haskellers in Chicagoland? Message-ID: <92fdc3450705031026o64a2f2a2x82c66ee386e49f1c@mail.gmail.com> > I'd love to post an ANN: Chicago Haskell user group, but i want to > make sure there's more than one of me. > > -johnnnnnnn I live in the Northwest Suburbs of Chicago (specifically Wheaton), and I would LOVE to join a Chicago Haskell user group. From nominolo at googlemail.com Thu May 3 15:39:49 2007 From: nominolo at googlemail.com (Thomas Schilling) Date: Thu May 3 15:37:08 2007 Subject: [Haskell-cafe] Listing package dependencies from GHC In-Reply-To: <1178207581.9770.123.camel@localhost> References: <2d3641330704270311p737c9324u5968f1998093af38@mail.gmail.com> <2d3641330705030735q7d1cd848lf99e5df9163f434f@mail.gmail.com> <1178207581.9770.123.camel@localhost> Message-ID: On 3 maj 2007, at 17.53, Duncan Coutts wrote: > This is not a Cabal bug. By design, Cabal does not just pick up any > packages from the environment like --make does. One of the main points > of Cabal is to be able to explicitly track dependencies of a > package, so > we do require that they all be listed explicitly. Cabal then tells ghc > to *only* look in those listed packages and ignore all others even if > they happen to be installed. > > Now certainly it would be nicer if ghc+cabal could be more helpful and > tell you all the missing packages that you need to list in the > "build-depends" field in the .cabal file, rather than currently where > you have to do it one by one. In fact I was thinking of something more than this. When I said "file a bug" I didn't intend to describe it as a bug but as a feature, which are also managed by the bug tracker. Also, I agree that dependencies should be listed explicitly; it might be very useful to let Cabal generate you a template with some sane suggestions, though. / Thomas From dons at cse.unsw.edu.au Thu May 3 20:33:07 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Thu May 3 20:30:29 2007 Subject: [Haskell-cafe] outputing .hs file without comments In-Reply-To: <20070503164434.71B1D32420C@www.haskell.org> References: <20070503164434.71B1D32420C@www.haskell.org> Message-ID: <20070504003307.GA31335@cse.unsw.EDU.AU> jmvilaca: > > Hi all, > > > Is there a simple tool or command to remove all comments > from a Haskell file, i.e. something that outputs the input > file but without any comments on it? Using Language.Haskell, such a program is almost trivial: -- -- strip comments from haskell source -- {- the main module -} import Language.Haskell.Parser import Language.Haskell.Pretty main = interact $ \s -> case parseModule s of ParseFailed loc str -> (show loc) ++ "\n" ParseOk m -> (prettyPrint m) ++ "\n" And running this program on itself: $ runhaskell A.hs < A.hs module Main (main) where import Language.Haskell.Parser import Language.Haskell.Pretty main = interact $ \ s -> case parseModule s of ParseFailed loc str -> (show loc) ++ "\n" ParseOk m -> (prettyPrint m) ++ "\n" Hehe, it also pretty prints :-) -- Don From dons at cse.unsw.edu.au Thu May 3 20:57:06 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Thu May 3 20:54:21 2007 Subject: [Haskell-cafe] "Programming in Haskell" made it to RegDeveloper Message-ID: <20070504005706.GC31335@cse.unsw.EDU.AU> http://www.regdeveloper.co.uk/2007/05/03/programming_haskell/ Mmm... mainstream exposure. -- Don From aneumann at inf.fu-berlin.de Fri May 4 03:43:35 2007 From: aneumann at inf.fu-berlin.de (Adrian Neumann) Date: Fri May 4 03:37:42 2007 Subject: [Haskell-cafe] The Trivial Monad Message-ID: <463AE427.3040809@inf.fu-berlin.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I've read this blogpost about the "trivial monad" http://sigfpe.blogspot.com/2007/04/trivial-monad.html, because I still don't understand what this monad thingy is all about. The author defines three functions: data W a = W a deriving Show return :: a -> W a return x = W x fmap :: (a -> b) -> (W a -> W b) fmap f (W x) = W (f x) bind :: (a -> W b) -> (W a -> W b) bind f (W x) = f x and asks the reader to prove the tree monad laws for them. However I don't understand the type signatures for bind and fmap. I'd say (and ghci's type inference agrees) that bind and fmap have the type bind:: (a->W b) -> W a -> W b fmap:: (a->b) -> W a -> W b They take a function f and something and return what f does to that. I don't see why they should return a function. This of course makes it hard for me to prove the monad laws. The first however works nonetheless: 1) bind f (return a)= f a => bind f (return a)= bind f (W a) = f a Can someone explain bind and fmap (and possible law 2 and 3)? Thanks, Adrian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGOuQS11V8mqIQMRsRCmngAJ9NwQMwXeS/PSM1NUsVA8gxPuA0KACfSLiA ItqRZW5a4XyQ099bhMtSWmU= =/8i/ -----END PGP SIGNATURE----- From tom.davie at gmail.com Fri May 4 03:52:17 2007 From: tom.davie at gmail.com (Thomas Davie) Date: Fri May 4 03:49:50 2007 Subject: [Haskell-cafe] The Trivial Monad In-Reply-To: <463AE427.3040809@inf.fu-berlin.de> References: <463AE427.3040809@inf.fu-berlin.de> Message-ID: On 4 May 2007, at 08:43, Adrian Neumann wrote: > However I > don't understand the type signatures for bind and fmap. I'd say (and > ghci's type inference agrees) that bind and fmap have the type > > bind:: (a->W b) -> W a -> W b > fmap:: (a->b) -> W a -> W b > > They take a function f and something and return what f does to that. I > don't see why they should return a function. I suggest you look up currying. In the mean time, I shall attempt an explanation. In Haskell (as in many other functional languages), function types appear as if the function were curried. This means that a function accepts one single argument, and returns one single result. The important thing to realise though is that the result (or less importantly the argument) may be a function. Let's study a (slightly over constrained) variant on the (+) function, with type (+) :: Int -> Int -> Int. This type signature should be read to mean: (+) takes an Int, and returns a new function of type (Int -> Int). We can see an example of this (+ 5) -- (+) is given an argument (5), and returns a function (that adds 5 to integers). Another way to think about it is that the (->) type constructor is right associative, so any type written as a -> b -> c -> d -> e, can also be written as a -> (b -> (c -> (d -> e))). I hope that helped a bit, and if it didn't I suggest going and looking up currying in as many places as you can. Bob -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20070504/00492c47/attachment.htm From mvanier at cs.caltech.edu Fri May 4 03:55:28 2007 From: mvanier at cs.caltech.edu (Michael Vanier) Date: Fri May 4 03:52:53 2007 Subject: [Haskell-cafe] The Trivial Monad In-Reply-To: <463AE427.3040809@inf.fu-berlin.de> References: <463AE427.3040809@inf.fu-berlin.de> Message-ID: <463AE6F0.30709@cs.caltech.edu> The -> in type signatures associates to the right, so the type signatures > fmap :: (a -> b) -> (W a -> W b) > bind :: (a -> W b) -> (W a -> W b) are the same as: > fmap :: (a -> b) -> W a -> W b > bind :: (a -> W b) -> W a -> W b Sometimes people put in the extra parentheses because they want to emphasize a particular way to use the function. I'm assuming you understand that a function that takes two arguments and returns a (possibly non-function) value is equivalent to a function that takes one argument that returns a function that takes the other argument and returns a value. HTH, Mike Adrian Neumann wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > I've read this blogpost about the "trivial monad" > http://sigfpe.blogspot.com/2007/04/trivial-monad.html, because I still > don't understand what this monad thingy is all about. > > The author defines three functions: > > data W a = W a deriving Show > > return :: a -> W a > return x = W x > > fmap :: (a -> b) -> (W a -> W b) > fmap f (W x) = W (f x) > > bind :: (a -> W b) -> (W a -> W b) > bind f (W x) = f x > > and asks the reader to prove the tree monad laws for them. However I > don't understand the type signatures for bind and fmap. I'd say (and > ghci's type inference agrees) that bind and fmap have the type > > bind:: (a->W b) -> W a -> W b > fmap:: (a->b) -> W a -> W b > > They take a function f and something and return what f does to that. I > don't see why they should return a function. > > This of course makes it hard for me to prove the monad laws. The first > however works nonetheless: > > 1) bind f (return a)= f a > > => bind f (return a)= bind f (W a) = f a > > Can someone explain bind and fmap (and possible law 2 and 3)? > > Thanks, > > Adrian > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFGOuQS11V8mqIQMRsRCmngAJ9NwQMwXeS/PSM1NUsVA8gxPuA0KACfSLiA > ItqRZW5a4XyQ099bhMtSWmU= > =/8i/ > -----END PGP SIGNATURE----- > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe From eilya497 at 013.net Fri May 4 07:42:53 2007 From: eilya497 at 013.net (Ilya Tsindlekht) Date: Fri May 4 07:40:00 2007 Subject: [Haskell-cafe] Monad definition question Message-ID: <20070504114253.GA24244@localhost> Does the definition of monad silently assume that if f and f' are equal in the sense that they return the same value for any argument o correct type then m >>= f = m >>= f' More specifically, the definition says x >>= return = x. How does one justify from this that x >>= (return . id) = x? Are values of type a -> b in general assumed to be maps from the set of values of type a into the set ov values of type b? (What bothers me is that the problem whether two lambda-expressions define the same map is clearly undecidable.) More generally, is some kind of logic without equality more appropriate for formalisation of Haskell then the usual kind(s) of logic with equality? From greenrd at greenrd.org Fri May 4 08:01:37 2007 From: greenrd at greenrd.org (Robin Green) Date: Fri May 4 08:07:18 2007 Subject: [Haskell-cafe] Monad definition question In-Reply-To: <20070504114253.GA24244@localhost> References: <20070504114253.GA24244@localhost> Message-ID: <20070504130137.1c1ef80f@greenrd.ucd.ie> On Fri, 04 May 2007 14:42:53 +0300 Ilya Tsindlekht wrote: > Does the definition of monad silently assume that if f and f' are > equal in the sense that they return the same value for any argument o > correct type then m >>= f = m >>= f' How could it be otherwise? How are you going to distinguish between f and f' if they are indistinguishable functions, in Haskell? > More specifically, the definition says x >>= return = x. How does one > justify from this that x >>= (return . id) = x? > > Are values of type a -> b in general assumed to be maps from the set > of values of type a into the set ov values of type b? Yes - if _|_ is considered to be a value. > (What bothers > me is that the problem whether two lambda-expressions define the same > map is clearly undecidable.) Yes. But this is a fundamental mathematical issue which isn't at all specific to Haskell, of course. It suggests using some sort of intensional type theory, so that you have to explicitly prove lambda expressions to be equal. > More generally, is some kind of logic without equality more > appropriate for formalisation of Haskell then the usual kind(s) of > logic with equality? I suggest you look into Observational Type Theory. -- Robin From frederik at a5.repetae.net Fri May 4 10:01:27 2007 From: frederik at a5.repetae.net (Frederik Eaton) Date: Fri May 4 09:59:04 2007 Subject: [Haskell-cafe] outputing .hs file without comments In-Reply-To: <20070504003307.GA31335@cse.unsw.EDU.AU> References: <20070503164434.71B1D32420C@www.haskell.org> <20070504003307.GA31335@cse.unsw.EDU.AU> Message-ID: <20070504140127.GA25674@a5.repetae.net> Is it possible to use Language.Haskell to print a program with comments preserved? That might be useful for refactoring. Not that Language.Haskell isn't already cool enough, if the answer is "no", of course. Frederik On Fri, May 04, 2007 at 10:33:07AM +1000, Donald Bruce Stewart wrote: > jmvilaca: > > > > Hi all, > > > > > > Is there a simple tool or command to remove all comments > > from a Haskell file, i.e. something that outputs the input > > file but without any comments on it? > > Using Language.Haskell, such a program is almost trivial: > > -- > -- strip comments from haskell source > -- > > {- the main module -} > > import Language.Haskell.Parser > import Language.Haskell.Pretty > > main = interact $ \s -> case parseModule s of > ParseFailed loc str -> (show loc) ++ "\n" > ParseOk m -> (prettyPrint m) ++ "\n" > > And running this program on itself: > > $ runhaskell A.hs < A.hs > module Main (main) where > import Language.Haskell.Parser > import Language.Haskell.Pretty > main > = interact $ > \ s -> > case parseModule s of > ParseFailed loc str -> (show loc) ++ "\n" > ParseOk m -> (prettyPrint m) ++ "\n" > > > Hehe, it also pretty prints :-) > > -- Don > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- http://ofb.net/~frederik/ From jgoerzen at complete.org Fri May 4 09:36:11 2007 From: jgoerzen at complete.org (John Goerzen) Date: Fri May 4 10:05:43 2007 Subject: [Haskell-cafe] Hugs dropped Text.Regex?! Message-ID: I learned today, as I tried to run my ftphs unit tests under Hugs, that Hugs dropped Text.Regex between 200503.08 and 200609.21. The Hugs download page claims that they did this because the new GHC implementation of Text.Regex is not compatible with Hugs. But why can't Hugs keep the old implementation? This is going to render Hugs just about useless for me. I like regexps. -- John From haskell at list.mightyreason.com Fri May 4 11:07:05 2007 From: haskell at list.mightyreason.com (Chris Kuklewicz) Date: Fri May 4 11:04:27 2007 Subject: [Haskell-cafe] Hugs dropped Text.Regex?! In-Reply-To: References: Message-ID: <463B4C19.90904@list.mightyreason.com> John Goerzen wrote: > I learned today, as I tried to run my ftphs unit tests under Hugs, that > Hugs dropped Text.Regex between 200503.08 and 200609.21. > > The Hugs download page claims that they did this because the new GHC > implementation of Text.Regex is not compatible with Hugs. > > But why can't Hugs keep the old implementation? > > This is going to render Hugs just about useless for me. I like regexps. > > -- John I will explain how to setup Text.Regex.* for Hugs (I hope)... I have not been using Hugs, but I have created the current Text.Regex code in use by GHC. The stable regex-base package that comes with GHC 6.6 and 6.6.1 has instances (of RegexContext) that depend on GHC's late resolution of overlapping instances. Hugs can only use that with some instanes removed (via the preprocessor). The unstable regex-base package you can get with darcs is version 0.91 from http://darcs.haskell.org/packages/regex-unstable/regex-base/ has been modified to use a few newtypes to allow both GHC and Huge to use all the instances. >From there you want a backend. The old backend use the local regex.h api from the c library and is in the regex-posix version 0.92 package at http://darcs.haskell.org/packages/regex-unstable/regex-posix/ To get the old haskell API to this backend (Text.Regex itself) you need regex-compat version 0.90 at http://darcs.haskell.org/packages/regex-unstable/regex-compat/ To get the new pure haskell backend (works better in almost all cases) you need regex-tda at http://darcs.haskell.org/packages/regex-unstable/regex-tdfa/ Note that this regex-tdfa is the latest version, 0.93, which now has the patch that Ross Paterson sent to me and makes it Hugs compatible. So it is broken up into several smaller packages. I think all but regex-tdfa-0.93 are also available from http://hackage.haskell.org/packages/archive/pkg-list.html#cat:Text Cheers, Chris From dpiponi at gmail.com Fri May 4 12:47:49 2007 From: dpiponi at gmail.com (Dan Piponi) Date: Fri May 4 12:45:00 2007 Subject: [Haskell-cafe] The Trivial Monad In-Reply-To: <463AE427.3040809@inf.fu-berlin.de> References: <463AE427.3040809@inf.fu-berlin.de> Message-ID: <625b74080705040947u4985d755l9573b0afae173307@mail.gmail.com> Hi Adrian, > They take a function f and something and return what f does to that. I > don't see why they should return a function. Consider a function, f, that takes two arguments, one of type A, and one of type B, and returns something of type C. In conventional mathematical notation this would be written as f : A x B -> C. Think about what this function does from a practical point of view. It waits to be handed an object of type A. It then waits for an object of type B. And now it can return an object of type C. But suppose we hand f an object of type A, but not another of type B. What do we get? Well we basically have something that's still waiting for an object of type B, and when it gets that it'll return an object of type C. Something that's waiting for a B in order to give you a C is of type B->C. So after you've given f an A, you get back a B->C. So f can be thought of as being of type A->(B->C). So there are two ways of thinking of f. (1) A function that takes an A and a B and gives you a C. Or (2) a function that takes an A and gives you back a function mapping a B to a C. Haskell blurs the distinction between these things and the transition from view (1) to view (2) is called 'currying'. Internally, the Haskell parser automatically converts A->B->C to A->(B->C) so you can view the former as simply being shorthand for the latter. (In CS-speak '->' is considered to be right associative but that's just another way of saying the same thing.) -- Dan From bulat.ziganshin at gmail.com Fri May 4 12:02:07 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Fri May 4 12:59:02 2007 Subject: [Haskell-cafe] The Trivial Monad In-Reply-To: <463AE427.3040809@inf.fu-berlin.de> References: <463AE427.3040809@inf.fu-berlin.de> Message-ID: <1228333000.20070504200207@gmail.com> Hello Adrian, Friday, May 4, 2007, 11:43:35 AM, you wrote: > don't understand what this monad thingy is all about. the whole monadic business was introduced with the sole goal to let haskellers believe that they are smarter than other programmers :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From derek.a.elkins at gmail.com Fri May 4 13:03:59 2007 From: derek.a.elkins at gmail.com (Derek Elkins) Date: Fri May 4 13:01:59 2007 Subject: [Haskell-cafe] The Trivial Monad In-Reply-To: <1228333000.20070504200207@gmail.com> References: <463AE427.3040809@inf.fu-berlin.de> <1228333000.20070504200207@gmail.com> Message-ID: <463B677F.206@gmail.com> Bulat Ziganshin wrote: > Hello Adrian, > > Friday, May 4, 2007, 11:43:35 AM, you wrote: > >> don't understand what this monad thingy is all about. > > the whole monadic business was introduced with the sole goal to let > haskellers believe that they are smarter than other programmers :) Indeed. Continuation-based IO would have been so much clearer. From Phlex at telenet.be Fri May 4 13:23:16 2007 From: Phlex at telenet.be (Phlex) Date: Fri May 4 13:20:26 2007 Subject: [Haskell-cafe] [IO Int] -> IO [Int] Message-ID: <463B6C04.4010401@telenet.be> Hello all, I'm trying to learn haskell, so here's is my first newbie question. I hope this list is appropriate for such help requests. I'm trying to write a function with the signature [IO Int] -> IO [Int] Here is my first attempt : conv :: [IO Int] -> IO [Int] conv l = do val <- (head l) return (val : (c