[Haskell-cafe] Pattern matching on lazy bytestrings: how does it work?
I noticed today that I can pattern match against lazy bytestrings when using the OverloadedStrings extension: import Data.ByteString.Char8 () import Data.ByteString.Lazy.Char8 f :: ByteString - Bool f abc = True f _ = False main = do print $ f $ fromChunks [abc] print $ f $ fromChunks [a,bc] When I run the above, I get: True True Given that pattern matching is based on data constructors, how is it possible that (Chunk abc Empty) and (Chunk a (Chunk bc Empty)) match the same pattern? Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pattern matching on lazy bytestrings: how does it work?
Surely `fromChunks` is making the both lines in the code snippet the same? Also, in your last sentence I think you've miscalculated the shape of the initial input. Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pattern matching on lazy bytestrings: how does it work?
On Fri, Apr 22, 2011 at 11:52:32PM -0700, Tom Brow wrote: I noticed today that I can pattern match against lazy bytestrings when using the OverloadedStrings extension: [..] Given that pattern matching is based on data constructors, how is it possible that (Chunk abc Empty) and (Chunk a (Chunk bc Empty)) match the same pattern? Tom According to the haskell report[1] string literals use the overloaded (==) for pattern matching. Matching a numeric, character, or string literal pattern k against a value v succeeds if v == k, where == is overloaded based on the type of the pattern. The match diverges if this test diverges. [1]: http://www.haskell.org/onlinereport/exps.html#sect3.17.2 -- Helgi Kristvin Sigurbjarnarson helgikrs (at) gmail (dot) com pgpu1kqNpXfhn.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Leksah 0.10.0
Hi Hamish, Am Freitag, den 22.04.2011, 22:40 +1200 schrieb Hamish Mackenzie: Yesterday we uploaded our official 0.10.0 release (0.10.0.4) to Hackage and we have Windows and OS X installers at http://leksah.org/download.html I am checking what is to be done to get this new release into Debian, and I notice quite a few changes to the dependencies, including some duplication of existing libraries (haddock-leksah, haddock-process). That is something we would definitely like to avoid in Debian. Can you tell us why exactly you need different packages, e.g. a link to the bug report where you ask for inclusion of your changes? Ideally, we would in Debian incorporate your changes in the Debian package of process or haddock, but of course only if they are reviewed by upstream and will eventually be merged. Also, is there a chance that the features of binary-shared will be merged into binary eventually? Thanks, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: iteratee-compress 0.2.0.0
Iteratee-compress provides compressing and decompressing enumerators including flushing (using John Lato's implementation). Currently only gzip and bzip is provided but LZMA is planned. Changes from previous version: - Add BZip support Next goals: - LZMA support - Generic interface for flushing To think about: - Should inner iteratee be able to request flushing Regards signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
David Terei wrote: Good chance you've already read this but if not here is a good post by Linus about his take on the problems with darcs: http://markmail.org/message/vk3gf7ap5auxcxnb I always have to smile at the complaint that something is academic. :D You know, like purely functional programming, that's soo academic. It's centered around some academic ideas, like mathematical functions, higher-rank types, monads and zygohistomorphic prepromorphisms, that have absolutely no relevance in real life, and that just don't work in practice. You do *not* want to write whole programs that way. At some point, you need something that works at another level than pure functions. What the *hell* do you do? I think a better invective would be amazing. Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Leksah 0.10.0
On 23 Apr 2011, at 21:48, Joachim Breitner wrote: I am checking what is to be done to get this new release into Debian, and I notice quite a few changes to the dependencies, including some duplication of existing libraries (haddock-leksah, haddock-process). That is something we would definitely like to avoid in Debian. Can you tell us why exactly you need different packages, e.g. a link to the bug report where you ask for inclusion of your changes? Ideally, we would in Debian incorporate your changes in the Debian package of process or haddock, but of course only if they are reviewed by upstream and will eventually be merged. Dependancy on haddock-leksah only applies if you are using ghc-6.10. If you are only supporting ghc 6.12 and above you can ignore it. This is what is in the leksah-server.cabal file... if (impl(ghc = 6.12)) build-depends: haddock = 2.7.2 2.10 else build-depends: haddock-leksah == 2.5.0 process-leksah is still needed. The feature request is here... http://hackage.haskell.org/trac/ghc/ticket/3994 Favonia has recently made some suggestions and raised some concerns and I imagine it may take a little while to resolve those. Once it is in we will need to update some of the imports as process-leksah module names are different to avoid conflicts. Also, is there a chance that the features of binary-shared will be merged into binary eventually? We would like to see it included and we will prepare a patch and submit it to trac/ghc for consideration. Thanks, Hamish ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
On Sat, 23 Apr 2011, Heinrich Apfelmus wrote: David Terei wrote: Good chance you've already read this but if not here is a good post by Linus about his take on the problems with darcs: http://markmail.org/message/vk3gf7ap5auxcxnb I always have to smile at the complaint that something is academic. :D You know, like purely functional programming, that's soo academic. It's centered around some academic ideas, like mathematical functions, higher-rank types, monads and zygohistomorphic prepromorphisms, that have absolutely no relevance in real life, and that just don't work in practice. You do *not* want to write whole programs that way. At some point, you need something that works at another level than pure functions. What the *hell* do you do? I also found the introduction about 'darcs' being too academic quite silly. However at the end of his invited rant Linus proposes a requirement (or may we call it 'axiom'?), that would be nice to be have: An identifier (a 'version') that can be uniquely mapped to a set of files and their contents. In Darcs this is the darcs history and it is usually the largest part of submitted darcs patches. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Berlin Haskell Meeting
Hi all! The next Berlin Haskell Meeting will be next wednesday: Date: Wednesday, April 27th Time: from 20:00 Location: c-base, Rungestrasse 20, 10179 Berlin I hope, this is not on too short notice. Cheers, Sönke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
On Sat, 2011-04-23 at 12:31 +0200, Heinrich Apfelmus wrote: David Terei wrote: Good chance you've already read this but if not here is a good post by Linus about his take on the problems with darcs: http://markmail.org/message/vk3gf7ap5auxcxnb I always have to smile at the complaint that something is academic. :D You know, like purely functional programming, that's soo academic. It's centered around some academic ideas, like mathematical functions, higher-rank types, monads and zygohistomorphic prepromorphisms, that have absolutely no relevance in real life, and that just don't work in practice. You do *not* want to write whole programs that way. At some point, you need something that works at another level than pure functions. What the *hell* do you do? I think a better invective would be amazing. Best regards, Heinrich Apfelmus To be fair he realize[s] that's a pretty weak flame, and I'm sorry. He gives reason why he thinks it have no meaning in real live like: Fundmantal example: somebody has a problem/bug. Tell me how to tell a developer what his exact version is - without creating new tags, and without having to synchronize the archives. Just tell the developer what version he is at. I'm not English native speaker but there are 2 reasons why we may assume that he does not think academic == irrelevant: - quotes around word usually denotes non-literal meaning (in this context) - IIRC that can be used only in defing relative clauses. Therefore he does not think (or he might not think) academic idea have no meaning in real life but those particular ideas. I'm not saying that he's right but he implied much less that it one would assume from quote academic. Regards I think that quotes around the word + structure of sentence (relative clause with that which implies it is non-defining) signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
On 21/04/2011 11:16 PM, John Millikin wrote: My chief complaint is that it's built on patch theory, which is ill-defined and doesn't seem particularly useful. The Bazaar/Git/Mercurial DAG model is much easier to understand and work with. Possibly as a consequence of its shaky foundation, Darcs is much slower than the competition -- this becomes noticeable for even very small repositories, when doing a lot of branching and merging. I think it's been kept alive in the Haskell community out of pure eat our dogfood instinct; IMO if having a VCS written in Haskell is important, it would be better to just write a new implementation of an existing tool. Of course, nobody cares that much about what language their VCS is written in, generally. Ah, how silly of me. I should have known a question like this was highly likely to provoke a flamewar. I had assumed that the way Darcs was is *the definition of* what distributed version control is. So it was a bit of a shock to read about how Git works, and discovered that it does it totally wrong. So I want and read about Mercural and all the others, and discovered that they all do it wrong too. Given that the way Darcs works is so superior to the way everything else works, I was just puzzled as to why even GHC is trying to get rid of it. It seems the answer is some combination of performance issues (I've never seen any) and reliability issues (which again I've never come across). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Storing failing testcases for QuickCheck
Hi! I would like to have a library that would allow to use QuickCheck in the normal manner, but it would save test data for failing properties on the filesystem (maybe using the shiny new acid-state?). On consecutive test runs, the saved test data would be used first (before generating new arbitrary test data). I think, this would come in quite handy when doing test driven development. Any comments on this? Does something like this already exist? Cheers, Sönke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] There is no null; Maybe/Option types
Evan Laforge qdun...@gmail.com writes: Most of the (non-IO) runtime errors I get using Haskell software is due to head or fromJust, it's actually quite annoying. Just singling this one out because I've heard it before. I've never gotten a runtime error from these. It seems quite easy to just not use these functions. Unfortunately, it is quite easy to just use them, too :-) Sometimes I just *know* that this list will never be empty, or that that Maybe will never be nothing - but often I'm wrong. Maybe is in a sense easier, as 'Maybe a' and 'a' are different types, while there isn't a similarly elegant type distinction between lists that may be empty and lists with at least one element. Maybe is really quite brilliant. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to use cabal's data-files feature and run in-place?
On Thu, Apr 21, 2011 at 11:27:10PM -0500, Antoine Latter wrote:
2. Here's what I do for the paths situation:
In the package description, create a CPP option so you know you're
compiling via Cabal:
Cpp-options: -DCABAL
Then create a module to wrap around the autogenerated paths module,
making sure to put the CPP Language pragma at the top:
{-# LANGUAGE CPP #-}
You can then use #ifdef CABAL to decide to re-export the Cabal
autogenerated paths functionality, or to use the ones you've written
yourself (based on the current directory or whatever you need).
I hope that this helps! I don't have any examples on hand at the moment.
Thanks -- works like a charm! I'm particularly pleased to see that ghci
supports cpp.
Richard
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
I'm a great fan of darcs, and also have never run into the performance and reliability issues that GHC has. That said, it's clear that they *have* run into them, and if something else makes GHC development go more smoothly, then I'm 100% supportive of their using it. It is disappointing, though that (I agree with you here) git and others have a fundamentally bad model for performing the task. They chose that model for pragmatic reasons... it's operationally clearer, even if the meaning of things is a bit more muddled. Making a working znd pragmatic version control system using a darcs-ish model is simply a harder job than doing the same in the git/hg way. I use darcs whenever I can, and think they have done an excellent job by and large; but you won't find a single darcs developer who thinks they have completely accomplished the task. On Apr 23, 2011 5:57 AM, Andrew Coppin andrewcop...@btinternet.com wrote: On 21/04/2011 11:16 PM, John Millikin wrote: My chief complaint is that it's built on patch theory, which is ill-defined and doesn't seem particularly useful. The Bazaar/Git/Mercurial DAG model is much easier to understand and work with. Possibly as a consequence of its shaky foundation, Darcs is much slower than the competition -- this becomes noticeable for even very small repositories, when doing a lot of branching and merging. I think it's been kept alive in the Haskell community out of pure eat our dogfood instinct; IMO if having a VCS written in Haskell is important, it would be better to just write a new implementation of an existing tool. Of course, nobody cares that much about what language their VCS is written in, generally. Ah, how silly of me. I should have known a question like this was highly likely to provoke a flamewar. I had assumed that the way Darcs was is *the definition of* what distributed version control is. So it was a bit of a shock to read about how Git works, and discovered that it does it totally wrong. So I want and read about Mercural and all the others, and discovered that they all do it wrong too. Given that the way Darcs works is so superior to the way everything else works, I was just puzzled as to why even GHC is trying to get rid of it. It seems the answer is some combination of performance issues (I've never seen any) and reliability issues (which again I've never come across). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] There is no null; Maybe/Option types
Ketil Malde schrieb: Maybe is in a sense easier, as 'Maybe a' and 'a' are different types, while there isn't a similarly elegant type distinction between lists that may be empty and lists with at least one element. Maybe is really quite brilliant. type NonEmptyList a = (a, [a]) data NonEmptyList a = NonEmptyList a [a] I use the second one frequently for quick check testing and especially for testing on infinite lists. Unfortunately, the Prelude functions like 'cycle' (for input and output) and 'group' (for sublists of the result list) do not use that type. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] There is no null; Maybe/Option types
On Sat, Apr 23, 2011 at 5:57 PM, Ketil Malde ke...@malde.org wrote: Evan Laforge qdun...@gmail.com writes: Most of the (non-IO) runtime errors I get using Haskell software is due to head or fromJust, it's actually quite annoying. Just singling this one out because I've heard it before. I've never gotten a runtime error from these. It seems quite easy to just not use these functions. Unfortunately, it is quite easy to just use them, too :-) Sometimes I just *know* that this list will never be empty, or that that Maybe will never be nothing - but often I'm wrong. That's the thing I was commenting on... I do a lot of things wrong, but maybe somewhere I'm doing something right, because for whatever reason this never comes up for me. The only times I can think of are 'maximum' that I know will complete because I wrote 'maximum (0 : stuff)' and split functions, which are guaranteed to return at least one element. As Henning points out, (a, [a]) is an explicit type for those, but usually I just trust the postcondition of the function and match right away on its output. I have lots of 'maybe [] id' or whatever, but it's always cases where I expect a Nothing so I have an escape route planned. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Storing failing testcases for QuickCheck
On 4/23/11 8:02 AM, Sönke Hahn wrote: Hi! I would like to have a library that would allow to use QuickCheck in the normal manner, but it would save test data for failing properties on the filesystem (maybe using the shiny new acid-state?). On consecutive test runs, the saved test data would be used first (before generating new arbitrary test data). I think, this would come in quite handy when doing test driven development. Any comments on this? Does something like this already exist? The closest I can think of is using HUnit on the same property functions you use in QuickCheck. I do this often for regression testing and to ensure that corner cases are covered[1]. Unfortunately this still requires a bit of hand-holding to keep your regression suite up to date. I would *love* there to be a tool which (a) automatically saves failing QuickCheck values to disk, and (b) automates using HUnit to load those in and test them. I'm not so sure that QuickCheck should be doing the second step of that since that'd really mess with the QuickCheck infrastructure; once you have the code for reading from disk, it'd be trivial to just use HUnit. [1] I also do some overloading of (==) and similar, so that I can use the same properties in both QuickCheck and lazy SmallCheck. Unfortunately, I've yet to come up with a good way to ensure that QuickCheck doesn't explore territory already covered by SmallCheck. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] fishing for ST mutable Vector examples
brad clawsie clawsie at fastmail.fm writes: hi all i was wondering if anyone could post some minimal examples on using mutable Vectors in the ST monad. i've been digging around in the usual places but haven't been able to find anything to get me over the hump thanks in advance brad I was just looking into the same thing. This link at Rosetta Code has a list shuffling function, which is my first experiment with mutable Vectors: http://rosettacode.org/wiki/Balanced_brackets#Haskell The list is converted to a mutable Vector, the mapM_ performs a series of element swaps, then the result is frozen and converted back to a list. - Globules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
