[Haskell-cafe] Either Monad and Laziness
Hello, I am currently trying to rewrite the Graphics.Pgm library from hackage to parse the PGM to a lazy array. The current implementation parses it straight to UArray, which is strict. The behaviour I want to achieve is like this: I want the program when compiled to read from a file, parsing the PGM and at the same time apply transformations to the entries as they are read and write them back to another PGM file. The problem is that even using a lazy array structure, because the parser returns an Either structure it is only possible to know if the parser was successful or not after the whole file is read, therefore requiring it to read the entire file before applying the transformations, ruining the property of laziness. Is there some way to keep this from happening? Should I even want to make it like this? Not really a real life situation, but imagine I want to read a really large PGM file which does not fit into RAM memory and I don't want to be forced to have the whole array in the memory at once. One alternative I thought was parsing only the PGM header and then read the rest of the input without using Parsec and the Either Monad. In the event the data is corrupted, though, I would not know how to recover from it. Any thoughts? Hopefully I'm not saying anything really stupid. Eric ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Either Monad and Laziness
Thanks for all the tips! The iteratees seem worth checking out. I'll see what I can do and will report back if I come up with something. Eric On 12 September 2012 03:03, wrote: > >> I am currently trying to rewrite the Graphics.Pgm library from hackage >> to parse the PGM to a lazy array. > > Laziness and IO really do not mix. > >> The problem is that even using a lazy array structure, because the >> parser returns an Either structure it is only possible to know if the >> parser was successful or not after the whole file is read, > > That is one of the problems. Unexpected memory blowups could be > another problem. The drawbacks of lazy IO are well documented by now. > >> The behaviour I want to achieve is like this: I want the program when >> compiled to read from a file, parsing the PGM and at the same time >> apply transformations to the entries as they are read and write them >> back to another PGM file. > > Such problems are the main motivation for iteratees, conduits, pipes, > etc. Every such library contains procedures for doing exactly what you > want. Please check Hackage. John Lato's iteratee library, for example, > has procedure for handling sound (AIFF) files -- which may be very > big. IterateeM has the TIFF decoder -- which is incremental and > strict. TIFF is much harder to parse than PGM. > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Either Monad and Laziness
On 12 September 2012 11:46, Eric Velten de Melo wrote: > Thanks for all the tips! The iteratees seem worth checking out. I'll > see what I can do and will report back if I come up with something. > > Eric > > On 12 September 2012 03:03, wrote: >> >>> I am currently trying to rewrite the Graphics.Pgm library from hackage >>> to parse the PGM to a lazy array. >> >> Laziness and IO really do not mix. >> >>> The problem is that even using a lazy array structure, because the >>> parser returns an Either structure it is only possible to know if the >>> parser was successful or not after the whole file is read, >> >> That is one of the problems. Unexpected memory blowups could be >> another problem. The drawbacks of lazy IO are well documented by now. >> >>> The behaviour I want to achieve is like this: I want the program when >>> compiled to read from a file, parsing the PGM and at the same time >>> apply transformations to the entries as they are read and write them >>> back to another PGM file. >> >> Such problems are the main motivation for iteratees, conduits, pipes, >> etc. Every such library contains procedures for doing exactly what you >> want. Please check Hackage. John Lato's iteratee library, for example, >> has procedure for handling sound (AIFF) files -- which may be very >> big. IterateeM has the TIFF decoder -- which is incremental and >> strict. TIFF is much harder to parse than PGM. >> It would be really awesome, though, if it were possible to use a parser written in Parsec with this, in the spirit of avoiding code rewriting and enhancing expressivity and abstraction. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Either Monad and Laziness
On 13 September 2012 20:29, wren ng thornton wrote: > On 9/12/12 5:37 PM, Francesco Mazzoli wrote: >> >> At Wed, 12 Sep 2012 12:04:31 -0300, >> Eric Velten de Melo wrote: >>> >>> It would be really awesome, though, if it were possible to use a >>> parser written in Parsec with this, in the spirit of avoiding code >>> rewriting and enhancing expressivity and abstraction. >> >> >> There is <http://hackage.haskell.org/package/attoparsec-conduit> and >> <http://hackage.haskell.org/package/attoparsec-enumerator>, which turn >> attoparsec parsers into enumerators/conduits, and >> <http://hackage.haskell.org/package/attoparsec-parsec>, which is a >> compatibility >> layer between attoaparsec and parsec. Good luck :). > > > Not to mention attoparsec-iteratee, for the iteratee minded folks: > > http://hackage.haskell.org/package/attoparsec-iteratee > Hm... I guess I'm spoiled for choice then. :) But now I'm kinda lost. Is there an easy way to explain the difference between: -iteratee -conduit -enumerator I'm very curious about everything concerning Haskell and new interesting abstractions and ways of doing things, but I might not have the time to delve deeper into that. > > -- > Live well, > ~wren > > > ___ > 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] GHC maintenance on Arch
In his defense, from the perspective of a more or less newbie in the subject matter, I had quite a bit of trouble using Haskell under Arch. Not that it is so much better in other systems, I wouldn't know. I often was in the position to decide whether to use cabal-install, arch-haskell repositories or official repositories and many times the thing that worked for me was a mix of everything, which is quite sub-optimal, although more or less working for me at the moment. I'm not saying that this is because the way Arch works or the way Cabal is designed is wrong. Maybe it is because I'm not figuring it out. Some people say you should not use cabal-install as a package manager, because it is not supposed to be one. Again, other people say arch-haskell repositories are very buggy at the moment and one should install only cabal-install and ghc from the official repositories and only use cabal-install for the rest. Just telling my experience so far: I often have had to struggle between cabal dependency hell and non-working packages in the repositories. Either something is very wrong with the way things are right now or I'm doing everything wrong (which is more likely). I am still not in the condition of proposing things myself, but I don't think this is fair treatment so far to someone that is proposing a compromise solution to a problem he found. Anyway, hopefully this would be better clarified in the arch-haskell mailing list. 2012/10/29 Magnus Therning : > Hello Timothy, > > Now I'm going to run the risk of upsetting you quite a bit by being > completely blunt. > > You come across in your mail like someone who has thought through your > own situation, but fail to see the larger picture. You do know *your* > Haskell needs, and you know what *you* would want from a project like > ArchHaskell. Then however you completely fail to realise that these > are *your needs*, not anyone else's, but still you suggest that > ArchHaskelll is broken because it doesn't provide a system that solves > *your* problems. > > I suggest you take your insights of your situation and try to find a > solution that works for you, and it sounds like you're on the way > already with cabal-install. If you have suggestions on how to improve > ArchHaskell *within the goals of the project* (which includes the > general goals of ArchLinux) that would make ArchHaskell more usable to > you, then you are more than welcome. However, if all you do is > suggest that we completely change the goals of ArchHaskell because > they don't align with your needs, then we thank you for your input, > but ask you to not hold your breath for any changes. > > /M > > On Sun, Oct 28, 2012 at 9:49 PM, wrote: >> Hello, >> Who is in charge of the ghc and haskell packages on Arch linux? The current >> system isn't working. >> >> Arch linux tends to update packages very quickly. >> >> For ghc, always having the latest ghc isn't a good thing. At least if you >> actually want to get some work done. A majority of the time the latest GHC >> is unusable. This is because the packages in hackage simply don't keep up. >> With the current ghc version(7.6.1) even some basic packages in hackage are >> not upgraded yet. >> >> Right now, a large number of other haskell related packages are in the arch >> repos. Other than gtk2hs, I think these packages are pointless duplications. >> In the other cases, it has been my experience that it is simpler to maintain >> these packages through cabal rather than through pacman. Support for these >> packages in Arch should probably be dropped. >> >> If you want to get work done in Arch with haskell, you should only install >> ghc and cabal-install(right now, you'll have to search the Internet for the >> old binaries, because the arch repos usually don't keep the old versions >> around). Then you should add these packages to "IgnorePkg =" in pacman.conf >> this way things won't break every couple of months. You can then choose to >> upgrade when you wish. >> >> I hope that someone who is involved with the haskell Arch stuff reads this. >> The current model needs to be rethought. Linux should be sane by default, >> but I've lost many many hours learning that arch's relationship with haskell >> is not so :( Probably the best solution would be to make Arch automatically >> keep two versions of ghc around at any given time. >> >> Thank you for your time, >> Timothy Hobbs >> >> ___ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > > -- > Magnus Therning OpenPGP: 0xAB4DFBA4 > email: mag...@therning.org jabber: mag...@therning.org > twitter: magthe http://therning.org/magnus > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Hask
Re: [Haskell-cafe] cabal install...
I have a dream of one day being able to install leksah without having to downgrade ghc. Right now I can't even install cabal-dev with cabal. It will break ghc if I do. 2012/11/20 Johan Tibell : > On Tue, Nov 20, 2012 at 1:10 PM, Gregory Guthrie wrote: >> >> Hmm, >> >> Now when I tried to run Leksah, I get not only some broken packages (which >> I can avoid for my current project), but: >> >> >> >> : cannot satisfy -package-id >> base-4.5.1.0-7c83b96f47f23db63c42a56351dcb917: >> >> base-4.5.1.0-7c83b96f47f23db63c42a56351dcb917 is unusable due to >> missing or recursive dependencies: >> >> integer-gmp-0.4.0.0-c15e185526893c3119f809251aac8c5b >> >> (use -v for more information) >> >> >> >> So I tried to install base, then re-install it, but both fail; >> >> Any hints? > > > From this email and some of the previous emails it seems that your package > DB is in a pretty bad state, most likely from using --force-reinstalls. When > Cabal warns you that this will break stuff it actually means it. :) My > suggestion is that you > > rm -rf ~/.ghc/x86_64-linux-7.6.1 # or equivalent on your system. > > Then reinstall all the packages you want by listing them all at once > > cabal install pkg1 pkg2 pk3 > > By listing them all together cabal-install tries to come up with an install > plan that is globally consistent for all of them. > > -- Johan > > > ___ > 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] sequential logic
2012/12/5 Christopher Howard : > Hi. I was wondering what the various (and especially most simple) > approaches one could take for working with (simulating or calculating) > sequential logic in Haskell. By sequential logic, I mean like wikipedia > describes, where a system is made up of logic gates, whose output is > dependent not only on the logic operation of the gate, but on the > previous state of the gate. (Like in electronics where the system can be > driven by a clock signal or have memory.) > > Does one have to get into FRP for that sort of thing? Or use some kind > of FSM framework? Or is there some kind of fancy state monad suitable > for that? Or...? > > I'm no electronic or digital engineer, but for learning purposes I've > been trying to see if I could build an (extremely simple) virtual > processor or calculator in Haskell, using only the Bool type and a few > of the boolean operators (and functions composed of the aforementioned), > reproducing things like half adders and full adders as functions in the > program. Of course, I quickly ran into the stateful aspect of the > problem, in subjects like clock signal and flip flops. Not answering your question directly, but you might be interested in checking out this programming language: http://en.wikipedia.org/wiki/Hume_(programming_language) > > -- > frigidcode.com > > > ___ > 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