Re: [Haskell-cafe] sequential logic
2012/12/5 Christopher Howard christopher.how...@frigidcode.com: 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
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 johan.tib...@gmail.com: On Tue, Nov 20, 2012 at 1:10 PM, Gregory Guthrie guth...@mum.edu 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: command line: 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] 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 mag...@therning.org: 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, timothyho...@seznam.cz 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org
Re: [Haskell-cafe] Either Monad and Laziness
On 13 September 2012 20:29, wren ng thornton w...@freegeek.org 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] 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, o...@okmij.org 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 ericvm...@gmail.com 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, o...@okmij.org 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
[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
