Re: [Haskell-cafe] Message
On Thu, Nov 3, 2011 at 9:09 PM, Ryan Newton rrnew...@gmail.com wrote: I have interfaced Erlang and Haskell... And delivered it as a product. I just came up with a dead-simple text based communication syntax from Erlang to Haskell that was very easily testable. It allowed for complete isolation Interesting. I can't imagine there are too many people who have done this. So I must ask -- given the explicit attempt to imitate Erlang in recent CloudHaskell work, does that come close to giving you everything you would have wanted in this app? I don't know, as I've not looked at all at CloudHaskell at all. My current job doesn't really give me a lot of time for it. There's definite advantages to polyglot programming approaches. The difficulty is in the glue, and that doesn't have to really be that difficult. I just picked a text based protocol that was really easy to implement and understand as well as test externally. No XML, no JSON, nothing standardized, just tiny and really obvious. With a sufficiently simple protocol getting C++, haskell and erlang on the same page was pretty trivial, and the separation of concerns for each piece was really well drawn. It felt like what was meant by the unix philosophy of one good tool for each job coordinated over pipes because well that's exactly what I did. Dave (Hot code update being the big missing piece.) Cheers, -Ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Message
On Fri, Oct 21, 2011 at 8:02 AM, Yves Parès limestr...@gmail.com wrote: That's interesting, have you ever worked on interfacing Erlang with Haskell? I have interfaced Erlang and Haskell... And delivered it as a product. I just came up with a dead-simple text based communication syntax from Erlang to Haskell that was very easily testable. It allowed for complete isolation of components and them to be developed and debugged in parallel. The Haskell code was an Erlang pipe driver, which, in turn was connected to a C program to drive a polling interface, controlled by Haskell with the fancy IO done in C. All of this was on a relatively small linux appliance. I'm pretty proud of that little system. It was quickly done, and I was able to mock out various pieces of it very quickly as well. When the hardware it was meant to control finally arrived I think I only spent a few extra hours turning the screws to make it work for real and then we discovered wiring problems :-) BTW, Twitter switched to Scala, so obviously their initial choice of Ruby end up invalidated. I believe they have Java, Clojure and Scala actually. I know of a guy doing a start up using only Go, and that language is not even fully released yet. They're most definitely using Clojure in their Storm realtime event processing framework anyway, and it's freely available. Other than finding people who can come work for you writing good Haskell code, I don't see any reason to avoid doing a startup using that language as a code base. The Haskell Platform makes things a little nicer, but needs to have more regular releases. Go comes with a lot of batteries already making it slightly more attractive. Dave 2011/10/21 Alex Kropivny alex.kropi...@gmail.com Let's look at this from a high, project management level. Twitter ran on... Ruby initially? Facebook ran on PHP. Immediately this tells me that programming language choice wasn't a factor in their success. One succeeded in building a large throughput system with a slow language, the other succeeded in building a massively popular website with a bad one. What hard problems did they have to solve? Twitter had to deal with scalability, distribution, and massive throughput. These are hard problems on their own, and are non-trivial even in languages tailor made to handle them. (Although using Erlang would make things a good deal easier.) Facebook is not a technical problem at all. There are interesting challenges hidden within (ad targeting and friend feed optimization) but they're tiny, isolated components. Rapid development and prototyping of features help Facebook, but if the features are easy CRUD stuff it's perfectly cost effective to hire a pile of PHP developers to do them. One has problems that are hard regardless of tool choice, the other has no hard problems at all. No Haskell needed, use whatever language you can outsource overseas. With that in mind. Using Haskell gives you an edge, for most problems, even the ones with poor libraries. If you can get the programmer manpower you need, it is a clear advantage over your competition. Your startup may not need that advantage - as Facebook retrospectively didn't - but you don't know that when just starting out. If Facebook went deep into user behaviour analysis and newsfeed optimization, the way OkCupid has with dating, Haskell would suddenly stand out. If you need every advantage you can get, you use the best tools for the job. Haskell is one of the best and shiniest - I personally would use Erlang for any embarrassingly parallel parts of the service and do the rest in Haskell. On Fri, Oct 21, 2011 at 1:00 AM, Matti Oinas matti.oi...@gmail.comwrote: I don't think I'm going to write next twitter or facebook but yes, it is on my TODO list. If such an applications can be written with languages like PHP then why not. Can't think of any language that is worse than PHP but still there are lots of web applications written with that. Even I have written many using PHP. Why I would use Haskell? To see if it is better option to that problem than other languages. I have allready installed Yesod but for now I don't have enough time to work on this project. After 6 months the situation should be different. 2011/10/21 Michael Snoyman mich...@snoyman.com: This is clearly a job for node.js and the /dev/null data store, since they are so web scale~ Less sarcasm: I think any of the main Haskell web frameworks (Yesod, Happstack, Snap) could scale better than Ruby or PHP, and would use any of those in a heartbeat for such a venture. I'd personally use Yesod. I think data store would be a trickier issue. I'd likely use one of the key/value stores out there, possibly Redis, though I'd really need to do more research to give a real answer. Michael On Fri, Oct 21, 2011 at 9:42 AM, Yves Parès limestr...@gmail.com wrote: Wow, controversial point I guess...
Re: [Haskell-cafe] *GROUP HUG*
I got hired at a company because one of the interviewers was impressed that I taught myself Haskell. I basically never use it at work, but I did in my old job. Dave On Thu, Jun 2, 2011 at 2:23 PM, Michael Litchard mich...@schmong.orgwrote: I disagree. I'm by no means proficient in Haskell. And, I never bothered learning PHP. I will when I need to. PHP programmers are a dime a dozen. It's been my experience that Haskell is a tool one may use to distinguish oneself from the hoi-poloi. This is important when you live in an area where the baker down the street has a CS degree. On Thu, Jun 2, 2011 at 11:52 AM, Yves Parès limestr...@gmail.com wrote: Learning Haskell will pay off much less than learning PHP, if your goal is to find a job. Amen. I cannot agree with this for practical reasons. I'm using Haskell for real world commercial applications, and I'm very productive with it. I wish so much I could say that... Out of curiosity, what are you using Haskell for? 2011/6/2 Ertugrul Soeylemez e...@ertes.de Alberto G. Corona agocor...@gmail.com wrote: Haskell is an academic asset as well as a fun asset. I cannot agree with this for practical reasons. I'm using Haskell for real world commercial applications, and I'm very productive with it. There is however a variation of this statement, with which I could agree, namely: Learning Haskell will pay off much less than learning PHP, if your goal is to find a job. It takes a lot longer and there are a lot less companies in need of Haskell programmers. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ 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 ___ 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] The Lisp Curse
See the Haskell Platform. Sent from my iPhone On May 19, 2011, at 1:56 PM, Andrew Coppin andrewcop...@btinternet.com wrote: On 19/05/2011 09:34 PM, vagif.ve...@gmail.com wrote: Andrew, you are being non constructive. It seems I'm being misunderstood. Some people seem to hold the opinion that more libraries = better. I'm trying to voice the opinion that there is such a thing as too many libraries. The article I linked to explains part of why this is the case, in a better way than I've been able to phrase it myself. I'm not trying to say OMG, the way it is now completely sucks! I'm not trying to say you must do X right now! I'm just trying to put forward an opinion. The opinion that having too many libraries can be a problem, which some people don't seem to agree with. (Obviously it isn't *always* bad, I'm just saying that sometimes it can be.) That's all I was trying to say. ___ 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] Why not Darcs?
Codehole doesn't sound like a good name. Don't lose stuff in codehole! Sent from my iPhone On Apr 21, 2011, at 7:33 PM, Simon Michael si...@joyful.com wrote: +1 to what you said. On 4/21/11 4:16 PM, John Meacham wrote: Incidentally, I wrote a github like site based around darcs a few years ago at codehole.org. It is just used internally by me for certain projects. but if people were interested, I could resume work on it and make it public. John, please do - darcs folks are longing for a really good hub. You're probably aware of patch-tag and darcsden - perhaps you can exceed or reuse those ? Both are good but have maintainers now focussed elsewhere. Running a robust scalable public darcs hub is difficult. I think darcs developers are keen to help anyone working on that. FYI codehole seems access-restricted. -Simon ___ 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] ANNOUNCE: enumerator 0.4.8
On Mon, Mar 28, 2011 at 8:06 AM, John Millikin jmilli...@gmail.com wrote: On Sunday, March 27, 2011 9:45:23 PM UTC-7, Ertugrul Soeylemez wrote: For setting a global timeout on an entire session, it's better to wrap the ``run_`` call with ``System.Timeout.timeout`` -- this is more efficient than testing the time on every chunk, and does not require a specialised enumerator. It may be more efficient, but I don't really like it. I like robust applications, and to me killing a thread is always a mistake, even if the thread is kill-safe. ``timeout`` doesn't kill the thread, it just returns ``Nothing`` if the computation took longer than expected. Timeout does kill the thread that is used for timing out :-). The thread that measures the timeout throws an exception to the worker thread that's being monitored. Either way you're interrupting a thread. Kill it or toss an exception at it, I don't see the difference really. Dave ___ 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] unregisterised plan9 port
I'd also love to see GHC on Plan 9. I don't have a lot of time to contribute to such an effort really though I do wish you well! On Mon, Mar 21, 2011 at 1:20 AM, * midbr...@gmail.com wrote: Hi there. I am trying to get an unregisterised build of ghc 7.0.2 working and am having problems turning mangling off. When I build the compiler with GhcUnregisterized = YES GhcWithNativeCodeGen = NO SplitObjs = NO BeConservative = YES The 'evil mangler' is still used. When I disable it at the command line with -fno-asm-mangling the FB_ macro is still put into the generated C. I just want to turn everything related to this dreaded evil mangler off, and still produce working executables. Are there things that I could set in the build.mk file to do this, or is it more involved? I have read some things in the mailing list and the bug tracker that (to my ignorant and slightly confused ears) seem to suggest that this unregisterised is problematic or depreciated or something. If this is the case I would be perfectly happy using an older version of the compiler, and would be grateful if someone could point me to a specific older version number where this stuff builds with less hassel. I don't care how out of date it is. In case you are wondering, I am attempting to get an unregisterised port of ghc working in plan9, an operating system that has yet to be blessed with a haskell implementation (hugs doesn't count :P) Plan 9 has a gcc port, an older one, but it should be fine. ___ 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] iteratee-compress space leak?
Sent from my iPhone On Feb 22, 2011, at 5:03 AM, John Lato jwl...@gmail.com wrote: 2011/2/22 Michael A Baikov pa...@bk.ru -Original Message- Hi Maciej, Thanks for looking in to this. After looking into problem (or rather onto your code) - the problem have nothing to do with iteratee-compress I believe. I get similar behaviour and results when I replace joinIM $ enumInflate GZip defaultDecompressParams chunkedRead by chunkedRead. (The memory is smaller but it is due to decompression not iteratee fault). This is due to printLines. Whether it's a bug depends on what the correct behavior of printLines should be. printLines currently only prints lines that are terminated by an EOL (either \n or \r\n). This means that it needs to hold on to the entire stream received until it finds EOL, and then prints the stream, or drops it if it reaches EOF first. In your case, the stream generated by convStream consChunk printLines is just a stream of numbers without any EOL, where the length is dependent on the specified block size. This causes the space leak. If I change the behavior of printLines to print lines that aren't terminated by EOL, the leak could be fixed. Whether that behavior is more useful than the present, I don't know. Alternatively, if you insert some newlines into your stream this could be improved as well. As a result of investigating this, I realized that Data.Iteratee.ListLike.break can be very inefficient in cases where the predicate is not satisfied relatively early. I should actually provide an enumeratee interface for it. So thanks very much for (indirectly) suggesting that. Actually i can give you full sorce code - it uses also attoparsec-iteratee. it leaks with iteratee-compress and works fine without it. Whole idea - get bytestring from access.log, convert it to stream of data object with usernames and bytes downliaded and then feed this stream into iteratee which will collect all data into one big Map ByteString Integer. I'm not familiar with iteratee-compress, but you could be getting hit by Map's laziness. Instead of a map, could you use something like hashmap[1], bytestring-trie[2], or Johan's new containers library[3]? I've definitely hit lazy Map update problems more than once in my Haskell career. Something I was expecting to run in constant space was spiraling out of control. The profiling tools that ship with GHC were outstanding in helping pinpoint the issue. As was Real World Haskell's chapter on the topic. Also, I've recently posted a minor update to iteratee which includes an enumeratee version of break and an alternative to printLines that doesn't retain data, which you may find useful. Cheers, John [1] http://hackage.haskell.org/package/hashmap [2] http://hackage.haskell.org/package/bytestring-trie [3] http://hackage.haskell.org/package/unordered-containers ___ 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] forkIO on GHCI does not seem to spawn the thread in the background on some OSs
On Tuesday, February 8, 2011, C K Kashyap ckkash...@gmail.com wrote: I can't reproduce this. What are you using as the action? I've tried bottoms, and tight loops whose Core contains no allocations, and not managed to lock up the prompt, or seen ghci using more threads than I have cores. One thing that may give the appearance of locking up the prompt is if the thread starts reading from the terminal and your commands no longer make it to the interpreter. It is not always a thread. ForkIO creates a spark and then the scheduler decides when sparks should be scheduled to threads. Thus you get a guarantee of concurrent but not parallel execution. That is not correct - it is par that creates sparks may be discarded. forkIO always creates new threads, though it is of course up to the scheduler when the threads are executed, and how many cores are used. Are you running with threads enabled? That is, was your ghci compiled with -threaded? This mostly depends on the version. what version of ghc are you running, and how did you install it? Sorry ... extremely sorry ... my bad ... for some reason, I was omitting the call to forkIO :( when I was trying on other platforms. Regards,Kashyap :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] forkIO on GHCI does not seem to spawn the thread in the background on some OSs
It is not always a thread. ForkIO creates a spark and then the scheduler decides when sparks should be scheduled to threads. Thus you get a guarantee of concurrent but not parallel execution. That is not correct - it is par that creates sparks may be discarded. I guess I should have been clearer. A forkIO thread is not an OS thread necessarily. Sparks may become threads or be discarded in the par sense. forkIO always creates new threads, though it is of course up to the scheduler when the threads are executed, and how many cores are used. Yes, this is my understanding as well. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] forkIO on GHCI does not seem to spawn the thread in the background on some OSs
On Monday, February 7, 2011, C K Kashyap ckkash...@gmail.com wrote: Hi,I found that on windows and my ubuntu box, when I did this ghci t - forkIO someAction someAction started executing in the foreground - as in, the ghci prompt did not come back (until I pressed Ctrl-C) On my mac however, when I ran the same thing, the action started executing in the background and ghci prompt returned instantaneously.How can I get the thread backgrounded explicitly? It is not always a thread. ForkIO creates a spark and then the scheduler decides when sparks should be scheduled to threads. Thus you get a guarantee of concurrent but not parallel execution. Are you running with threads enabled? Regards,Kashyap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GPL License of H-Matrix and prelude numeric
On Tue, Jan 25, 2011 at 8:53 PM, John Millikin jmilli...@gmail.com wrote: On Tue, Jan 25, 2011 at 18:55, Chris Smith cdsm...@gmail.com wrote: Licensing with the GPL has definite consequences; for example, that the great majority of Haskell libraries, which are BSD3 licensed, may not legitimately declare dependencies on it. What are you talking about? Of course BSD3 libraries/applications can depend on GPL'd code. I am not an IP lawyer, but this is my understanding of the GPL and it's transitive relationship with bodies of work that aren't GPL'd. BSD3 doesn't really state anything about what it links with, but the GPL injects itself into the tree of stuff it's linked with via the derivative works clause. The consequence is that the entire derivative work becomes GPL'd as well, and those distributing the derivative work must adhere to the terms of the GPL for distribution and provide source. This is somewhat in the tradition of commercial middleware requiring a royalty fee or some per-installation licensing when a work is distributed that uses a particular library with such terms. In other words transitive licensing properties are NOT unique to the GPL. At least that's always been my understanding. A BSD3 library in isolation may still remain BSD3, but if it's not useful without being linked to a GPL'd library, then the point is kind of moot, except that someone is free to implement a replacement for the GPL'd part to avoid the transitive properties in the derivative work, in much the same way you could implement a free version of a commercial library (barring patent or other violations) to avoid transitive properties of the commercial license. Dave The only license Cabal allows that conflicts with the GPL is BSD4, which (to my knowledge) is not used by any software on Hackage. ___ 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] Reader monad
On Wed, Dec 29, 2010 at 1:48 PM, Michael Lazarev lazarev.mich...@gmail.comwrote: 2010/12/29 michael rice nowg...@yahoo.com I had an Aha! moment and it all makes sense now. Just as the State monad can hold a generator (which can change) and pass it down a calculation chain, a Reader monad can hold an environment (which doesn't change) and pass it down a calculation chain. I was wondering how I could include a (global) house betting limit in that craps application I've been playing with (without passing it as a parameter) and it sounds like the Reader monad would be an ideal candidate. Correct? It also sounds like a job for monad transforms. That is right. You need transformers if you want to have one value as settings to read, other value as a state, and so on, and they must be simultaneously accessible in some function. Or, for example, if you want to build a sequence of IO actions by functions that share the same environment. After you said that you had an Aha! moment, I remembered how I had something alike not very long ago. That was surprising event when I ended up with some transformer stack written myself although just several minutes ago I would consider this to be some dark wizardry. When I was dealing with monads for the first time, I tried reading source code and explanations. Soon I found that pure unapplied theory was making such a dismal, depressing feeling on me that I was not able to continue. But some time after I was writing an application in Haskell. It was real, and contrary to my previous theoretical studies the process was much fun. I had good FP background at that time, and had no problem writing everything in functional style. Since everything that can be done with monads can also be done without them, I didn't use any monad except IO (in main function :) ). Not that I especially avoided them, I just didn't think about them. And then I noticed that I constantly pass one same parameter to a lot of functions. And then -- since I remembered the boring theory -- bam! -- I introduced Reader into the code. And it worked. Which tempted me to interweave Reader and Writer, and so on, and twenty minutes later I had monstrosity that I only saw before in others' code: ReaderT WriterT State and so on :) Reader Writer State is commonly needed in big applications so transformers provides one for us: http://hackage.haskell.org/packages/archive/transformers/0.2.2.0/doc/html/Control-Monad-Trans-RWS-Lazy.html Pretty cool stuff if you ask me. I often wondered about the correct stacking order of Monad transformers, or how often it mattered. Dave So, good luck with your application! ___ 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] ANNOUNCE: yackage 0.0.0
This is very interesting. I was thinking if this could work like an overlayed namespace on top of Hackage, rather than a complete override, that it would be a very interesting way to fork Hackage so it does what you want, transparently, and as a proxy. Is that actually how it works though? (It might be that I've not had my coffee yet, but I'm a little fuzzy on that point). While the Haskell-platform is a great stabilizing technology for the Haskell community and gives a nice warm fuzzy feeling to those who want to try it in commercial settings, it's not always true that it provides enough functionality for everyone's needs, and being able to somewhat modify what's available on Hackage could be very valuable. Dave On Mon, Dec 27, 2010 at 8:41 AM, Michael Snoyman mich...@snoyman.comwrote: Hi all, I was speaking with my coworker Yitz[1] about a project he's working on. Basically, he's going to end up with about 16 cabal packages that are not going to be deployed to Hackage, and wanted us to set up a Hackage server for our company to deploy these kinds of things. However, getting all the pieces of Hackage aligned properly for such a simple use case seemed a bit overkill. I then realized that I had the exact same problem during Yesod development: before I make a major release, I usually end up with about 10-15 packages that are not yet live on Hackage. It gets to be a real pain when suddenly wai-extra is depending on network 2.3 and authenticate requires network 2.2, and suddenly I need to manually recompile 10 packages. So I decided to write up a simple web service to act as a local Hackage server. It has no security (anyone with access can upload a package), doesn't build haddocks, doesn't show package descriptions, etc. All it does is: Show a list of uploaded packages/versions Links to the tarballs Allows you to upload new versions, which will automatically overwrite existing packages Provides the 00-index.tar.gz file needed by cabal-install, as well as the tarballs for all the packages In order to use this, just do the following: cabal install yackage run yackage Upload your packages Add remote-repo: yackage:http://localhost:3500/ to your ~/.cabal/config file cabal update Install your packages are usual You'll need to leave yackage running whenever you want to run an update or download new packages. A few other usage notes: If you overwrite a package, your cache folder will still have the old version. You might want to just wipe our your cache folder on each usage. Running cabal update will download the update for both yackage and the main hackage server; the latter can be a long process depending on your internet connection. Here's a little shell script that will disable the Hackage repo, wipe our the Yackage cache, update and re-enable the Hackage repo: #!/bin/sh CABAL_DIR=~/.cabal cp $CABAL_DIR/config $CABAL_DIR/config.sav sed 's/^remote-repo: hackage/--remote-repo: hackage/' $CABAL_DIR/config.sav $CABAL_DIR/config rm -rf $CABAL_DIR/packages/yackage cabal update cp $CABAL_DIR/config.sav $CABAL_DIR/config I hope others find this tool useful. Michael [1] http://www.haskellers.com/user/Yitz_Gale/ ___ 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] Why is Haskell flagging this?
On Fri, Dec 17, 2010 at 9:04 AM, michael rice nowg...@yahoo.com wrote: I don't understand this error message. Haskell appears not to understand that 1 is a Num. Prelude :t 1 1 :: (Num t) = t Prelude :t [1,2,3,4,5] [1,2,3,4,5] :: (Num t) = [t] Prelude Michael === f :: [Int] - IO [Int] f lst = do return lst main = do let lst = f [1,2,3,4,5] fmap (+1) lst f takes [Int] and returns IO [Int] fmap is fmap :: (Functor f) = (a - b) - f a - f b That is it takes a function of a's to b's, a functor of a, and returns you a functor of b. So when you fmap (+1) to an IO [Int], it's trying to add 1 to a [Int], and [Int] is not an instance of Num, so the + does not work. Luckily you can use function composition here (fmap . fmap) (+1) $ f [1..10] [2,3,4,5,6,7,8,9,10,11] fmap . fmap is the type I think you wanted: Prelude :t fmap . fmap fmap . fmap :: (Functor f, Functor f1) = (a - b) - f (f1 a) - f (f1 b) With IO as the f Functor, and [] as the f1 Functor. === Prelude :l test [1 of 1] Compiling Main ( test.hs, interpreted ) test.hs:5:17: No instance for (Num [Int]) arising from the literal `1' at test.hs:5:17 Possible fix: add an instance declaration for (Num [Int]) In the second argument of `(+)', namely `1' In the first argument of `fmap', namely `(+ 1)' In the expression: fmap (+ 1) lst Failed, modules loaded: none. Prelude ___ 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] Why is Haskell flagging this?
No problem. Haskell is a different animal than even other functional languages in my experience, and it takes time to get used to the coolness in the type system, the lazy evaluation, the point free style, functional composition and all the other interesting techniques you now have at your fingertips for writing very expressive code :-). Do that for a while then go back to algol based languages, and wonder why the heck anyone uses those on purpose :-). (yeah there's good reasons to use them, but it starts to feel confining) Dave On Fri, Dec 17, 2010 at 4:28 PM, michael rice nowg...@yahoo.com wrote: Hi, all. Plenty of answers. Thank you. Putting the list in the IO monad was deliberate. Another one I was looking at was f :: String - IO String f s = do return s main = do ios - f hello fmap tail ios which worked fine So, the big error was trying to add 1 + [1,2,3,4,5]. I considered that I needed an additional fmap and thought I had tried fmap (fmap (1+)) iol but must have messed it up, because I got an error. I guess I was on the right track. I like to try various combinations to test my understanding. It's kind of embarrassing when I get stumped by something simple like this, but that's how one learns. Thanks again, Michael --- On Fri, 12/17/10, Daniel Fischer daniel.is.fisc...@googlemail.com wrote: From: Daniel Fischer daniel.is.fisc...@googlemail.com Subject: Re: [Haskell-cafe] Why is Haskell flagging this? To: haskell-cafe@haskell.org Cc: michael rice nowg...@yahoo.com Date: Friday, December 17, 2010, 4:24 PM On Friday 17 December 2010 18:04:20, michael rice wrote: I don't understand this error message. Haskell appears not to understand that 1 is a Num. Prelude :t 1 1 :: (Num t) = t Prelude :t [1,2,3,4,5] [1,2,3,4,5] :: (Num t) = [t] Prelude Michael === f :: [Int] - IO [Int] f lst = do return lst main = do let lst = f [1,2,3,4,5] fmap (+1) lst The fmap is relative to IO, your code is equivalent to do let lst = (return [1,2,3,4,5]) fmap (+1) lst ~ fmap (+1) (return [1,2,3,4,5]) ~ do lst - return [1,2,3,4,5] return $ (+1) lst but there's no instance Num [Int] in scope You probably meant do let lst = f [1,2,3,4,5] fmap (map (+1)) lst === Prelude :l test [1 of 1] Compiling Main ( test.hs, interpreted ) test.hs:5:17: No instance for (Num [Int]) arising from the literal `1' at test.hs:5:17 Possible fix: add an instance declaration for (Num [Int]) In the second argument of `(+)', namely `1' In the first argument of `fmap', namely `(+ 1)' In the expression: fmap (+ 1) lst Failed, modules loaded: none. Prelude --- On *Fri, 12/17/10, Daniel Fischer daniel.is.fisc...@googlemail.com*wrote: From: Daniel Fischer daniel.is.fisc...@googlemail.com Subject: Re: [Haskell-cafe] Why is Haskell flagging this? To: haskell-cafe@haskell.org Cc: michael rice nowg...@yahoo.com Date: Friday, December 17, 2010, 4:24 PM On Friday 17 December 2010 18:04:20, michael rice wrote: I don't understand this error message. Haskell appears not to understand that 1 is a Num. Prelude :t 1 1 :: (Num t) = t Prelude :t [1,2,3,4,5] [1,2,3,4,5] :: (Num t) = [t] Prelude Michael === f :: [Int] - IO [Int] f lst = do return lst main = do let lst = f [1,2,3,4,5] fmap (+1) lst The fmap is relative to IO, your code is equivalent to do let lst = (return [1,2,3,4,5]) fmap (+1) lst ~ fmap (+1) (return [1,2,3,4,5]) ~ do lst - return [1,2,3,4,5] return $ (+1) lst but there's no instance Num [Int] in scope You probably meant do let lst = f [1,2,3,4,5] fmap (map (+1)) lst === Prelude :l test [1 of 1] Compiling Main ( test.hs, interpreted ) test.hs:5:17: No instance for (Num [Int]) arising from the literal `1' at test.hs:5:17 Possible fix: add an instance declaration for (Num [Int]) In the second argument of `(+)', namely `1' In the first argument of `fmap', namely `(+ 1)' In the expression: fmap (+ 1) lst Failed, modules loaded: none. Prelude ___ 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] Re: Manatee - The Haskell/Gtk+ Integrated Live Environment first version release!
On Thu, Nov 11, 2010 at 9:07 PM, Andy Stewart lazycat.mana...@gmail.comwrote: David Leimbach leim...@gmail.com writes: Wow! Is this just for Linux or is anyone able to run it on Mac OS X? I don't know whether can work on Mac. I design it for Linux. Fair enough, it's a great accomplishment all the same :-). Dave -- Andy Dave On Thu, Nov 11, 2010 at 7:51 PM, Andy Stewart lazycat.mana...@gmail.com wrote: My project want to provide a fact: Haskell not just can do GUI environment, and can do better! Gtk2hs + Haskell Threads is awesome! Below is source code lines of Manatee: All : 21651 Core and toolkit : 7047 Daemon and Window Manager: 3656 Multi-Threads input framework: 2537 Browser : 488 Editor : 813 File manager : 774 Image viewer : 565 IRC client : 2212 Multimedia player: 1358 PDF viewer : 457 Process Manager : 761 RSS/Atom reader : 893 -- Andy Andy Stewart lazycat.mana...@gmail.com writes: Hi all, I am proud to announce the release my gtk2hs project : Manatee - The Haskell/Gtk+ Integrated Live Environment http://hackage.haskell.org/package/manatee Screenshots at : http:goo.gl/MkVw Code at https://patch-tag.com/r/AndyStewart/ beginning with manatee-* Manatee is Haskell integrated environment written in Haskell. The goal of the Manatee project is to provide a fast, safe and flexible integrated environment for haskell hacking. You can consider it is new environment mix Gnome and Emacs. Like Gnome to provide friendly graphics interface and work efficient like Emacs. Manatee use multi-processes framework, any sub-module running in separate process to protected core won't crash. So it minimize your losses when some unexpected exception throw in extension. Now i have implement below sub-modules in Manatee: Editor Webkit Browser File Manager Image Viewer IRC Client Multimedia Player PDF Viewer Process Manager RSS/Atom reader From some friends feedback, manatee can't work in XMonad, i will fix it soon. You can play it in Gnome. Enjoy! :) Below are steps to build Manatee: 1) Install C library: In Debian use below command: sudo aptitude install libgtksourceview2.0-dev libgconf2-dev libwebkit-dev libcurl4-openssl-dev libgtkimageview-dev libpoppler-glib-dev poppler-data libtagc0-dev -y 2) Install Gtk2hs: cabal install gtk2hs-buildtools gtk And make sure HOME.cabalbin/ in your PATH. 3) Install Manatee: cabal install manatee-core manatee-anything manatee-browser manatee-editor manatee-filemanager manatee-imageviewer manatee-ircclient manatee-mplayer manatee-pdfviewer manatee-processmanager manatee-reader manatee That's all, then type command manatee to play it! :) manatee-core manatee-anything manatee are core packages, must be install, other extension package you can choose you want. Example, if you not install manatee-imageviewer, when you open Image file, manatee will call default image-viewer in your system instead. Manatee will show you search interface when you startup it. You can type some filepath or url to open it, example, you can type Haskell file to open in editor, and type url to open in browser. Below are quick play keys: F2 == startProcessManager F3 == startFeedReader F4 == startFileManager F5 == startBrowser F6 == loginIrcDefaultChannel F7 == startIrc Manatee project still in early develop stage, just core framework finish, many details still not perfect. But i think it's good start to build Real-World application in Haskell. Below are high task in my TODO list: Perfect current sub-module: IDE features, code completion browser JavaScript framework graphics custom system etc. Terminal emulator: support MVC design, not like VTE widget Mail-client BT-Client Proxy bridge: to build uniform proxy interface to fighting GFW!!! Jabbar client: video support etc
Re: [Haskell-cafe] Re: Manatee - The Haskell/Gtk+ Integrated Live Environment first version release!
Wow! Is this just for Linux or is anyone able to run it on Mac OS X? Dave On Thu, Nov 11, 2010 at 7:51 PM, Andy Stewart lazycat.mana...@gmail.comwrote: My project want to provide a fact: Haskell not just can do GUI environment, and can do better! Gtk2hs + Haskell Threads is awesome! Below is source code lines of Manatee: All : 21651 Core and toolkit : 7047 Daemon and Window Manager: 3656 Multi-Threads input framework: 2537 Browser : 488 Editor : 813 File manager : 774 Image viewer : 565 IRC client : 2212 Multimedia player: 1358 PDF viewer : 457 Process Manager : 761 RSS/Atom reader : 893 -- Andy Andy Stewart lazycat.mana...@gmail.com writes: Hi all, I am proud to announce the release my gtk2hs project : Manatee - The Haskell/Gtk+ Integrated Live Environment http://hackage.haskell.org/package/manatee Screenshots at : http:goo.gl/MkVw Code at https://patch-tag.com/r/AndyStewart/ beginning with manatee-* Manatee is Haskell integrated environment written in Haskell. The goal of the Manatee project is to provide a fast, safe and flexible integrated environment for haskell hacking. You can consider it is new environment mix Gnome and Emacs. Like Gnome to provide friendly graphics interface and work efficient like Emacs. Manatee use multi-processes framework, any sub-module running in separate process to protected core won't crash. So it minimize your losses when some unexpected exception throw in extension. Now i have implement below sub-modules in Manatee: Editor Webkit Browser File Manager Image Viewer IRC Client Multimedia Player PDF Viewer Process Manager RSS/Atom reader From some friends feedback, manatee can't work in XMonad, i will fix it soon. You can play it in Gnome. Enjoy! :) Below are steps to build Manatee: 1) Install C library: In Debian use below command: sudo aptitude install libgtksourceview2.0-dev libgconf2-dev libwebkit-dev libcurl4-openssl-dev libgtkimageview-dev libpoppler-glib-dev poppler-data libtagc0-dev -y 2) Install Gtk2hs: cabal install gtk2hs-buildtools gtk And make sure HOME.cabalbin/ in your PATH. 3) Install Manatee: cabal install manatee-core manatee-anything manatee-browser manatee-editor manatee-filemanager manatee-imageviewer manatee-ircclient manatee-mplayer manatee-pdfviewer manatee-processmanager manatee-reader manatee That's all, then type command manatee to play it! :) manatee-core manatee-anything manatee are core packages, must be install, other extension package you can choose you want. Example, if you not install manatee-imageviewer, when you open Image file, manatee will call default image-viewer in your system instead. Manatee will show you search interface when you startup it. You can type some filepath or url to open it, example, you can type Haskell file to open in editor, and type url to open in browser. Below are quick play keys: F2 == startProcessManager F3 == startFeedReader F4 == startFileManager F5 == startBrowser F6 == loginIrcDefaultChannel F7 == startIrc Manatee project still in early develop stage, just core framework finish, many details still not perfect. But i think it's good start to build Real-World application in Haskell. Below are high task in my TODO list: Perfect current sub-module: IDE features, code completion browser JavaScript framework graphics custom system etc. Terminal emulator: support MVC design, not like VTE widget Mail-client BT-Client Proxy bridge: to build uniform proxy interface to fighting GFW!!! Jabbar client: video support etc. Spell checker CHM viewer DVI viewer LaTex editor PS viewer Multi-thread download manager Org-Mode : http://orgmode.org/ Twitter client Network toolkit: sniffer etc. Multi-Language translater offline support Too many ideas lying in my TODO list Any suggestion and contribution are welcome! :) -- Andy ___ 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] ANN: fountain-0.0.0
2 things. 1. Wow that's cool. 2. Is this technology not patented by Digital Fountain? (now Qualcomm?) I remember when I first heard of fountain codecs, I thought it was science fiction based on the description :-). Dave On Tue, Oct 19, 2010 at 8:00 PM, Tom Hawkins tomahawk...@gmail.com wrote: This library [1] implements a fountain code [2]. Fountain codes are forward error correction codes for erasure channels [3]. A fountain code encodes a message into an infinite stream of packets -- transmitters generate message packets at random, on-the-fly. To reconstruct the message, receivers simply need to capture enough packets for the decoding process. As a rateless code, fountain codes automatically adapt to varying channel conditions. Some of the more interesting applications of fountain codes include unsynchronized data broadcast and distributed download. For example, a multiple number of devices can transmitting content to multiple receivers without any coordination. Because packets are generated at random, receivers increase their bandwidth simply by listening to more transmitters. Note that receivers can also start generating packets and forwarding the message on even before they have decoded the complete message. This library provides a packet generator and a decoder for one of the first known fountain codes: LT codes [4]. It also includes a test function to experiment with message lengths, and encoding degrees -- it runs a simulation to determine the number of packets needed to decode a message. -Tom [1] http://hackage.haskell.org/package/fountain [2] http://en.wikipedia.org/wiki/Fountain_code [3] http://en.wikipedia.org/wiki/Binary_erasure_channel [4] http://en.wikipedia.org/wiki/LT_codes ___ 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] Re: Cleaning up threads
On Tue, Sep 14, 2010 at 11:29 AM, Bryan O'Sullivan b...@serpentine.comwrote: On Tue, Sep 14, 2010 at 11:21 AM, Edward Z. Yang ezy...@mit.edu wrote: Pure code can always be safely asynchronously interrupted (even code using state like the ST monad), and IO code can be made to interact correctly with thread termination simply by using appropriate bracketing functions that would handle normal IO exceptions. Ertugrul's advice is still correct. I'd wager there are very few concurrent applications that could survive a killThread without disaster. People simply don't write or test code with that in mind, and even when they do, it's more likely than not to be wrong. I don't use killThread, and I write what I'd call somewhat complex concurrent Haskell software for a living right now :-). Instead I have a TChan of commands that I can send to a thread, either from the outside or inside, and that thread will eventually come back to it's event loop that looks at such messages, and shut down gracefully from there. Of course the only time this would happen is if something goes wrong and I'm going to restart and forget all the data I have accumulated thus far anyway. ___ 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
[Haskell-cafe] recommendations for reading list?
In my amazon shopping cart I currently have: *Conceptual Mathematics: A First Introduction to Categorieshttp://www.amazon.com/gp/product/052171916X/ref=ord_cart_shr?ie=UTF8m=ATVPDKIKX0DER *- F. William Lawvere *Categories for the Working Mathematician (Graduate Texts in Mathematics)http://www.amazon.com/gp/product/0387984038/ref=ord_cart_shr?ie=UTF8m=ATVPDKIKX0DER *- Saunders Mac Lane *Categories and Computer Science (Cambridge Computer Science Texts)http://www.amazon.com/gp/product/0521422264/ref=ord_cart_shr?ie=UTF8m=ATVPDKIKX0DER *- R. F. C. Walters Are all 3 of these worthwhile? Any of them? I'm just trying to get a grasp on enough Category Theory to be able think more deeply about programming in general, and maybe grasp more Haskell terminology beyond the seemingly superficial meanings I understand today. Thanks! Dave ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] recommendations for reading list?
Thank you for this suggestion. I do have this book. I found it to be a little lacking in some areas in that it felt like I was reading a student's lecture notes, not the professor's. At some point, I'm left with questions that there's no one around to answer :-). This is why I'm trying to go deeper. I think it's a great one to have on your bookshelf though for quick refreshers! Dave 2010/9/8 Николай Кудасов crazy.fiz...@gmail.com Hi, Dave! Consider this book: *Basic Category Theory for Computer Scientists (Foundations of Computing)http://www.amazon.com/Category-Computer-Scientists-Foundations-Computing/dp/0262660717-- *Benjamin C.Pierce This is at the moment the only book about category theory I've read, but it was easy for me as for programmer rather than mathematician to understand most of the stuff. Now I am reading Categories for the Working Mathematician and just can't go further 50-60 pages, cause for understanding rest of the book I must understand examples given in the book, and those are mainly from group theory, topology and functional analysis. As I am slightly familiar with any, first I need to learn some other mathematics. So if you are rather programmer than mathematician, I think you'd better start with book I mentioned above. Otherwise you should stock up with lots of books about less abstract mathematics =) With best regards, Nick ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] recommendations for reading list?
2010/9/8 Benedict Eastaugh ionf...@gmail.com 2010/9/9 Николай Кудасов crazy.fiz...@gmail.com: Consider this book: Basic Category Theory for Computer Scientists (Foundations of Computing) -- Benjamin C.Pierce Hi David, Николай Кудасов is quite right--Pierce's book is excellent. Apart from being a good introduction to category theory, it's worth buying for the fourth chapter alone, which is an annotated bibliography of textbooks, introductory articles and reference works on category theory. It would be an excellent guide to where to go next after finishing Basic Category Theory. Graham Hutton also taught a course on category theory at MGS 2010, and his slides are online. I found them quite enlightening, and they move at a good pace for a beginner, with an appropriate level of formality. http://www.cs.nott.ac.uk/~gmh/cat.html Category theorists tend to give lots of examples from abstract algebra, so a basic understanding of some algebraic structures is, I've found, a lot of help when trying to appreciate category-theoretic ideas. Hope this helps a little. Thank you Benedict, it does help a bit. I don't have really any significant exposure to abstract algebra either. I think that might help a bit. If only there was a resource like Khan's Academy for this stuff. (I don't think he goes in this direction for abstract math). Dave Benedict. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hackage on Linux
On Thu, Aug 26, 2010 at 5:02 AM, Don Stewart d...@galois.com wrote: marlowsd: If you look at the original Cabal design document[1], you'll see that one of the goals of Cabal was to be the glue that lets you convert an arbitrary Haskell library into a native package for a variety of systems - including MSIs on Windows. Indeed, I must admit when we were designing Cabal I thought that native packages would be the most common way that people would install Cabal packages, specifically because many systems already have a good package manager, and trying to bypass the system package manager would be a fundamental mistake. It turned out that cabal-install would be a lot more useful than I imagined, but the two systems are complementary: native packages are for installing globally, and cabal-install is for installing packages in your home directory. We also didn't know that Hackage would get so big, so quickly. So there's three levels of packages now: 1. absolutely vital: HP (now on every system) 2. native packaging of useful Haskell apps and libs (many on Debian, Arch, Gentoo, few elsewhere) 3. cabal-install: everything else, works everywhere. And it looks like many distros are learning towards just providing 1. natively. Those with more automation (Debian, Arch) do 2. as well, though it is less useful than we thought now that cabal-install is relatively stable. A new trend are tools like 'bauerbill' on Arch, which has a --hackage flag, that converts hackage to native packages on the fly. That's like teaching apt to grok hackage. It's interesting how its all sorting out. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Library packages are only interesting to me when it comes to application deployment. Things are greatly simplified when you DO NOT have shared libraries to contend with because the only person tracking dependencies is the developer. Go, for example, has no shared libraries, and the runtime fits in every binary. It does not even depend on libc. Go binaries call the system call interface of the kernel, and the net result is that I get to test my go code, deploy it, and not worry about the state of deployed go environments quite so much as I do in the presence of shared libraries. As such I think cabal-install is excellent in that it installs in the developer's home directory, because that's all I need in other environments as well. It's quite practical. People are obsessed with shared library support but I can not for the life of me figure out why. Dave ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hackage on Linux
On Thu, Aug 26, 2010 at 11:11 AM, Brandon S Allbery KF8NH allb...@ece.cmu.edu wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/26/10 10:23 , David Leimbach wrote: Go, for example, has no shared libraries, and the runtime fits in every binary. It does not even depend on libc. Go binaries call the system call interface of the kernel, and the net result is that I get to test my go code, deploy it, and not worry about the state of deployed go environments quite so much as I do in the presence of shared libraries. Um. That's a really good way to have all your programs stop working when the Linux kernel interface changes yet again (ABIs? We don't need no steenking ABIs! --- see in /usr/src/linux/Documentation). Solaris is similar; the only approved interface is via libc and you must link to it shared if you want your program to work across versions/releases. (Which is the reason shared library support is important. I personally like my programs to keep working.) So you have to keep the runtime as up to date as glibc? Sounds ok :-). Also, I don't know anyone that supports people updating kernels in linux in any sort of commercial setting for the very reason you just gave. Sounds like asking for trouble. In my experience, a kernel upgrade is taken pretty seriously, and not done without very good reason. Look at CentOS, it's on a pretty old kernel most of the time, because people in enterprise situations prefer stability over bleeding edge features. Dave - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkx2rmMACgkQIn7hlCsL25XmjACgmWne8rR0EYeeHIBZvp2gywLp KDMAoKLGedOj5Dy2GXBo+NLcbCGemhS8 =XBmS -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] can Haskell do everyting as we want?
On Wed, Aug 4, 2010 at 3:16 AM, Alberto G. Corona agocor...@gmail.comwrote: Just to clarify, I mean: Haskell may be seriously addictive. Sounds like a joke, but it is not. I do not recommend it for coding something quick and dirty. I use it for quick and dirty stuff all the time, mainly because what I want is often something that can be broken down into stages of processing, and pure functions are really nice for that. If I know the input is coming from a reliable enough stream (like a unix pipe to stdin) I can use functions like interact to create filters, or parse some input, and produce some output. It's pretty nice. 2010/8/4 Alberto G. Corona agocor...@gmail.com Before entering haskell, please read our disclaimer: http://www.haskell.org/pipermail/haskell-cafe/2010-June/079044.html You've been warned * * 2010/8/4 Zura_ x...@gol.ge As already noted here, Haskell is a general purpose language, but you should take it with a grain of salt. For instance, you can nail with a laptop (provided that you hit the place where a HDD is located), but you prefer a hammer :) One thing is if you do it only for enjoyment, in this case you can even develop 3D shooter game in Haskell, but when it comes to production/real world use, I think it is better to maintain right tool for the right job attitude. Regards, Zura Qi Qi-2 wrote: Is there anyone happen to come into any tasks that haskell is not able to achieve? -- View this message in context: http://old.nabble.com/can-Haskell-do-everyting-as-we-want--tp29341176p29342871.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Microsoft's Singularity Project and Haskell
Haskell's great and all but it does have a few warts when it comes to how much real trust one should put into the type system. Some compromises still exist like unsafePerformIO that you can't detect simply by looking at the types of functions. In order to live up to the hype and the marketing around Haskell, really things like unsafePerformIO should not be allowed at all. The type of unsafePerformIO $ fireTheMissles return 3 ::Int is just Int after all. Does Singularity also have such back doors? Dave On Sat, Jul 31, 2010 at 6:53 AM, Alberto G. Corona agocor...@gmail.comwrote: I guess that the house OShttp://www.google.com/search?hl=ensafe=offq=+house+OS+haskellaq=faqi=g-sx7aql=oq=gs_rfai=has no one of these problems that singularity tries to solve in the first place. The problem of general OSs is: we have unsafe code, so what we do to deal with it?. The usual option is the isolation trough virtual addresses so that every pointer address is virtual. This imposes cost in task switching and pointer handling. The singularity alternative seems to be to check the managed code for pointer violations at installation time. In singularity they pretend to extend the reach of types, defined in .NET at the assembly level for inter program and inter language safety, to the OS level for runtime safety. This goal is interesting, because a well defined type system, without unsafe operations permitted, managed at the OS level could permit pure code to run wildly in real memory very fast, for example. With effects defined in the type system the advantages may be greater. 2010/7/31 Tim Matthews tim.matthe...@gmail.com SPJ http://research.microsoft.com/en-us/people/simonpj/default.aspx and probably many others are actually employed at Microsoft research centers. It looks like Microsoft just hasn't been able to find a suitable spot to push Haskell. Haskell influenced F# because they needed a functional language that targeted CLR, and included OO and mutable data. IMO Haskell is even better than their languages Maybe so but singularity actually provides the whole os apis via clr interfaces compared to mainstream windows os where the underlying apis are all in C, C++ and COM. The common intermediate language is not tied to any specific programming language such as C# or VB, it's more generic than that, and has it's advantages. Safety is something they wish to achieve but afaik their main goal is to write an OS in managed code. Haskell does provide a safe runtime but afaik unlike the clr it's tied to the haskell language. I think there has also been some attempts to write an OS in haskell too though, but that's another story... ___ 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Actors and message-passing a la Erlang
On Tue, Jul 27, 2010 at 5:27 AM, Stefan Schmidt stefanschmid...@googlemail.com wrote: Hi Yves, You say that With the help of this library it is possible to build Erlang-Style mailboxes, but how would you solve the issue of static typing? this wasn't an issue for me because I wanted as much type checking as possible. In many implementations, you have an implicit contract between the sender and the receiver process. In this case, the contract is explicit and the compiler can tell me if I'm trying to send or receive wrong data. I've found that I like Erlang's pattern matching for sorting through different kinds of data payloads, but that I prefer to use typed data channels per Limbo, Go, Plan 9's thread and messaging libraries etc. I've often wanted an Erlang with static typing to get this capability. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A question about State Monad and Monad in general
On Thu, Jul 15, 2010 at 9:02 AM, C K Kashyap ckkash...@gmail.com wrote: Hi, I looked at State Monad yesterday and this question popped into my mind. From what I gather State Monad essentially allows the use of Haskell's do notation to invisibly pass around a state. So, does the use of Monadic style fetch us more than syntactic convenience? Again, if I understand correctly, in Mutable Arrays also, is anything getting modified in place really? If not, what is the real reason for better efficiency? Syntactic convenience is important, and allows for the separation of logic into different modular pieces. The do notation is totally independent of the Monad in question's behavior. You can even roll your own Monad if you wish, and the do notation will work. Consider if you had a big data structure that you had to pass around all the different versions of in a series of functions. Then consider what happens when you decide that some of your data has to change later as your program evolves over time. Having to change the state that's being threaded around is quite a pain when it can be done transparently at the Monad definition level. Monads let you define the stuff that's going on between statements of do syntax. Some say it's the equivalent of overriding a fictional ; operator for sequencing imperative looking code statements. There's much power to be had here, and because of this analogy, it's easy to see why Monads are a good place to implement an embedded specific sublanguage in Haskell. I also think that because you're writing the glue between statements when you implement a Monad that it could be why some people (myself included) sometimes have a difficult time thinking of how to implement a particular Monad. Monads also allow you to package up pure data values with some computational activities that might have side effects and logically separate them. This allows one to unwrap a value from a monadic environment and pass it to pure functions for computation, then re-inject it back into the monadic environment. Monads are a good place to store side-effectful code, because they allow you to get away with causing a side effect and using some of those unwrapped monadic values in your pure code. They are an interface between two worlds in this respect. Monads are a good place, therefore, to implement code that does do in-place updates of values because they help the functional programmer deal with the issues of sequencing as well as interfacing side-effect-having and pure code and how to express dependencies between these two worlds. Dave -- Regards, Kashyap ___ 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] A question about State Monad and Monad in general
On Thu, Jul 15, 2010 at 10:34 AM, C K Kashyap ckkash...@gmail.com wrote:
Thanks David for the detailed explanation.
A couple of quick clarifications -
1. Even the invisible state that gets modified during the monadic
evaluation is referred to as side effect right?
If the state is free of types that allow for side effects then the state
threaded through a state monad is also free from side effects. If the state
contains some IO type, which allows for side effects, for example, that
state is affected by outside influences and is no longer pure.
Non-monadic example:
foo :: Int
foo = let state1 = 1
state2 = state1 + 3
state3 = state2 + state1
in state3 + 9
Each of those states are really just labels on a stage of computation that's
been done so far up to a final expression which is the result of the
function foo being called. In the end, this function is just a fancy way
of saying 14 is an Int and foo could have been replaced with a let foo=14 in
some other expression.
This is a pure function with what looks like states updating a value to
produce a new state. That's more akin to what happen in the state monad.
At no time is a previous state truly overwritten as that could be
considered a side effect.
Here's a state monad like example of the same:
foo :: Int
foo = (flip execState) 1 $ do {
state1 - get;
modify (+3);
state2 - get;
put (state2 + state1);
modify (+9)
}
2. I am a little unclear about in-place - does pure Haskell let one do
such a thing- or does it need to be done using FFI only?
Pure haskell does not allow for in place update of values because that would
violate the definition of purity. That said, there are ways to update
values in place with Haskell, ideally with Monads to control and sequence
those side effects.
Example here:
http://www.haskell.org/haskellwiki/Monad/ST
The ST monad allows one to describe a thread of computation which can update
some mutable state and then exchange it with the pure world of normal
Haskell computation.
Dave
On Thu, Jul 15, 2010 at 10:48 PM, David Leimbach leim...@gmail.comwrote:
On Thu, Jul 15, 2010 at 9:02 AM, C K Kashyap ckkash...@gmail.com wrote:
Hi,
I looked at State Monad yesterday and this question popped into my mind.
From what I gather State Monad essentially allows the use of Haskell's do
notation to invisibly pass around a state. So, does the use of Monadic
style fetch us more than syntactic convenience?
Again, if I understand correctly, in Mutable Arrays also, is anything
getting modified in place really? If not, what is the real reason for better
efficiency?
Syntactic convenience is important, and allows for the separation of logic
into different modular pieces. The do notation is totally independent of
the Monad in question's behavior. You can even roll your own Monad if you
wish, and the do notation will work. Consider if you had a big data
structure that you had to pass around all the different versions of in a
series of functions. Then consider what happens when you decide that some
of your data has to change later as your program evolves over time. Having
to change the state that's being threaded around is quite a pain when it can
be done transparently at the Monad definition level.
Monads let you define the stuff that's going on between statements of do
syntax. Some say it's the equivalent of overriding a fictional ; operator
for sequencing imperative looking code statements. There's much power to be
had here, and because of this analogy, it's easy to see why Monads are a
good place to implement an embedded specific sublanguage in Haskell.
I also think that because you're writing the glue between statements when
you implement a Monad that it could be why some people (myself included)
sometimes have a difficult time thinking of how to implement a particular
Monad.
Monads also allow you to package up pure data values with some
computational activities that might have side effects and logically separate
them. This allows one to unwrap a value from a monadic environment and pass
it to pure functions for computation, then re-inject it back into the
monadic environment.
Monads are a good place to store side-effectful code, because they allow
you to get away with causing a side effect and using some of those unwrapped
monadic values in your pure code. They are an interface between two worlds
in this respect. Monads are a good place, therefore, to implement code that
does do in-place updates of values because they help the functional
programmer deal with the issues of sequencing as well as interfacing
side-effect-having and pure code and how to express dependencies between
these two worlds.
Dave
--
Regards,
Kashyap
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo
Re: [Haskell-cafe] What is Haskell unsuitable for?
On Thu, Jun 17, 2010 at 11:57 AM, Darrin Chandler dwchand...@stilyagin.comwrote: On Thu, Jun 17, 2010 at 01:38:23PM -0500, aditya siram wrote: Judging by the other thread, getting hired might be a valid answer here... No argument there - I'm even afraid to stick it on my resume. At least Clojure can be snuck into the JVM without people noticing - Haskell, unfortunately, is not that shy. I am sad that I can't use cool languages in the boring, mainstream corporate jobs that are easy to find. If you want to use cool languages, you may have to get a cool job. I know: it's easy to say and harder to accomplish. -- Darrin Chandler| Phoenix BSD User Group | MetaBUG dwchand...@stilyagin.com | http://phxbug.org/ | http://metabug.org/ http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe I would never look at a resume when reviewing people to hire, see an exotic programming language, and draw negative conclusions about that candidate. In fact, I've found that learning to solve problems from different solution spaces in general is a worthwhile mental exercise, and helps one to come up with possibly better solutions in the mainstream languages. Sometimes breadth of experience is a good thing. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Language Shootout reverse-complement benchmark
I'm still trying to figure out what the point of the shootout really is. If there's no dedicated folks working with a language there, trying to make things run faster, a language will come out looking inefficient potentially. There's a lot of compile flags and optimizations that can make a difference in probably all of the languages listed on that page. I guess all you can get from the shootout is a sense of what a particular language or set of tools is capable of in the hands of the programmers who submit implementations. It doesn't really give you a concrete idea as to how to evaluate a programming language. It does still seem kind of fun for some reason though :-) Dave On Mon, May 31, 2010 at 5:47 PM, Louis Wasserman wasserman.lo...@gmail.comwrote: Hey, I was looking at the reverse-complement benchmark on the Language Shootout, and among other things, I noticed that the Haskell implementation was using (filter (/= '\n')) on ByteStrings, and also using lists as queues. I had a few improvements which using -fasm seem to yield about a 19% improvement in speed, and a 35% reduction in allocation, on my computer. (If both programs are compiled with -fllvm -- I'm not sure whether or not that's fair game on the Shootout -- my implementation is 35% faster, and does 10% less allocation.) I've checked my code on the Shootout's test input, as well. Mostly, the improvement comes from a tightly specialized version of (filter (/= '\n')), although eliminating an intermediate list entirely (and one used in a queuelike fashion) didn't seem to hurt. I managed to cut the program to a point where the program size is about the same as before. The code is at http://hpaste.org/fastcgi/hpaste.fcgi/view?id=25865; the previous implementation is at http://shootout.alioth.debian.org/u32/program.php?test=revcomplang=ghcid=2 . Let the arguing begin? Louis Wasserman wasserman.lo...@gmail.com http://profiles.google.com/wasserman.louis ___ 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] Wait forever in main thread
On Tue, May 18, 2010 at 7:08 AM, John Millikin jmilli...@gmail.com wrote: On Mon, May 17, 2010 at 19:41, David Leimbach leim...@gmail.com wrote: Is there not a way to multiplex the signal handlers into one thread, and then dispatch new threads to do the work when events that require such concurrency occur? That would be the initial way I'd structure such a program. All signals, method calls, method returns, etc are read from the socket in a single thread. If some computation needs to be performed, a thread is spawned. There's no thread pool, and I doubt such a construct would provide any benefit. I think you just said the same thing I just said. So are we arguing? I'm kind of confused. If some computation needs to be performed, a thread is spawned is very similar to what I just said about multiplexing the signal handling into one thread and spawning worker threads. I never mentioned a thread pool, and agree with you that it probably doesn't make any sense in this discussion. It might just be that I don't know anything about your DBus library that's causing this discussion to go this way. Let me look at it and get back to you. In fact, if the results of a computation based on a signal aren't even needed immediately, one could rely on the fact that Haskell is a non-strict language to partially evaluate an expression and get to it later when it's really needed. Haskell has built in Futures of a sort. That may not be appropriate depending on the processing at hand, but it's worth noting that it's possible. I'm not sure what partial evaluation has to do with anything under discussion. If received messages are processed in the same thread, then some long-running computation would block that thread (and, hence, message reception). This occurs regardless of exactly when the computation is performed, relative to its declaration. Removing the fork from within the signal/method dispatcher would simply force every user to write forkIO $ ... everywhere. When I think of Haskell, I think of laziness and partial evaluation, so to me it's always on topic. Maybe that's because I've been bitten by assuming strictness where it doesn't exist and had ridiculously bad data leaks in my code as a result. What I've been trying to come to terms with is a way to leverage the laziness rather than constantly striving to turn it off so I get reasonable runtime footprint of my Haskell programs. Dave ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Wait forever in main thread
On Tue, May 18, 2010 at 8:06 AM, David Leimbach leim...@gmail.com wrote: On Tue, May 18, 2010 at 7:08 AM, John Millikin jmilli...@gmail.comwrote: On Mon, May 17, 2010 at 19:41, David Leimbach leim...@gmail.com wrote: Is there not a way to multiplex the signal handlers into one thread, and then dispatch new threads to do the work when events that require such concurrency occur? That would be the initial way I'd structure such a program. All signals, method calls, method returns, etc are read from the socket in a single thread. If some computation needs to be performed, a thread is spawned. There's no thread pool, and I doubt such a construct would provide any benefit. I think you just said the same thing I just said. So are we arguing? I'm kind of confused. If some computation needs to be performed, a thread is spawned is very similar to what I just said about multiplexing the signal handling into one thread and spawning worker threads. I never mentioned a thread pool, and agree with you that it probably doesn't make any sense in this discussion. It might just be that I don't know anything about your DBus library that's causing this discussion to go this way. Let me look at it and get back to you. I've taken a few minutes to look through the documentation and dbus-core stuff on Hackage (quite nice by the way!!!), and I get where this is all going finally. The original poster of this thread asked a generic question about making a thread wait and synchronize with another, but the thread in question didn't do anything so I could not figure out why on earth anyone would want to do that. I think I see now that your library takes registered handlers to run and that there is nothing to be done in the main thread if you're just gathering events and dealing with them in each handler thread. For the application at hand, you're correct on all points. I was trying to have a more general discussion of what might be possible in other frameworks assuming nothing about their design. Sorry if I derailed the thread. At least it's given me a couple of ideas for things to try out, and I learned a little something about DBus. Dave ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Wait forever in main thread
On Mon, May 17, 2010 at 10:04 AM, DPX-Infinity dpx.infin...@gmail.comwrote: Hi, I'm writing a program which listens to some D-Bus signals using DBus.Client.onSignal function from dbus-client package. This function runs IO action in separate haskell thread when signal is received. My program does nothing except signal handling, so after setting up signals it has to wait indefinitely. Now I'm using not very clean (I think so) forever $ threadDelay 1000 . Is there another (I mean, correct) method to do this thing? You could ask yourself why you need a child thread if the main thread doesn't do anything else. I presume you're at a step in the development of something larger and that you'll eventually have a use for the main thread... otherwise the child thread is buying you nothing. Dave ___ 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] Wait forever in main thread
On Mon, May 17, 2010 at 2:37 PM, John Millikin jmilli...@gmail.com wrote: Author of dbus-client here. Don Stewart's solution (blocking on an mvar) is the best way to handle it. Presumably, you've got some way to make your program shut down (method call? signal handler?) -- just set the mvar in that. On Mon, May 17, 2010 at 11:07, David Leimbach leim...@gmail.com wrote: You could ask yourself why you need a child thread if the main thread doesn't do anything else. I presume you're at a step in the development of something larger and that you'll eventually have a use for the main thread... otherwise the child thread is buying you nothing. Dave DBus is an asynchronous protocol; running signal handlers in a common thread would let one long-running computation block receipt of any others. Is there not a way to multiplex the signal handlers into one thread, and then dispatch new threads to do the work when events that require such concurrency occur? That would be the initial way I'd structure such a program. In fact, if the results of a computation based on a signal aren't even needed immediately, one could rely on the fact that Haskell is a non-strict language to partially evaluate an expression and get to it later when it's really needed. Haskell has built in Futures of a sort. That may not be appropriate depending on the processing at hand, but it's worth noting that it's possible. Dave ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
On Sat, May 15, 2010 at 8:42 AM, Limestraël limestr...@gmail.com wrote: Okay, guess I'll have to bring out the chapter 25 of my Real World Haskell... I find it's often the most practical chapter that I hit a lot during writes and changes to my server process I have in Haskell in our control system code :-) That plus the information that I had missed that Control.Monad.State defaulted to the Lazy version (which is consistent, but for some reason it got by me) helped me to realize why I was leaking so much space in a garbage collected environment. I wouldn't have gotten very far with Haskell as this piece of our code without that chapter. I'd love to see more writing of that sort around Haskell in book form. One can become fluent in tuning Haskell by trial and error, but the sharp corners one must bump into are often sharper than in other languages I've found. Dave 2010/5/15 Bulat Ziganshin bulat.zigans...@gmail.com Hello Limestraėl, Saturday, May 15, 2010, 7:02:38 PM, you wrote: But when I set my beat to tick every 60 times per second, the position is well updated, but I clearly see that the display dramatically slows down after a few seconds of execution. Too heavy rate for integrate? it may be due to lot of uncollected garbage that is result of lazy evaluation. profile program to check its GC times -- Best regards, Bulatmailto:bulat.zigans...@gmail.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
[Haskell] Re: [Haskell-cafe] ANN: Monad.Reader Issue 16
On Wed, May 12, 2010 at 7:24 PM, Edward Z. Yang ezy...@mit.edu wrote: Excerpts from Brent Yorgey's message of Wed May 12 14:12:53 -0400 2010: I am very pleased to announce that Issue 16 of The Monad.Reader is now available [1]. Excellent news! Looking forward to reading. I'm trying the Iteratee examples, and everything is fine in this issue up to the point where it gets to IO and the lifting. I'm afraid my brain must be too small for figuring out the right syntax to make the 'throbber' do anything. Dave Cheers, Edward ___ Haskell-Cafe mailing list haskell-c...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] ANN: Monad.Reader Issue 16
On Wed, May 12, 2010 at 7:24 PM, Edward Z. Yang ezy...@mit.edu wrote: Excerpts from Brent Yorgey's message of Wed May 12 14:12:53 -0400 2010: I am very pleased to announce that Issue 16 of The Monad.Reader is now available [1]. Excellent news! Looking forward to reading. I'm trying the Iteratee examples, and everything is fine in this issue up to the point where it gets to IO and the lifting. I'm afraid my brain must be too small for figuring out the right syntax to make the 'throbber' do anything. Dave Cheers, Edward ___ 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] Location of library documentation with 6.12.1?
Those libraries are not distributed with the compiler. Use either The Haskell Platform, or hackage to get those packages. On Saturday, May 1, 2010, Roly Perera roly.per...@dynamicaspects.org wrote: Hi, I've just upgraded from 6.10.1 to 6.12.1 and can't seem to find all the library documentation. This page is apparently the documentation root: http://www.haskell.org/ghc/docs/6.12.1/html/ but if I click through to the Haskell Hierarchical Libraries page http://www.haskell.org/ghc/docs/6.12.1/html/libraries/index.html I can't for example find Control.Monad.State. I guess I'm missing something obvious about how things are organised? thanks in advance, Roly ___ 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] The instability of Haskell libraries
On Fri, Apr 23, 2010 at 12:17 PM, John Goerzen jgoer...@complete.orgwrote: Don Stewart wrote: I'll just quickly mention one factor that contributes: * In 2.5 years we've gone from 10 libraries on Hackage to 2023 (literally!) That is a massive API to try to manage, hence the continuing move to focus on automated QA on Hackage, and automated tools -- no one wants to have to resolve those dependencies by hand. Yep, it's massive, and it's exciting. We seem to have gone from stodgy old language to scrappy hot one. Which isn't a bad thing at all. Out of those 2023, there are certain libraries where small changes impact a lot of people (say base, time, etc.) I certainly don't expect all 2023 to be held to the same standard as base and time. We certainly need to have room in the community for libraries that change rapidly too. I'd propose a very rough measuring stick: anything in the platform ought to be carefully considered for introducing incompatibilities. Other commonly-used libraries, such as HaXML and HDBC, perhaps should fit in that criteria as well. I feel your pain John... I try to use Haskell commercially, and sometimes run into things I'm either going to have to re-implement myself or wait for a fix and do some workaround. Luckily I *like* this language enough to care to do it, but it does present a bit of a problem when trying to break it into an ecosystem full of C/C++ and Java when I have to back-peddle to explain why something in this new language that's supposed to help solve some problems with the old languages is not a magic bullet. I think managers expect magic bullets and holy grails... sometimes they just end up with holy cow's (or other more interesting 4 letter words) instead. Dave -- John ___ 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] Re: Haskellers hate GUIs!!
Never been a fan of GTK myself, but that's because I was a KDE developer I guess :-). Having said that, are there any plans to make it really easy to get gtk2hs working on Mac OS X? Dave On Fri, Apr 2, 2010 at 6:34 AM, Andy Stewart lazycat.mana...@gmail.comwrote: Hi Jürgen, For GHC-6.12, just darcs version support. So please download darcs version. Axel has working on that make gtk2hs build on cabal. And i'm working on update All gtk2hs API to Gtk+ 2.18.3 (have finish 99%), i can finish all APIs in later days. Axel have finish some sub-modules on http://www2.in.tum.de/~simona/ (Note, above cabal packages not include patches i push recently) After we finsh work, we can merge gtk2hs into Haskell Platform. Because gtk2hs just interface code for low-level C library, so it's stable enough. As recently so much new code push in gtk2hs, perhaps have bug. So please report any problem on gtk2hs mail-list, we can fix it as soon as we can. -- Haskller GUI lover Jürgen Nicklisch-Franken j...@arcor.de writes: I am in the damned position to have tried to develop a GUI app in Haskell. I'm building on top of gtk2hs, now we have a new compiler version a new Platform release and no gtk2hs release, so I cite from a mail from a potential user/contributor for my GUI app. What shall I say, how should he install gtk2hs? Is their a way to get a stable version from a changing darcs repo? If not all Haskellers were such GUI haters, we would have GUI libs with the platform. Jürgen ... Each gtk2hs package (like glib-0.10.1) installed in that non-standard location by Ubuntu apt-get does at least have a package.conf file, like glib.package.conf. However, on inspection, the id fields are missing, and the depends fields look more like .cabal file depends fields (no ABI ID). I tried an experiment on my glib.package.conf, used ghc --abi-hash to generate an ID, so eventually creating a new line something like id: glib-0.10.1-d41d8cd98f00b204e9800998ecf8427e and then set up the depends properly by getting the real dependencies using ghc-pkg -v list. After doing this then ghc-pkg register glib.package.conf worked just fine, and I see it in my global DB. It's cool that this works but it seems highly roundabout. :-) Building gtk2hs from source is broken. Not sure why - I did it OK with ghc-6.10.3. I can run ./configure no problem with ./configure --with-hcflags=-O0 --disable-split-objs --with-ghc=/usr/local/lib/ghc-6.12.1 and it claims that it will build: * The following packages will be built: * * glib : yes * gtk: yes * gio: yes * glade : yes * cairo : yes * svgcairo : yes * gtkglext : no * gconf : yes * sourceview : no * gtksourceview2 : yes * mozembed : no * soegtk : yes * gnomevfs : no * gstreamer : yes * documentation : no But make fails horribly...can't find any packages like base that configure had no problems finding, so I have no idea what the problem is there. Which is why I'd rather figure out a way to make ghc-6.12.1 recognize the gtk2hs packages that I have in that non-standard location. It works but it's awkward. :-) Each gtk2hs package (like glib-0.10.1) installed in that non-standard location by Ubuntu apt-get does at least have a package.conf file, like glib.package.conf. However, on inspection, the id fields are missing, and the depends fields look more like .cabal file depends fields (no ABI ID). I tried an experiment on my glib.package.conf, used ghc --abi-hash to generate an ID, so eventually creating a new line something like id: glib-0.10.1-d41d8cd98f00b204e9800998ecf8427e and then set up the depends properly by getting the real dependencies using ghc-pkg -v list. After doing this then ghc-pkg register glib.package.conf worked just fine, and I see it in my global DB. It's cool that this works but it seems highly roundabout. :-) I think I'll pack it in for the evening. The procedure I described works well in theory, but apparently if the depends field in the package conf files says something like foo-2.0.1.0, it's not OK to use
Re: [Haskell-cafe] Re: Haskellers hate GUIs!!
On Fri, Apr 2, 2010 at 10:31 AM, Anthony Cowley acow...@seas.upenn.eduwrote: On Fri, Apr 2, 2010 at 12:53 PM, Dominic Espinosa dces...@fastmail.fm wrote: Is there a general strategy for deploying Haskell apps, graphical or no, to MacOS X and/or Windows? I'm especially interested in cases where the application uses some heavyweight libraries like OpenGL. I have a GUI app that I deploy on Mac and Linux that uses OpenGL and wxHaskell. It has been a pretty good experience, but getting wx set up on every development machine is hairier than cabal install. The good news is that it was easy to set up a pure GLUT front end as well as a wx one that both use the same OpenGL code for rendering graphically intensive bits. I just have two build targets to switch between the two. For general cross-platform GUI apps that I need in a pinch, I turn to PLT Scheme. They have a really excellent system in this regard. Yeah PLT is pretty awesome... But I think they're calling it Racket now. :-) http://www.plt-racket.org/new-name.html Anthony ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Do I need to roll my own?
I'm looking at iteratee as a way to replace my erroneous and really inefficient lazy-IO-based backend for an expect like Monad DSL I've been working for about 6 months or so now on and off. The problem is I want something like: expect some String send some response to block or perhaps timeout, depending on the environment, looking for some String on an input Handle, and it appears that iteratee works in a very fixed block size. While a fixed block size is ok, if I can put back unused bytes into the enumerator somehow (I may need to put a LOT back in some cases, but in the common case I will not need to put any back as most expect-like scripts typically catch the last few bytes of data sent before the peer is blocked waiting for a response...) Otherwise, I'm going to want to roll my own iteratee style library where I have to say NotDone howMuchMoreIThinkINeed so I don't over consume the input stream. Does that even make any sense? I'm kind of brainstorming in this email unfortunately :-) Dave ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: iteratee: Do I need to roll my own?
First thanks for the reply,
On Wed, Mar 31, 2010 at 11:15 AM, Valery V. Vorotyntsev valery...@gmail.com
wrote:
I'm looking at iteratee as a way to replace my erroneous and really
inefficient lazy-IO-based backend for an expect like Monad DSL I've
been working for about 6 months or so now on and off.
The problem is I want something like:
expect some String
send some response
to block or perhaps timeout, depending on the environment, looking for
some String on an input Handle, and it appears that iteratee works
in a very fixed block size.
Actually, it doesn't. It works with what enumerator gives him.
In case of `enum_fd'[1] this is a fixed block, but generally this is
a ``value'' of some ``collection''[2]. And it is up to programmer to
decide of what should become a value.
[1] http://okmij.org/ftp/Haskell/Iteratee/IterateeM.hs
[2] http://okmij.org/ftp/papers/LL3-collections-enumerators.txt
While a fixed block size is ok, if I can put back unused bytes into
the enumerator somehow (I may need to put a LOT back in some cases,
but in the common case I will not need to put any back as most
expect-like scripts typically catch the last few bytes of data sent
before the peer is blocked waiting for a response...)
I don't quite get this ``last few bytes'' thing. Could you explain?
What I mean is let's say the stream has
abcd efg abcd efg
and then I run some kind of iteratee computation looking for abcd
and the block size was fixed to cause a read 1024 bytes, but returns as much
as it can providing it to the iteratee to deal with. The iteratee, which I
want to implement Expect like behavior, would really only want to read up to
abcd consuming that from the input stream. Does the iteratee get the
whole stream that was read by the enumerator, or is it supplied a single
atomic unit at a time, such as a character, in which I can halt the
consumption of the streamed data?
What I don't want to have happen is my consuming bytes from the input
Handle, only to have them ignored, as the second instance of abcd could be
important.
I'm actually not sure that was very clear :-). I don't want to throw out
bytes by accident if that's even possible.
My discomfort with Iteratee is that most Haskell texts really want you to go
the way of lazy IO, which has led me to a good bit of trouble, and I've
never seen a very comprehensive tutorial of Iteratee available anywhere. I
am reading the Examples that come with the hackage package though.
I was about writing that there is no problem with putting data back to
Stream, and referring to head/peek functions... But then I thought,
that the ``not consuming bytes from stream'' approach may not work
well in cases, when the number of bytes needed (by your function to
accept/reject some rule) exceeds the size of underlying memory buffer
(4K in current version of `iteratee' library[3]).
[3]
http://hackage.haskell.org/packages/archive/iteratee/0.3.4/doc/html/src/Data-Iteratee-IO-Fd.html
Do you think that abstracting to the level of _tokens_ - instead of
bytes - could help here? (Think of flex and bison.) You know, these
enumerators/iteratees things can be layered into
_enumeratees_[1][4]... It's just an idea.
Now that's an interesting idea, and sort of where my previous confusing
answer seemed to be heading. I wasn't sure if the iteratee was provided a
byte, a char, or a token. If I can tell the enumerator to only send tokens
to the iteratee, (which I'd have to define), then perhaps I can ignore the
amount consumed per read, and deal with let the enumerator deal with that
buffering issue directly. Perhaps that's how iteratee really works anyway!
[4] http://ianen.org/articles/understanding-iteratees/
Otherwise, I'm going to want to roll my own iteratee style library
where I have to say NotDone howMuchMoreIThinkINeed so I don't over
consume the input stream.
What's the problem with over-consuming a stream? In your case?
Well my concern is if it's read from the input stream, and then not used,
the next time I access it, I'm not certain what's happened to the buffer.
However I suppose it's really a 2-level situation where the enumerator
pulls out some fixed chunk from a Handle or FD or what have you, and then
folds the iteratee over the buffer in some sized chunk.
In C++ I've used ideas like this example that a professor I had in college
showed me from a newsgroup he helped to moderate.
int main () {
std::cout Word count on stdin:
std::distance(std::istream_iteratorstd::string(std::cin),
std::istream_iteratorstd::string()) std::endl;
}
If the code were changed to be:
int main () {
std::cout Character count on stdin:
std::distance(std::istreambuf_iteratorchar(std::cin),
std::istreambuf_iteratorchar()) std::endl;
}
We get different behavior out of the upper level distance algorithm due to
the kind of iterator, while distance does a form of folding over the
iterators, but it's actually
Re: [Haskell-cafe] Do I need to roll my own?
On Wed, Mar 31, 2010 at 12:02 PM, Gregory Collins
g...@gregorycollins.netwrote:
David Leimbach leim...@gmail.com writes:
to block or perhaps timeout, depending on the environment, looking for
some String on an input Handle, and it appears that iteratee works
in a very fixed block size. While a fixed block size is ok, if I can
put back unused bytes into the enumerator somehow (I may need to put a
LOT back in some cases, but in the common case I will not need to put
any back as most expect-like scripts typically catch the last few
bytes of data sent before the peer is blocked waiting for a
response...)
See IterGV from the iteratee lib:
http://hackage.haskell.org/packages/archive/iteratee/0.3.1/doc/html/Data-Iteratee-Base.html#t%3AIterGV
The second argument to the Done constructor is for the portion of the
input that you didn't use. If you use the Monad instance, the unused
input is passed on (transparently) to the next iteratee in the chain.
If you use attoparsec-iteratee
(
http://hackage.haskell.org/packages/archive/attoparsec-iteratee/0.1/doc/html/Data-Attoparsec-Iteratee.html
),
you could write expect as an attoparsec parser:
{-# LANGUAGE OverloadedStrings #-}
import Control.Applicative
import Control.Monad.Trans (lift)
import Data.Attoparsec hiding (Done)
import Data.Attoparsec.Iteratee
import qualified Data.ByteString as S
import Data.ByteString (ByteString)
import Data.Iteratee
import Data.Iteratee.IO.Fd
import Data.Iteratee.WrappedByteString
import Data.Word (Word8)
import System.IO
import System.Posix.IO
expect :: (Monad m) = ByteString
- IterateeG WrappedByteString Word8 m ()
expect s = parserToIteratee (p return ())
where
p = string s | (anyWord8 p)
dialog :: (Monad m) =
IterateeG WrappedByteString Word8 m a -- ^ output end
- IterateeG WrappedByteString Word8 m ()
dialog outIter = do
expect login:
respond foo\n
expect password:
respond bar\n
return ()
where
respond s = do
_ - lift $ enumPure1Chunk (WrapBS s) outIter = run
return ()
main :: IO ()
main = do
hSetBuffering stdin NoBuffering
hSetBuffering stdout NoBuffering
enumFd stdInput (dialog output) = run
where
output = IterateeG $ \chunk -
case chunk of
(EOF _)- return $ Done () chunk
(Chunk (WrapBS s)) - S.putStr s
hFlush stdout
return (Cont output Nothing)
Usage example:
$ awk 'BEGIN { print login:; fflush(); system(sleep 2); \
print password:; fflush(); }' | runhaskell Expect.hs
foo
bar
N.B. for some reason enumHandle doesn't work here w.r.t buffering, had
to go to POSIX i/o to get the proper buffering behaviour.
That's pretty neat actually. I'm going to have to incorporate timeouts
into something like that (and attoparsec-iteratee doesn't install for me for
some reason, I'll try again today).
That leads me to another question in another thread I'm about to start.
Dave
G
--
Gregory Collins g...@gregorycollins.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do I need to roll my own?
On Wed, Mar 31, 2010 at 12:24 PM, David Leimbach leim...@gmail.com wrote:
On Wed, Mar 31, 2010 at 12:02 PM, Gregory Collins g...@gregorycollins.net
wrote:
David Leimbach leim...@gmail.com writes:
to block or perhaps timeout, depending on the environment, looking for
some String on an input Handle, and it appears that iteratee works
in a very fixed block size. While a fixed block size is ok, if I can
put back unused bytes into the enumerator somehow (I may need to put a
LOT back in some cases, but in the common case I will not need to put
any back as most expect-like scripts typically catch the last few
bytes of data sent before the peer is blocked waiting for a
response...)
See IterGV from the iteratee lib:
http://hackage.haskell.org/packages/archive/iteratee/0.3.1/doc/html/Data-Iteratee-Base.html#t%3AIterGV
The second argument to the Done constructor is for the portion of the
input that you didn't use. If you use the Monad instance, the unused
input is passed on (transparently) to the next iteratee in the chain.
If you use attoparsec-iteratee
(
http://hackage.haskell.org/packages/archive/attoparsec-iteratee/0.1/doc/html/Data-Attoparsec-Iteratee.html
),
you could write expect as an attoparsec parser:
{-# LANGUAGE OverloadedStrings #-}
import Control.Applicative
import Control.Monad.Trans (lift)
import Data.Attoparsec hiding (Done)
import Data.Attoparsec.Iteratee
import qualified Data.ByteString as S
import Data.ByteString (ByteString)
import Data.Iteratee
import Data.Iteratee.IO.Fd
import Data.Iteratee.WrappedByteString
import Data.Word (Word8)
import System.IO
import System.Posix.IO
expect :: (Monad m) = ByteString
- IterateeG WrappedByteString Word8 m ()
expect s = parserToIteratee (p return ())
where
p = string s | (anyWord8 p)
dialog :: (Monad m) =
IterateeG WrappedByteString Word8 m a -- ^ output end
- IterateeG WrappedByteString Word8 m ()
dialog outIter = do
expect login:
respond foo\n
expect password:
respond bar\n
return ()
where
respond s = do
_ - lift $ enumPure1Chunk (WrapBS s) outIter = run
return ()
main :: IO ()
main = do
hSetBuffering stdin NoBuffering
hSetBuffering stdout NoBuffering
enumFd stdInput (dialog output) = run
where
output = IterateeG $ \chunk -
case chunk of
(EOF _)- return $ Done () chunk
(Chunk (WrapBS s)) - S.putStr s
hFlush stdout
return (Cont output Nothing)
Usage example:
$ awk 'BEGIN { print login:; fflush(); system(sleep 2); \
print password:; fflush(); }' | runhaskell Expect.hs
foo
bar
N.B. for some reason enumHandle doesn't work here w.r.t buffering, had
to go to POSIX i/o to get the proper buffering behaviour.
That's pretty neat actually. I'm going to have to incorporate timeouts
into something like that (and attoparsec-iteratee doesn't install for me for
some reason, I'll try again today).
worked fine today...
That leads me to another question in another thread I'm about to start.
And that other thread is not going to happen, because I realized I was just
having issues with non-strict vs strict evaluation :-) It makes perfect
sense now...
gist is:
timeout (10 ^ 6) $ return $ sum [1..]
and
timeout (10 ^ 6) $! return $ sum [1..]
will not timeout, and will hang while
timeout (10 ^ 6) $ return $! sum [1..]
does timeout... and everything in the Haskell universe is nice and
consistent.
Dave
Dave
G
--
Gregory Collins g...@gregorycollins.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Do I need to roll my own?
On Wed, Mar 31, 2010 at 2:12 PM, John Lato jwl...@gmail.com wrote: Hi Dave, From: David Leimbach leim...@gmail.com I'm looking at iteratee as a way to replace my erroneous and really inefficient lazy-IO-based backend for an expect like Monad DSL I've been working for about 6 months or so now on and off. The problem is I want something like: expect some String send some response to block or perhaps timeout, depending on the environment, looking for some String on an input Handle, and it appears that iteratee works in a very fixed block size. While a fixed block size is ok, if I can put back unused bytes into the enumerator somehow (I may need to put a LOT back in some cases, but in the common case I will not need to put any back as most expect-like scripts typically catch the last few bytes of data sent before the peer is blocked waiting for a response...) I'm quite sure I don't know what you're trying to do. The only time I can think of needing this is if you're running an iteratee on a file handle, keeping the handle open, then running another iteratee on it. Is this what you're doing? If so, I would make a new run function: runResidue :: (Monad m, SC.StreamChunk s el) = IterateeG s el m a - m (a, s) runResidue iter = runIter iter (EOF Nothing) = \res - case res of Done x s - return (x, s) Cont _ e - error $ control message: ++ show e This function will return the unused portion of the stream, then you can do this: enumResidue :: Handle - s - EnumeratorGM s el m a enumResidue h s = enumPure1Chunk s . enumHandle h Is this what you need? If I'm completely wrong about what you're trying to do (or you're using multiple threads), there are other options. The problem is I am not sure what it was I needed to get started to begin with. For a moment it seemed that I could be throwing out data that's been read, but not yet fed to an iteratee step. If that's not the case, I'll never need to put back any characters. The attoparsec-iteratee example posted, plus some experimentation has led me to believe I don't need to worry about this sort of thing for the kind of processing I'm looking to do. You also may want to look at iteratee-HEAD. The implementation has been cleaned up a lot, the block sizes are user-specified, and there's an exception-based, user-extensible mechanism for iteratees to alter enumerator behavior. That's very compelling. Here's the properties of the system I'm trying to build (in fact I've built this system with Haskell already months ago, but trying to evaluate if iteratee can fix problems I've got now) 1. Must have an expect-like language to a subprocess over a pair of Handles such that I can query what is normally a command line interface as a polling refresher thread to a cache. Note that there may be many sub-processes with a poller/cache (up to 6 so far). Data produced is dumped as records to stdout from each thread such that the process that spawned this haskell program can parse those records and update it's view of this particular part of the world. 2. Must be able to interleave commands between polled record data from the processes in 1. These commands come in over this process's stdin from the program that started the Haskell program. 3. The polling process in 1, must be able to respond to a timeout situation. In this system, a cable could become disconnected or a part of the system could become unavailable, or a part of the system underneath could become unreliable and require a restart to guarantee the serviceability of the whole system. I have 1 and 2 working fine in a current iteration of the system, but because we're dealing with a pretty complex stack, 3 is really necessary too, and I've conquered my timeout issues from earlier in a reasonable enough way. The problem is that the timeout handler apparently runs into problems that I think stem from lazyIO not having been evaluated on a handle yet, but the timeout handler has invalidated that handle, and then that thunk, which was partially applied, is now talking to some broken value. As far as I know, I can't go back and prevent previously bound thunks that have the wrong handle from executing, if that is truly what's happening. What I'd like to do is prevent that situation from ever happening to begin with, or at least rule it out. I'm hoping version 2 of this system to be based on iteratee and avoid this sort of problem at all. The alternative is to write this in another language, but that throws out a lot of nice and simple code that's present in the non IO bits of this code, for dealing with parsing and data serialization. Dave Sincerely, John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Are there any female Haskellers?
On Tue, Mar 30, 2010 at 4:13 AM, Alberto G. Corona agocor...@gmail.comwrote: . 2010/3/29 Jason Dusek jason.du...@gmail.com 2010/03/29 Alberto G. Corona agocor...@gmail.com: [...] What we evolved with is a general hability: to play with things to achieve what we need from them, (besides other abilities). The pleasure to acheve ends by using available means. [...] A tool is someting used to solve a class of problems. It does not matter if it is something phisical or conceptual. [...] The more general is a tool, the more we feel pleasure playing with it So the adaptation you are saying men have in greater degree than women is pleasure in tool using, broadly defined to include taming animals, debate, programming, sword play, carpentry and more? What are you attributing to men is not so much superiority of ability but greater motivation? -- Jason Dusek n terms of natural selection, greater motivation for and greater innate hability are both positiverly correlated in response to an evolutionary pressure (in beings that have learning capabilities). for example, cats are better at catching mouse, and they enjoy to play catching them. A live being end up developping better innate habilities (and is more motivation) for whatever practises more. This is called baldwin effect (some common general learning for the task end up fixed innately). Motivation match ability and viceversa. This is evolutionarily stable. It makes no evolutionary sense that woman and men have the same abilities and tendencias because they had different activities since before they were even humans. The brain has limited computation resources. The optimal behaviours and strategies are in many cases different for each sex. This happen for almost all the animal kingdom. Why humans would be different?. No matter they are very similar in some aspects, they are different and very different in others (fortunatelly). Nothing that your grandparent didn´t know. What does any of this have to do with Haskell? Please move this off list. ___ 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] ANN: Yi 0.6.2.2
Well I think I can never figure out what it is I can actually do with Yi once it's installed. Editing keys are nice, but doe it let me build modules or jump in and out of ghci? It's difficult at best to use tools with no manual. Dave On Wed, Mar 24, 2010 at 12:54 PM, Jeff Wheeler j...@nokrev.com wrote: On Wed, Mar 24, 2010 at 2:46 PM, Colin Paul Adams co...@colina.demon.co.uk wrote: Anyway it works. At least, I managed to find out to save a customised version with emacs key bindings. But there is not gtk support, apparently, and I can't find out how to get help. I haven't successfully gotten Gtk2Hs to compile since this update, but if you can, Yi's Pango (Gtk) frontend should work, um, reasonably. There's a #yi room on freenode, but it's usually pretty quiet. The project has been near death for a while; I hope this release gets it in front of a few more people, at the least. -- Jeff Wheeler Undergraduate, Electrical Engineering University of Illinois at Urbana-Champaign ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] Timeouts that don't cause data growth.
Trying to understand why the code here: http://moonpatio.com/fastcgi/hpaste.fcgi/view?id=8823#a8823 exhausts memory. I need to have timeouts in a program I'm writing that will run an interactive polling session of some remote resources, and know when to give up and handle that error. Unfortunately this code dies pretty quickly and produces an -hc graph like the one attached. It seems that System.Timeout can't be used for this. I should note that if the code is changed to use an inifnite timeout (-1) that this problem doesn't occur. Is this a bug in System.Timeout, or is there something I should be doing to keep the data size down? Dave timeouttest.ps Description: PostScript document ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Timeouts that don't cause data growth.
Is this just a problem of spawning too many forkIO resources that never
produce a result?
I was thinking of trying something like the following in System.Timeout's
place:
module Main where
import Control.Concurrent.MVar
import Control.Concurrent
import Data.Maybe
timeout :: Int - IO a - IO (Maybe a)
timeout time action = do
someMVar - newEmptyMVar -- MVar is a Maybe
timeoutThread - forkIO $ nothingIzer time someMVar
forkIO $ actionRunner action someMVar timeoutThread
takeMVar someMVar = return
where
nothingIzer time mvar = threadDelay time putMVar mvar Nothing
actionRunner action mvar timeoutThread = do
res - action
killThread timeoutThread
putMVar mvar $ Just res
main :: IO ()
main = do
res - timeout (5 * 10 ^ 6) (getLine = putStrLn)
case res of
Nothing - putStrLn Timeout
Just x - putStrLn Success
On Tue, Mar 23, 2010 at 11:31 AM, Roel van Dijk vandijk.r...@gmail.comwrote:
I tried a few things. First I added another timeout to main, so the
program kills itself after a few seconds.
doit :: IO (Maybe ())
doit = timeout 1200 $ {- yield -} return ()
main :: IO ()
main = do _ - timeout 500 $ forever doit
return ()
This program failed to terminate. But when I compiled -with threaded
and added a yield to doit, it worked (kinda). If the timeout in doit
is not too long, like 200 milliseconds, the program has constant space
usage. But when I increased the timeout in doit to 12 seconds I got a
stack overflow.
I'll investigate further when I have more time.
Regards,
Roel
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Timeouts that don't cause data growth.
Actually this isn't good enough either as I'm potentially leaving the
action thread in a state where it never times out... I guess I have to do
all thread killing in the main thread.
On Tue, Mar 23, 2010 at 12:23 PM, David Leimbach leim...@gmail.com wrote:
Is this just a problem of spawning too many forkIO resources that never
produce a result?
I was thinking of trying something like the following in System.Timeout's
place:
module Main where
import Control.Concurrent.MVar
import Control.Concurrent
import Data.Maybe
timeout :: Int - IO a - IO (Maybe a)
timeout time action = do
someMVar - newEmptyMVar -- MVar is a Maybe
timeoutThread - forkIO $ nothingIzer time someMVar
forkIO $ actionRunner action someMVar timeoutThread
takeMVar someMVar = return
where
nothingIzer time mvar = threadDelay time putMVar mvar Nothing
actionRunner action mvar timeoutThread = do
res - action
killThread timeoutThread
putMVar mvar $ Just res
main :: IO ()
main = do
res - timeout (5 * 10 ^ 6) (getLine = putStrLn)
case res of
Nothing - putStrLn Timeout
Just x - putStrLn Success
On Tue, Mar 23, 2010 at 11:31 AM, Roel van Dijk vandijk.r...@gmail.comwrote:
I tried a few things. First I added another timeout to main, so the
program kills itself after a few seconds.
doit :: IO (Maybe ())
doit = timeout 1200 $ {- yield -} return ()
main :: IO ()
main = do _ - timeout 500 $ forever doit
return ()
This program failed to terminate. But when I compiled -with threaded
and added a yield to doit, it worked (kinda). If the timeout in doit
is not too long, like 200 milliseconds, the program has constant space
usage. But when I increased the timeout in doit to 12 seconds I got a
stack overflow.
I'll investigate further when I have more time.
Regards,
Roel
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Timeouts that don't cause data growth.
On Tue, Mar 23, 2010 at 1:02 PM, Bas van Dijk v.dijk@gmail.com wrote: On Tue, Mar 23, 2010 at 8:23 PM, David Leimbach leim...@gmail.com wrote: Is this just a problem of spawning too many forkIO resources that never produce a result? It looks like it. Lets look at the implementation of timeout: timeout :: Int - IO a - IO (Maybe a) timeout n f | n 0= fmap Just f | n == 0= return Nothing | otherwise = do pid - myThreadId ex - fmap Timeout newUnique handleJust (\e - if e == ex then Just () else Nothing) (\_ - return Nothing) (bracket (forkIO (threadDelay n throwTo pid ex)) (killThread) (\_ - fmap Just f)) We see a thread is forked that throws the Timeout exception to the current thread after n microseconds. However when the current thread finishes early this timeout thread will be killed. I assume that when a thread is killed it can be garbage collected. (However we have to watch out for [1]) So it's a big surprise to me that we're seeing this space-leak! Maybe you can file a bug report? Seems like I should I was thinking of trying something like the following in System.Timeout's place: module Main where import Control.Concurrent.MVar import Control.Concurrent import Data.Maybe timeout :: Int - IO a - IO (Maybe a) timeout time action = do someMVar - newEmptyMVar -- MVar is a Maybe timeoutThread - forkIO $ nothingIzer time someMVar forkIO $ actionRunner action someMVar timeoutThread takeMVar someMVar = return where nothingIzer time mvar = threadDelay time putMVar mvar Nothing actionRunner action mvar timeoutThread = do res - action killThread timeoutThread putMVar mvar $ Just res main :: IO () main = do res - timeout (5 * 10 ^ 6) (getLine = putStrLn) case res of Nothing - putStrLn Timeout Just x - putStrLn Success The original timeout obeys the following specification: The design of this combinator was guided by the objective that timeout n f should behave exactly the same as f as long as f doesn't time out. This means that f has the same myThreadId it would have without the timeout wrapper. Any exceptions f might throw cancel the timeout and propagate further up. It also possible for f to receive exceptions thrown to it by another thread. They implement this by executing the action in the current thread. Yours executes the action in another thread. True, but mine's not leaking space! ;-) I think I can fix the action running in the other thread issue. regards, Bas [1] http://haskell.org/ghc/docs/latest/html/libraries/base-4.2.0.0/Control-Concurrent.html#t%3AThreadId ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Timeouts that don't cause data growth.
On Tue, Mar 23, 2010 at 1:06 PM, David Leimbach leim...@gmail.com wrote: On Tue, Mar 23, 2010 at 1:02 PM, Bas van Dijk v.dijk@gmail.comwrote: On Tue, Mar 23, 2010 at 8:23 PM, David Leimbach leim...@gmail.com wrote: Is this just a problem of spawning too many forkIO resources that never produce a result? It looks like it. Lets look at the implementation of timeout: timeout :: Int - IO a - IO (Maybe a) timeout n f | n 0= fmap Just f | n == 0= return Nothing | otherwise = do pid - myThreadId ex - fmap Timeout newUnique handleJust (\e - if e == ex then Just () else Nothing) (\_ - return Nothing) (bracket (forkIO (threadDelay n throwTo pid ex)) (killThread) (\_ - fmap Just f)) We see a thread is forked that throws the Timeout exception to the current thread after n microseconds. However when the current thread finishes early this timeout thread will be killed. I assume that when a thread is killed it can be garbage collected. (However we have to watch out for [1]) So it's a big surprise to me that we're seeing this space-leak! Maybe you can file a bug report? Seems like I should I was thinking of trying something like the following in System.Timeout's place: module Main where import Control.Concurrent.MVar import Control.Concurrent import Data.Maybe timeout :: Int - IO a - IO (Maybe a) timeout time action = do someMVar - newEmptyMVar -- MVar is a Maybe timeoutThread - forkIO $ nothingIzer time someMVar forkIO $ actionRunner action someMVar timeoutThread takeMVar someMVar = return where nothingIzer time mvar = threadDelay time putMVar mvar Nothing actionRunner action mvar timeoutThread = do res - action killThread timeoutThread putMVar mvar $ Just res main :: IO () main = do res - timeout (5 * 10 ^ 6) (getLine = putStrLn) case res of Nothing - putStrLn Timeout Just x - putStrLn Success The original timeout obeys the following specification: The design of this combinator was guided by the objective that timeout n f should behave exactly the same as f as long as f doesn't time out. This means that f has the same myThreadId it would have without the timeout wrapper. Any exceptions f might throw cancel the timeout and propagate further up. It also possible for f to receive exceptions thrown to it by another thread. They implement this by executing the action in the current thread. Yours executes the action in another thread. True, but mine's not leaking space! ;-) I think I can fix the action running in the other thread issue. Ok, that's a lot trickier than it looks, but you're still right; I don't expect the space leak either. What I did do was throw any exception caught in the actionThread back to the main thread to try to get it as close as I can to running in the main thread to begin with. I'll go ahead and file a bug, just as soon as I figure out where/how :-) Dave regards, Bas [1] http://haskell.org/ghc/docs/latest/html/libraries/base-4.2.0.0/Control-Concurrent.html#t%3AThreadId ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Timeouts that don't cause data growth.
cut The leak is caused by the Data.Unique library, and coincidentally it was fixed recently. 6.12.2 will have the fix. That's great! Thanks! I can get by with what I've got for now as a replacement. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Timeouts that don't cause data growth.
On Tue, Mar 23, 2010 at 4:04 PM, Bas van Dijk v.dijk@gmail.com wrote: On Tue, Mar 23, 2010 at 10:20 PM, Simon Marlow marlo...@gmail.com wrote: The leak is caused by the Data.Unique library, and coincidentally it was fixed recently. 6.12.2 will have the fix. Oh yes of course, I've reported that bug myself but didn't realize it was the problem here :-) David, to clarify the problem: newUnqiue is currently implemented as: newUnique :: IO Unique newUnique = do val - takeMVar uniqSource let next = val+1 putMVar uniqSource next return (Unique next) You can see that the 'next' value is lazily written to the uniqSource MVar. When you repeatedly call newUnique (like in your example) a big thunk is build up: 1+1+1+...+1 which causes the space-leak. In the recent fix, 'next' is strictly evaluated before it is written to the MVar which prevents a big thunk to build up. regards, Bas Thanks for this excellent description of what's going on. This whole thread has been a reminder of what makes the Haskell community truly excellent to work with. I appreciate everything you guys are doing! Dave ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bytestrings and [Char]
On Mon, Mar 22, 2010 at 6:10 AM, Johan Tibell johan.tib...@gmail.comwrote: On Mon, Mar 22, 2010 at 1:16 PM, Johann Höchtl johann.hoec...@gmail.com wrote: My question or discussion point: Why not depreciate [Char] altogether and favour of lazy Bytestrings? A sequence of bytes is not the same thing as a sequence of Unicode code points. If you want to replace String by something more efficient have a look at Data.Text. Slight correction. A sequence of bytes is exactly the same thing as a sequence of Unicode bytes when you use UTF8. -- 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] ANNOUNCE: attoparsec-iteratee v0.1
Sounds pretty good and applicable to a system I've been trying to implement. I've been trying to understand Iteratee, and it seems like a way of fusing some of the parsing with some of the IO in a fairly safe way. Is this a correct way to think of it? Dave On Fri, Mar 12, 2010 at 6:25 PM, Gregory Collins g...@gregorycollins.netwrote: Hi all, I've just uploaded the first version of the attoparsec-iteratee library to Hackage: http://hackage.haskell.org/package/attoparsec-iteratee It takes applicative parsers written using attoparsec and automagically converts them to iteratees that can parse things from streams in O(1) space. and the combination is fast: a prototype HTTP server I'm working on uses this library and can handle as many as 13k reqs/sec on my Macbook. G -- Gregory Collins g...@gregorycollins.net ___ 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] Space leak
On Sat, Mar 13, 2010 at 3:58 PM, Arnoldo Muller arnoldomul...@gmail.comwrote: Jason, I am trying to use haskell in the analysis of bio data. One of the main reasons I wanted to use haskell is because lazy I/O allows you to see a large bio-sequence as if it was a string in memory. In order to achieve the same result in an imperative language I would have to write lots of error-prone iterators. I saw lazy I/O as a very strong point in favor of Haskell. There's a safer lazy IO lib in Hackage: http://hackage.haskell.org/package/safe-lazy-io It seems the safer approach, though somewhat more confusing to some people, is the Iteratee pattern. The reasons why have probably been explained best on a paper on Oleg's site. Besides the space leaks that can occur and that are a bit difficult to find for a newbie like me, are there any other reasons to avoid Lazy I/O? Perhaps these two links will enlighten you. They did for me, and I'm now working out how exactly to convert a really inefficient but explicit IO program (char by char right now... yuck) to an Iteratee based parsing situation on a work-related project. Hopefully I'll be doing this all this coming week, and I'll be able to publish some results on my blog. (things come up though a lot at work, so I'm keeping my fingers crossed on this one). http://okmij.org/ftp/Haskell/Iteratee/Lazy-vs-correct.txt http://okmij.org/ftp/Streams.html Dave Arnoldo. On Sat, Mar 13, 2010 at 6:46 PM, Jason Dagit da...@codersbase.com wrote: On Thu, Mar 11, 2010 at 3:44 PM, Arnoldo Muller arnoldomul...@gmail.comwrote: Daniel, Thank you so much for helping me out with this issue! Thanks to all the other answers from haskel-cafe members too! As a newbie, I am not able to understand why zip and map would make a problem... Is there any link I could read that could help me to understand why in this case zip and map created a leak? What are some function compositions that should be avoided when doing lazy I/O? Actually, it's lazy I/O itself that should be avoided. Jason ___ 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] definition of sum
However, with optimisations turned on... GHC knows that sum is actually strict GHC does that when optimizations are turned on, but that behavior is not required by the Haskell standard. So there is no guarantee that any given compiler will produce usable output if you use foldl instead of foldl' for sum. In GHCi sum is broken, because optimizations are not in effect there. You have to define your own version of sum using foldl' for every GHCi session (or put it in your .ghci file). So it's a trade-off between a slight convenience in a bizarre corner case and general usability. I agree with Don that this is a bug in the Haskell 98 standard. I'm not sure whether it's a wart or a bug, but I agree that it would be better to have the default sum strict (and provide lazysum for the cases where it's useful). That would be really inconsistent with the way the rest of the Haskell language and libraries works. Note that foldl' has a ' to indicate that it's not the same as foldl exactly. I would propose that sum' exist as well as sum, and that sum be lazy. Part of what's interesting about Haskell is the default non-strict evaluation of the language, and even if it's hard for newcomers to get used to it, they're better off having a consistent space to work in rather than all these exceptions to make algorithms like sum work more efficiently when the problem was one of documentation and education about the language. Of course if you want a strict functional language there's plenty of those out there. Dave Regards, Yitz Cheers, Daniel ___ 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] Re: GPL answers from the SFLC (WAS: Re: ANN: hakyll-0.1)
2010/3/5 Maurício CA mauricio.antu...@gmail.com To my knowledge, the LGPL only allows *linking* with non-(L)GPL software. But GHC doesn't just link but performs massive cross-module inlining. So in my opinion, LGPL is not a solution, too. Use BSD3! But that massive cross-module inlining happens at your computer, where the rights allowed by GPL for private use applies. Not if I ship you a statically linked binary. You assume everyone compiles my Haskell source code :-). So, as long as you distribute the GPL/LGPL code separate from your BSD/proprietary code, no restrictions should apply. (I believe this applies even with GPL, as all you'll be using in your code is the API which, as far as I know, can't be copyrighted, like any kind of interface -- even hardware interface. But I can't find a source on that.) This is not suitable for everyone. Best, Maurício ___ 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] GPL answers from the SFLC (WAS: Re: ANN: hakyll-0.1)
On Fri, Mar 5, 2010 at 2:19 AM, Stephen Tetley stephen.tet...@gmail.comwrote: On 5 March 2010 09:53, Magnus Therning mag...@therning.org wrote: Now I'm even more confused. How is hosting on Hackage an issue in [1]? Hi Magnus The issue arouse when Tom Tobin spotted Hackage was hosting hakyll (libBSD3) that depends in pandoc (libGPL). Hakyll's author is allowed to privately write any code he wants that uses GPL code, Hackage come into it as he published on Hackage. Yes the author can privately license code to himself under any license he wants, but when he distributes code based on GPL'd code, it has to be GPL'd. That's why people hate this license, or love this license. For all the freedom it talks about it's awfully restrictive. Dave Best wishes Stephen ___ 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] GPL answers from the SFLC (WAS: Re: ANN: hakyll-0.1)
As always I'm still not a lawyer, so this is not legal advice... but here's how I think it works. If you need to talk to a lawyer to get this cleared up, do it. On Fri, Mar 5, 2010 at 2:30 AM, Malcolm Wallace malcolm.wall...@cs.york.ac.uk wrote: On 5 March 2010 09:53, Magnus Therning mag...@therning.org wrote: Now I'm even more confused. How is hosting on Hackage an issue in [1]? The GPL specifically (and only) applies when code is distributed to others outside the originating authors' organisation. I'm pretty sure it says nothing about organizations. If I threw a flash stick with a binary of a program I wrote over my cubicle wall to say, my coworker, Steve, and I tried to tell him he couldn't have the source to my binary that I created based on a GPL'd program on that stick, he could say I've infringed on his rights under the GPL. Hackage is a means of distributing such code. Because Hackage has received the code from the author, it therefore has the same obligations (under the GPL, or BSD, or whatever) as any other recipient. Hackage has no obligations unless it's an intelligent entity. Hackage does not have to enforce the GPL, the author responsible for the perceived violation of the GPL must resolve it with the person claiming the violation, either by settling it inside or outside of court, by either making their code the GPL, or dealing with someone potentially bringing them in front of a judge. In fact the people running Hackage have now become the same as the person I threw my flash drive over the cube wall to, and have the same rights as Steve. To be clear, like any recipient, one treats the donor in good faith. That is, one believes the license granted by the author (or upstream distributor) is valid until notified otherwise. It is the author's responsibility to check, not Hackage's. EXACTLY :-) Now for a bit of personal reflection that you can ignore if you wish... Wouldn't it be excellent if Google could tell us just how many times innocent mailing lists like haskell-cafe have to put up with confusion over the GPL? Every single open source project I've ever been on has had a mailing list that has had this problem in the last 15 years I've been active in open source communities, and it just keeps rearing it's ugly head. It's really irritating and distracts people who'd rather be sharing their work with one another from doing so, completely thwarting the point of the FSF to begin with. As such I've long since abandoned any love for any form of the GPL, and much prefer licenses like the BSD license. Regards, Malcolm ___ 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] Books for advanced Haskell
On Thu, Mar 4, 2010 at 7:11 PM, Richard O'Keefe o...@cs.otago.ac.nz wrote: I assumed that CBL meant Call By Location Commercial Brewer's License? I think it's about beer! ___ 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] Books for advanced Haskell
2010/3/4 Matthias Görgens matthias.goerg...@googlemail.com A shining example are Dan Piponis blog posts. Not his fault, mind. All I see is that there is something powerful. I also notice that the big brains construct monads in many different ways and thus giving them entirely different capabilities. An example of this is some techniques turn CBV to CBN or CBL while other techniques null this. What are CBV, CBN and CBL? It's a series of 3 TLAs designed to make people who know what they are feel more in-the-know than those who don't. :-) Dave ___ 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] Books for advanced Haskell
I don't think a Haskell-monad book would be terribly interesting. A book on taking the pieces of category theory, with a little bit more of the math, to apply to Haskell would be greatly interesting to me. Also a book on learning what to look for for measuring Haskell performance in space and time + optimization seems like it'd be a good thing to have as well. Monad in itself is really simple. Some of the implementations of Monad can be a little mind bending at times, but the Monad itself is not really that complicated. Dave 2010/3/1 Günther Schmidt gue.schm...@web.de Hi all, there seems to be a huge number of things that monads can be used for. And there are lots of papers, blog posts, etc. describing that, some more or less accessible. Apart from monads there are of course also Applicative Functors, Monoids, Arrows and what have you. But in short the Monad thingy seems to be the most powerful one of them all. Is there a book that specializes on Monads? A Haskell-Monad book? Günther ___ 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] Multiple Interpretations for a monad?
Monads aren't necessarily EDSLs by themselves but are often shipped with functions that provide what would make them an EDSL. Take the State monad, it has at least a get and a put function to work with the state in the monad. That get and put are commands that function only within the domain of the State monad, and therefore could be thought of as an embedded language that is used to work with the state encapsulated in the State Monad computation. The way I like to think of it, a Monad provides an environment or a context within which it is very convenient to express an EDSL, and that this style of coding should be encouraged! :-) Dave 2010/2/25 Günther Schmidt gue.schm...@web.de Hi everyone, in my attempts to remove boilerplate and thus to do more abstraction I come across a number of interesting things and suggestions. Especially blog posts from Dan Piponi and also Heinrich Apfelmus. I think what they both are saying is that you can construct / implement some sort of 2 layered monad which can then have more than one interpretation. In the responses to one of my posts on DSLs Dan Piponi also points out that he considers monads also to be DSLs. It didn't click with me when he said it, but reading more of his blog posts made me remember that. Now I know this is probably something obvious to most haskellers, but to me it's not. Did I understand this correctly so far? Günther ___ 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
[Haskell-cafe] haddock installation weirdness?
I'm on Mac OS X Snow Leopard, and can't get haddock installed due to the following error: Resolving dependencies... Configuring haddock-2.6.0... Warning: This package indirectly depends on multiple versions of the same package. This is highly likely to cause a compile failure. package haddock-2.6.0 requires Cabal-1.8.0.2 package ghc-6.12.1 requires Cabal-1.8.0.2 package bin-package-db-0.0.0.0 requires Cabal-1.8.0.2 Preprocessing library haddock-2.6.0... Preprocessing executables for haddock-2.6.0... unused terminals: 1 Building haddock-2.6.0... command line: cannot satisfy -package-id ghc-6.12.1-b691a185e99c62533666d9a28a9e1988: ghc-6.12.1-b691a185e99c62533666d9a28a9e1988 is unusable due to missing or recursive dependencies: Cabal-1.8.0.2-a08510b9460f1b65f9dee06ed53f0650 bin-package-db-0.0.0.0-0c559ebe951f9972c4e6dfe5ebd4ce6a (use -v for more information) cabal: Error: some packages failed to install: haddock-2.6.0 failed during the building phase. The exception was: ExitFailure 1 When I do a ghc-pkg list | grep Cabal I get the following: ghc-pkg list | grep Cabal Cabal-1.8.0.2 Cabal-1.8.0.2 I'm wondering if this means I have a copy in my .cabal, and another from GHC,and if that could be causing a problem? I'm trying to work on the Haddock docs for the NineP package I uploaded the other day, and would rather not have to finish uploading before previewing the result :-) Dave ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: haddock installation weirdness?
This might be heavy handed but I think I just got over this by clobbering my .ghc directory and redoing cabal install haddock Dave On Thu, Feb 25, 2010 at 7:23 PM, David Leimbach leim...@gmail.com wrote: I'm on Mac OS X Snow Leopard, and can't get haddock installed due to the following error: Resolving dependencies... Configuring haddock-2.6.0... Warning: This package indirectly depends on multiple versions of the same package. This is highly likely to cause a compile failure. package haddock-2.6.0 requires Cabal-1.8.0.2 package ghc-6.12.1 requires Cabal-1.8.0.2 package bin-package-db-0.0.0.0 requires Cabal-1.8.0.2 Preprocessing library haddock-2.6.0... Preprocessing executables for haddock-2.6.0... unused terminals: 1 Building haddock-2.6.0... command line: cannot satisfy -package-id ghc-6.12.1-b691a185e99c62533666d9a28a9e1988: ghc-6.12.1-b691a185e99c62533666d9a28a9e1988 is unusable due to missing or recursive dependencies: Cabal-1.8.0.2-a08510b9460f1b65f9dee06ed53f0650 bin-package-db-0.0.0.0-0c559ebe951f9972c4e6dfe5ebd4ce6a (use -v for more information) cabal: Error: some packages failed to install: haddock-2.6.0 failed during the building phase. The exception was: ExitFailure 1 When I do a ghc-pkg list | grep Cabal I get the following: ghc-pkg list | grep Cabal Cabal-1.8.0.2 Cabal-1.8.0.2 I'm wondering if this means I have a copy in my .cabal, and another from GHC,and if that could be causing a problem? I'm trying to work on the Haddock docs for the NineP package I uploaded the other day, and would rather not have to finish uploading before previewing the result :-) Dave ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How many Haskell Engineer I/II/IIIs are there?
Using it at the day job currently... like I need to get back to it. On Wed, Feb 10, 2010 at 8:22 AM, John Van Enk vane...@gmail.com wrote: Not using it yet, but there's been a large amount of interest and willingness to work with it from management. We're contractors, so it depends on us finding some one who will allow us to use the language or asks for it explicitly. On Wed, Feb 10, 2010 at 10:59 AM, Jason Dusek jason.du...@gmail.comwrote: Although I'm fond of Haskell, in practice I am not a Haskell programmer -- I'm paid for Ruby and Bourne shell programming. Many of the jobs posted on this list end up being jobs for people who appreciate Haskell but will work in C# or O'Caml or some-such. I wonder how many people actually write Haskell, principally or exclusively, at work? -- Jason Dusek ___ 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] safe lazy IO or Iteratee?
Hi everyone, This is not an attempt to start a flame war. I'm just trying to get a good feel for the advantages and disadvantages of the newer safe lazy io lib available on Hackage vs using Iteratee. It does appear to me that using something like Itereatee gives a bit of room to really tweak the low level enumerator/iteratee relationship, and, if you asked my old boss, I'm just a big fan of folds too, I use them a lot in my Erlang :-), so Iteratee really does appeal to me on many levels. Yet at the same time, I'm quite enamored with the beauty of interact and functions of that sort. I realize mixing the effects of the lazy IO and pure code may not be the clearest way to write code for everyone, but there is something about being able to get linewise data as interact (unlines . fmap someLineWiseFunction . lines) that is just kind of cool. Dave ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] safe lazy IO or Iteratee?
Thanks for the detailed response below... I must be able to understand how the resources will be used in my system for mission-critical, long-running applications. Dave On Thu, Feb 4, 2010 at 12:51 PM, John Millikin jmilli...@gmail.com wrote: Both have advantages and disadvantages. The primary advantage of lazy IO over iteratees is that it's much, *much* easier to understand -- existing experience with monads can be used immediately. The downsides of lazy IO, of course, are well documented[1][2][3]. Some are fixed by the safe/strict IO packages. However, safe lazy IO is still unpredictable in that it's difficult to know how many resources will be used, the order of some operations (eg, releasing handles), or whether some particular expression will throw an exception. Iteratees are useful because the author can make and verify guarantees about performance (eg, this code will never read more than 4 KiB at once). They also allow pure code to determine the behavior of IO, safely, which is useful when writing libraries which must deal with large amounts of data (eg, streaming a file over HTTP). The Hyena web server is written using iteratees, and from what I've heard the authors have been quite happy with their properties. I've also found iteratees to perform somewhat better than lazy IO, though I don't know why. Downside: iteratees are very hard to understand. I wrote a decently-sized article about them[4] trying to figure out how to make them useful, and some comments in one of Oleg's implementations[5] suggest that the iteratee package is subtly wrong. Oleg has written at least three versions (non-monadic, monadic, monadic CPS) and I've no idea why or whether their differences are important. Even dons says he didn't understand them until after writing his own iteratee-based IO layer[6]. tl;dr: Lots of smart people, with a history of being right about this sort of thing, say iteratees are better. Evidence suggests iteratee-based IO is faster and more predictable than lazy IO. Iteratees are really hard to understand. [1] http://okmij.org/ftp/Haskell/Iteratee/Lazy-vs-correct.txt [2] http://www.kuliniewicz.org/blog/archives/2010/01/27/happstack-and-streaming-part-4-the-flaw/ [3] http://forums.xkcd.com/viewtopic.php?f=11t=46780 [4] http://ianen.org/articles/understanding-iteratees/ [5] http://okmij.org/ftp/Haskell/Iteratee/IterateeM.hs , search for Drawbacks of this encoding [6] http://stackoverflow.com/questions/1319705/introduction-or-simple-examples-for-iteratee On Thu, Feb 4, 2010 at 08:29, David Leimbach leim...@gmail.com wrote: Hi everyone, This is not an attempt to start a flame war. I'm just trying to get a good feel for the advantages and disadvantages of the newer safe lazy io lib available on Hackage vs using Iteratee. It does appear to me that using something like Itereatee gives a bit of room to really tweak the low level enumerator/iteratee relationship, and, if you asked my old boss, I'm just a big fan of folds too, I use them a lot in my Erlang :-), so Iteratee really does appeal to me on many levels. Yet at the same time, I'm quite enamored with the beauty of interact and functions of that sort. I realize mixing the effects of the lazy IO and pure code may not be the clearest way to write code for everyone, but there is something about being able to get linewise data as interact (unlines . fmap someLineWiseFunction . lines) that is just kind of cool. Dave ___ 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: Re[2]: [Haskell-cafe] safe lazy IO or Iteratee?
On Thu, Feb 4, 2010 at 1:26 PM, Bulat Ziganshin bulat.zigans...@gmail.comwrote: Hello John, Thursday, February 4, 2010, 11:51:59 PM, you wrote: tl;dr: Lots of smart people, with a history of being right about this sort of thing, say iteratees are better. Evidence suggests iteratee-based IO is faster and more predictable than lazy IO. Iteratees are really hard to understand. thank you! good time for iteratee tutorials? ;) I put up my version of cat on my blog... http://leimy9.blogspot.com I'm just using runInteractiveCommand, and then putting the Handle returned through an enumerator/iteratee processing fold to get the contents. -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Game of life in haskell.
On Tue, Feb 2, 2010 at 11:54 AM, Jon Harrop j...@ffconsultancy.com wrote: On Tuesday 02 February 2010 18:23:59 Serguey Zefirov wrote: 2010/2/2 Jon Harrop j...@ffconsultancy.com: On Tuesday 02 February 2010 16:10:05 Serguey Zefirov wrote: Actually, your solution with arrays is the most often occured solution an imperative programmer will come with. It is simple but not scalable and not particularly fast. What gave you that impression? Discussion in Russian Smalltalk User Group. A solution in APL: http://catpad.net/michael/apl/ Some experience before (my own first implementation and some of my friends). Or, you're asking about scalability and speed? I meant the scalability and speed. An imperative solution should be simpler, more scalable and faster than any purely functional solution. That's a pretty strange comment. Why do you think an imperative solution is simpler, faster and more scalable? If functional programming can't provide any one of those, it's not worth anything, and based on the membership in this list, the interest in it these days, and the fact that I've seen many occasions where functional programming lends itself to a faster implementation (in terms of time to implement and test) that's actually readable sooner than a lot of imperative approaches, I find your claim to be quite contrary and smells of trollishness. Dave -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e ___ 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] Game of life in haskell.
On Tue, Feb 2, 2010 at 7:33 PM, Gregory Crosswhite gcr...@phys.washington.edu wrote: On Feb 2, 2010, at 7:11 PM, Jon Harrop wrote: I doubt programming paradigms live or die according to whether or not they can implement Conway's Game of Life simply and efficiently. This makes an awesome quote. :-) - Greg This whole thread has been rather odd. The sort of processing that goes on in Conway's Game of Life is pretty common. I've seen it implemented a good many different ways, including with GCD from apple where each cell could potentially be its own thread (good scalability test for apple it seems... neat code, doesn't even use Cocoa). I've got some very simple code for Conway's Game of Life, but it is not my own. It's from Dr. Graham Hutton's excellent Haskell introductory book. Doesn't even use external libraries from the Prelude. It's short and easy to read, and renders by plotting characters a terminal using escape sequences (so I guess it's VT100 at least required to run it). I'm left somewhat confused by people believing they know enough about functional programming to make claims like these, or that the processing used in Conway's Game of Life might not be important. As someone who's worked in HPC for 1/3 his life and his entire career, I find this to be a pretty closed minded approach to computer science. The worst form of ignorance is when you think you've got the answer to everything already... It's sad to see that going on here. Dave ___ 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] space leaks and optimizations
2) While each step is predictable, the overall behavior of a lazy program can be rather surprising. So one must be very careful. GHC provides two ways to control the evaluation order, seq and bang patterns, but I am not sure which of these (if any) is the right tool. Consider the following example (from the Real World Haskell book): mean :: [Double] - Double mean xs = sum / fromIntegral num where (num,sum) = foldl' f (0,0) xs :: (Int, Double) f (n,s) x = (n+1, s+x) Although it uses foldl', there is a space leak because Haskell tuples are not strict. There are two possible fixes: f (!n,!s) x = (n+1, s+x) or f (n,s) x = let n1=n+1; s1=s+x in n1 `seq` s1 `seq` (n1,s1) The first one is short, but less natural than the second one, where the offending thunks are suppressed on the spot. Unfortunately, the syntax is awkward; it would be nice to write something like f (n,s) x = (!n+1, !n+1) Well, I am becoming too grumpy, perhaps the bang patterns are fine. More important question: are there established practices to *avoid* space leaks rather than fixing them afterwards? I believe the expectation is to learn to not be surprised in the areas where lazy or non-strict evaluation can be overused, and to learn all the advantages of non-strict evaluation vs strict, and the power it gives, such that an imperative programmer doesn't feel surprised or angry when things go wrong. I blogged about writing a long running service in Haskell that ran into problems with the lazy State monad, and lazy Data.Map, and I discussed how I had to force evaluations of everything to get the program under control. This wasn't for a hobby, this was for a production system. I believe I've a much better handle on strict vs non-strict than when I started the project, but I felt pretty lost for a while in the process of doing it. I was even using the Maybe monad with it's MonadPlus implementation to avoid using case statements around deconstruction, which I'm sure exacerbated some of my problem. However, since Haskell will evaluate the outer-most stuff first, the trick seems to be to find the point at which you *really* need the values computed, then tell Haskell to get on with it. You kind of have to have an explicit sequence point where all things need to be resolved, and you have to be able to see those in your code. Sometimes you can get away with only doing small pieces at a time. I had about the worst situation I've ever seen for data growth in my code. I had a pile of non-strict expressions, that were all dependencies for the next, running forever, and never getting evaluated except at asynchronous and user-controlled moments. If these expressions had been evaluated strictly, they would have taken up constant space, but since they were all thunks, I got linear data growth over time, until I blew up. Some advice I've gotten since then was to think about using case for strictness rather than explicitly using seq. Turns out case's pattern matching is pretty strict, and that you can often get by with that. I haven't spent a lot of time with core output, but my understanding is that it's all let and case. 3) The standard library was not designed with space efficiency in mind; for example, there is sum but no sum'. Actually I think that the standard library was designed to be consistent with the way the language is documented to behave. That is to say that it's non-strict by default everywhere it's possible to be so. Control.Monad.State selects Control.Monad.State.Lazy by default instead of Control.Monad.State.Strict, but both exist. Yes, in some cases there's no strict equivalent provided, but is writing a strict sum really a big problem? I think there's stricter folds included because they're not quite as trivial, but once you have a strict fold isn't strict sum pretty easy? I suppose the type of the contained element in the list could make a big difference in whether the strict fold is strict enough, but where do you stop providing strict versions of functions for people? It seems a line must be drawn somewhere, and the right solution is to properly educate Haskell programmer about both the power and drawbacks of non-strict evaluation, and when it's really necessary to turn things off. Giving examples is fine, but one must learn to see the patterns where there is a problem that could brew. Real World Haskell teaches us about the profiling tools that helped me uncover my problems. Best regards, Alexei ___ 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] Re: Data.Ring -- Pre-announce
I recently needed a ring buffer in haskell, so I did it in C and used the FFI :-) This is much nicer. Dave On Thu, Dec 31, 2009 at 2:37 PM, Iavor Diatchki iavor.diatc...@gmail.comwrote: Hi, I usually refer to this structure as a RingBuffer, just an idea. If you have the time, I would add rough complexity estimates to the documentation for the different functions. Thanks for your work! Happy new year, Iavor On Thu, Dec 31, 2009 at 1:13 PM, John Van Enk vane...@gmail.com wrote: I've decided to settle on Data.CircularList. The renamed git repository is here: http://github.com/sw17ch/data-clist On Thu, Dec 31, 2009 at 3:29 PM, Twan van Laarhoven twa...@gmail.com wrote: John Van Enk wrote: Hi Heinrich, I think I like Ring more than Necklace or Tom's suggestion of Circular. I chose Ring simply because that's what I was searching for when I wanted the data structure. The package will be named data-ring, so that should hopefully be enough to clue in the user that it's not dealing with the mathematical concept. The mathematical concept would likely also go in Data, unfortunately. See for example Data.Monoid. If someone does at a Ring class sometime, it is very likely to go into Data.Ring, which would lead to conflicts. In fact it already exists, see the monoids package [1] I would prefer the name RingList or CircularList. As long as you put the word ring in the package description users will still find it when searching on hackage. [1] http://hackage.haskell.org/packages/archive/monoids/0.1.25/doc/html/Data-Ring.html Twan ___ 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Native CLient
I guess I'm confused by what it means to support this in a language. My understanding is this is using lightweight virtualization technology (perhaps via segment register hacks on x86, and something else on ARM) to provide a safe sandbox to run native code in a browser. If I had to guess, I'd say you could run an entire virtualized OS in there, similar to the way it was done for vx32 with the Plan 9 port to it. (9vx is a port of the plan 9 operating system to vx32, allowing it to run as a user process on linux, freebsd, and Mac OS X) Are you talking about porting the GHC Haskell runtime to NaCL? If so, then I think I understand, but the language itself doesn't really need to do anything special to support this as far as I can tell. Dave On Tue, Dec 29, 2009 at 5:26 AM, Joan Miller pelok...@gmail.com wrote: Native CLient (NaCl) [1] is a technology very cool which lets to run native code in web applications, and it's being integrated in some languages as Python [2]. Go [3] already has rudimentary support for Native Client (and it's logical since that both technologies are from Google) I hope that Haskell also gets support for NaCl and doesn't loose this train else a language as Go could get every time more users that until now they had gone to Haskell or Erlang mainly for its concurrency. [1] http://code.google.com/p/nativeclient/ [2] http://lackingrhoticity.blogspot.com/2009/06/python-standard-library-in-native.html [3] http://golang.org/pkg/exp/nacl/ ___ 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] Native CLient
Ah, I see now. Thanks for going deeper on that. I did eventually find the RPC stuff for Go, and thought that that might be interesting to implement. On Tue, Dec 29, 2009 at 8:31 AM, Joan Miller pelok...@gmail.com wrote: Each component runs in its own private address space. Inter-component communication is based on Native Client’s reliable datagram service, the IMC (Inter-Module Communications). For communications between the browser and a NaCl module, Native Client provides two options: a Simple RPC facility (SRPC), and the Netscape Plugin Application Programming Interface (NPAPI), both implemented on top of the IMC. The IMC also provides shared memory segments and shared synchronization objects, intended to avoid messaging overhead for high-volume or high-frequency communications. [1] The Native Client modules can communicate with the browser using either NPAPI or simple RPC (SRPC) [2] so there would be that implement that in Haskell. [1] http://nativeclient.googlecode.com/svn/data/docs_tarball/nacl/googleclient/native_client/documentation/nacl_paper.pdf [2] http://nativeclient.googlecode.com/svn/trunk/src/native_client/documentation/npapi.html 2009/12/29 David Leimbach leim...@gmail.com: I guess I'm confused by what it means to support this in a language. My understanding is this is using lightweight virtualization technology (perhaps via segment register hacks on x86, and something else on ARM) to provide a safe sandbox to run native code in a browser. If I had to guess, I'd say you could run an entire virtualized OS in there, similar to the way it was done for vx32 with the Plan 9 port to it. (9vx is a port of the plan 9 operating system to vx32, allowing it to run as a user process on linux, freebsd, and Mac OS X) Are you talking about porting the GHC Haskell runtime to NaCL? If so, then I think I understand, but the language itself doesn't really need to do anything special to support this as far as I can tell. Dave On Tue, Dec 29, 2009 at 5:26 AM, Joan Miller pelok...@gmail.com wrote: Native CLient (NaCl) [1] is a technology very cool which lets to run native code in web applications, and it's being integrated in some languages as Python [2]. Go [3] already has rudimentary support for Native Client (and it's logical since that both technologies are from Google) I hope that Haskell also gets support for NaCl and doesn't loose this train else a language as Go could get every time more users that until now they had gone to Haskell or Erlang mainly for its concurrency. [1] http://code.google.com/p/nativeclient/ [2] http://lackingrhoticity.blogspot.com/2009/06/python-standard-library-in-native.html [3] http://golang.org/pkg/exp/nacl/ ___ 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] Re: Why?
And that would be true if everything were strict and not partially evaluated sometimes :-) My understanding is the following... (and I could be way off) Remember that a function of arity N is really N functions of arity 1 with their arguments bound one at a time to create a new function along the way. At least you *can* write your code that way if you really want to, but the laziness might make it such that all the parameters are not bound, due to not being needed at that moment. Instead a thunk or what some other languages might call a Future is put in the argument's place, to be evaluated when needed. If Haskell were strict by default, I think your claim of passing references around could be true, but my experience with Haskell has been that sometimes it's too lazy for me to write the code that I first thought would be efficient without a lot f study and refactoring of that code. I'm sure this gets easier with practice, but it's not something I was expecting to be as difficult as it all was. Dave On Thu, Dec 10, 2009 at 5:57 AM, Alberto G. Corona agocor...@gmail.comwrote: One more advantage that is not frequently cited Purity permits to pass every parameter of a procedure by reference (giving the pointer) rather that by value giving a copy, and still be sure that the data has not been modified. Besides the safety. this is great language optimization itself. 2009/12/10 Alberto G. Corona agocor...@gmail.com What material benefit does Haskell derive from being a pure functional language as opposed to an impure one? Here is my list of benefits of purity (some of them are enhanced by other features like the type system). Purity means referential transparency. that means that the programmer has no way to modify pure data. That cut the tree of possible programmer errors.In particular, since there are no variables, every state change must be in the form o a call to a function with new parameters. each function has no state change (except when needed and then the type system labels the stateful code as such)( This enforcement goes in the righ direction for clarity and readability, maintainability, modularity xbility. Purity also eases paralel processing, since no data is modified, each process is isolated better. Less opportunities for errors. Purity permits lazines because since the execution tree of an expression has pure, data, can be evaluated later, since it will not be changed. Lazy evaluation eases mathematical reasoning,because mathematics has no notion of eager evaluation, but to make use of mathematical equations when the calculation is needed. . Mathematical reasoning permits the full use of a long tradition of mathematical knowledge. This makes code more simple, understandable, general, proof guarantted and elegant (for those that know the mathematical domain). This also permits high level optimization of code, both by the programmer and the compiler. for sure there are a few more We are superstitious and guided by nonrational ideas such is beauty. but: bauauty - (simplicity - (less effort to master, less errors) , utility -, solve more problems, solve greater problems ) ___ 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] Re: Why?
On Thu, Dec 10, 2009 at 6:31 AM, Alberto G. Corona agocor...@gmail.comwrote: My understanding is that a pointer to the lazy expression tree for the calcualtion of the parameter is put it the corresponding location of the function expression tree. But at any time you can force the evauation before the call. or the compiler itself. Optimization is possible depending on the knowledge. What happens if the parameter is an infinite list and the function handles a few items of it?. All of these consideration pales when a programmer has to call a procdure in a library made by others with no documentation, and no clue about what the procedure does inside. The purity and the type system removes many concerns. That's not a safe way to think of 3rd party libraries. It is a convenient claim for promoting the language, and is probably more often than not the case though it does not quite capture the whole truth. unsafePerformIO can exist in any library you import, and while you may think it's pure, you still have to implicitly trust the library writers (unless you bother to look at the source). Take Debug.Trace.trace for example, it's a pure computation, yet causes side effects. Yes, it's a controlled side effect, but a polluted version of the same function signature could launch the missles while looking like the function is synonymous with id. In short unsafePerformIO, while it's supposed to be avoided, may not be avoided as much as the advice given to do so :-). Might be interesting to see how many occurrences of unsafePerformIO exist in hackage. I fully realize that someone will probably claim I'm taking this position to the extreme, but I think we're tempted to pretend that all functions with pure signatures are always safe which is another kind of extreme when you consider the existence of backdoors to the Monads that provide the guarantees we're clinging to to talk about how great Haskell is. I think the existence of unsafePerformIO is a bit of an admission that there's some things yet to be figured out to make this system 100% consistent with where we want pure functional programming to be. Dave 2009/12/10 David Leimbach leim...@gmail.com And that would be true if everything were strict and not partially evaluated sometimes :-) My understanding is the following... (and I could be way off) Remember that a function of arity N is really N functions of arity 1 with their arguments bound one at a time to create a new function along the way. At least you *can* write your code that way if you really want to, but the laziness might make it such that all the parameters are not bound, due to not being needed at that moment. Instead a thunk or what some other languages might call a Future is put in the argument's place, to be evaluated when needed. If Haskell were strict by default, I think your claim of passing references around could be true, but my experience with Haskell has been that sometimes it's too lazy for me to write the code that I first thought would be efficient without a lot f study and refactoring of that code. I'm sure this gets easier with practice, but it's not something I was expecting to be as difficult as it all was. Dave On Thu, Dec 10, 2009 at 5:57 AM, Alberto G. Corona agocor...@gmail.comwrote: One more advantage that is not frequently cited Purity permits to pass every parameter of a procedure by reference (giving the pointer) rather that by value giving a copy, and still be sure that the data has not been modified. Besides the safety. this is great language optimization itself. 2009/12/10 Alberto G. Corona agocor...@gmail.com What material benefit does Haskell derive from being a pure functional language as opposed to an impure one? Here is my list of benefits of purity (some of them are enhanced by other features like the type system). Purity means referential transparency. that means that the programmer has no way to modify pure data. That cut the tree of possible programmer errors.In particular, since there are no variables, every state change must be in the form o a call to a function with new parameters. each function has no state change (except when needed and then the type system labels the stateful code as such)( This enforcement goes in the righ direction for clarity and readability, maintainability, modularity xbility. Purity also eases paralel processing, since no data is modified, each process is isolated better. Less opportunities for errors. Purity permits lazines because since the execution tree of an expression has pure, data, can be evaluated later, since it will not be changed. Lazy evaluation eases mathematical reasoning,because mathematics has no notion of eager evaluation, but to make use of mathematical equations when the calculation is needed. . Mathematical reasoning permits the full use of a long tradition of mathematical knowledge. This makes code more simple
Re: [Haskell-cafe] Re: Why?
I understand that this is very much a work-in-progress. But we have to also come to the realization that there's people forming industrial groups and such around Haskell, and trying very earnestly to show that it's worth looking into for serious practical applications. I do believe that it's important to point out where there is work that needs to be done to meet all the goals that Haskell wants to achieve such that the selling points aren't possibly construed by the audience as disingenuous claims. Now having said that, this is *not* meant to be a slap in the face of those who want Haskell to be used in a practical way *now*. I am in fact one of them, having created code that has shipped and will continue to ship (at least until I'm forced to rewrite it... let's hope not) in Haskell in management systems that may, if our plans work out, be deployed potentially all over the world. Dave On Thu, Dec 10, 2009 at 6:50 AM, John D. Earle johndea...@cox.net wrote: David, think of the machine as being the earth and laziness is in the clouds. Strict evaluation is closer to the machine. The relationship between a lazy algorithm and the earth is abstract; hence, it will make creating algorithms especially efficient ones difficult. All of this is still a work in progress. The Haskell creed appears to be, This is the way so stick to it! The idea appears to be that by sticking to the program the problems will be overcome in time and we will be left with all the glorious goodness. At one time it was not possible to achieve the sort of efficiency that Haskell achieves as a matter of course. ___ 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] Re: Why?
My understanding of functional programming is that nearly everything is a function, and that evaluation of those functions is how programs are written. Functional programming languages treat functions as first class values, allowing them to be passed to other functions and returned from functions. In this sense Scheme qualifies as a functional language. However Scheme will fail your definition because you're saying it must be effect free, which is not the case with Scheme. It becomes difficult to have a discussion when the fundamental terms are not agreed upon :-) Dave On Thu, Dec 10, 2009 at 8:15 AM, John D. Earle johndea...@cox.net wrote: To elaborate there is another language that is also a functional language. I won't mention the name so as not to offend anyone. It too is effect free, that is what makes it functional and it is a functional language in the true sense of the term, but it is not effect free in the sense that Haskell is effect free. This other language is effect free in every practical sense whereas Haskell is effect free in a strict sense. ___ 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] Re: Why?
Hi Stephen, While it's fair to mention that unsafePerformIO is not in the report for the reasons you give, it is present in some libraries. The practical reality of the situation is you can not in general trust that because a function's signature is pure, that the implementation of that function is. I mean you can, and you can pay the price for when you're wrong, as can the other people affected by that choice to trust that nothing fishy is going on behind the scenes, but it'd be a bad idea. Here's a really contrived example. Let's say you use a library, maybe one of the soon to be supported shared libraries for GHC, and that you use some pure functions of that library. Now let's say the system is compromised, and a modified version of said library is installed on the system which during the pure computation, has the effect of sending data that's being computed to some other internet connected machine. Now let's say you're a financial institution and the haskell code is running part of a webserver with people's account data in it. Now do you want to trust all pure functions implicitly? I realize this might be a bit too much of a straw man, but some people actually have to consider these possibilities. Dave On Thu, Dec 10, 2009 at 9:45 AM, Stephen Tetley stephen.tet...@gmail.comwrote: Hello David Apropos the (unfortunately) frosty exchanges that greeted the first release of UHC a couple of months ago, which argued that UHC wasn't Haskell because it didn't implement n+k patterns, one could argue (at least for rhetorical effect) that Haskell plus unsafePerformIO isn't Haskell, I don't think you'll be able to find unsafePerformIO in the report... Best wishes Stephen 2009/12/10 David Leimbach leim...@gmail.com: That's not a safe way to think of 3rd party libraries. It is a convenient claim for promoting the language, and is probably more often than not the case though it does not quite capture the whole truth. unsafePerformIO can exist in any library you import, [snip] In short unsafePerformIO, while it's supposed to be avoided, may not be avoided as much as the advice given to do so :-). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why?
2b. You can define brand new flow control constructs *inside* the language itself. (E.g., in Java, a for loop is a built-in language construct. In Haskell, for is a function in Control.Monad. Just a plain ordinary function that anybody could write.) Psst, heard about Scheme call/cc? But, very importantly, purity allows you to *restrict* the flow constructs that client code has available. If you have continuations + mutable state you can do anything, but the more code can *do*, the less you *know* about it. For example, providing parser combinators as an applicative functor offers more power than a traditional parser generator, but not enough that we can no longer parse efficiently. Exactly my fear over unsafePerformIO in 3rd party Haskell libraries :-). One can present an interface in Haskell that looks safe, but it can be very unsafe in its implementation. Dave Luke ___ 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] Is Haskell a Fanatic?
Hi Simon and others, Personally I don't see anything wrong with this guy's line of questioning. He wants some proof that Haskell can live up to some of the claims made about it. There's a lot of selling of languages like Clojure, Scala, and Haskell going on that have real world examples showing how code compares from one language to the next (sometimes unfairly I'll add, in that the code that one person writes in one language, does not illustrate the best of that language). I will admit I missed out on the optimization thread that people refer to. I guess I could read the archives, but the tone of this thread makes me think it's not worthwhile. I think what it boils down to is Haskell use is a choice that every person gets to make for their spare time projects and if you're lucky enough to have such a choice at your job, why not check it out and see for yourself? If one disagrees with the claims of the salesmen, perhaps a trial period will convince one otherwise, it's not like it costs anything but time. There's not even a 90 day money back guarantee to worry about. As for trolls on the mailing list, I personally do not have time to read every message that comes through haskell-cafe because the level of activity is higher than my available bandwidth for reading emails. As such, I often press this lovely button the people who made my computer and operating system so thoughtfully designed called delete. Man does that thing ever work wonders... Then people can refrain from increasing the magnitude of the denominator in the signal to noise ratio that has a nice value at the moment here in this community. Sadly I think I just did the opposite, but since this is a cafe, and I had something to say, and I said it, I don't feel so badly about it, and won't comment on it again. Just my 2 cents, which might be all I have left these days :-) Dave On Fri, Dec 4, 2009 at 1:34 AM, Simon Peyton-Jones simo...@microsoft.comwrote: Friends One of the absolutely best things about the Haskell community is that it is almost invariably respectful and usually friendly. People often remark on this when they join the community. Beginner questions are greeted with polite and helpful replies. Category theory and elementary type errors show up in successive messages. Etc. But thread is an exception. If you think someone is talking nonsense, I think the best policy is to ignore it or reply privately (not to the list); then the thread dies. I find derogatory discussion of a particular person quite discouraging. It is likely to be unjust, and it encourages more of the same. It's like littering your own house. Respect, guys, please. Simon | This troll was, apparently, invited by one of the Simons | onto the Haskell' list, then asked to move his spiels here. | | I am informed that the invitation I was referring to was actually | about his being invited *out*, not in, so his origin is still a | mystery and troll is likely appropriate. (I can't say he's | demonstrated much of a mathematical basis for his trollery; only a | propensity for pompous declarations, and deflection when challenged on | them. Put up or shut up, troll.) ___ 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] inotify-alike for mac os x?
d On Thu, Dec 3, 2009 at 7:55 PM, Gregory Collins g...@gregorycollins.netwrote: Conal Elliott co...@conal.net writes: I'd like to make some FRPish toys that keep files updated to have functional relationships with other files. hinotify looks like just the sort of underlying magic I could use for efficient implementation on linux. Is there any support for mac os x? Could support be either added to hinotify or maybe inotify and a mac-friendly library be abstracted into a common Haskell interface? I'm fine with an imperative interface, since I can abstract into a functional library, which I guess would be a sort of persistent simplified FRP. On Mac BSD you have to use kqueue, and on Windows it's ReadDirectoryChangesW. A platform-agnostic Haskell library for detecting filesystem change notifications is something that I would really appreciate! launchd does everything on mac os x, like literally everything. My mother said if I can't say something good about someone or something then don't say anything at all, and in this case, I'm taking her advice on what I think about launchd, however if you click the link below you might get an idea of how that works on Mac OS X. http://stackoverflow.com/questions/1515730/is-there-a-command-like-watch-or-inotifywait-on-the-mac Dave G -- Gregory Collins g...@gregorycollins.net ___ 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] Announcing Haskell 2010
First off congratulations everyone! Second, Oh shit! Graham Hutton's excellent Haskell introduction book is now not valid Haskell 2010 due to N+K patterns? I loaned that book to my boss and he's really enjoyed it. I guess I'll have to buy a revised copy. Can we get an update to it? :-) I realize N+K was considered dangerous On Tue, Nov 24, 2009 at 2:50 AM, Simon Marlow marlo...@gmail.com wrote: I'm very proud to announce a new revision of the Haskell language, Haskell 2010. Over the last couple of months the committee has been making final decisions about which extensions should be a part of this revision. The final list is: DoAndIfThenElse HierarchicalModules EmptyDataDeclarations FixityResolution ForeignFunctionInterface LineCommentSyntax PatternGuards RelaxedDependencyAnalysis LanguagePragma NoNPlusKPatterns You can read more about each one, including rationale for and against, on its relevant wiki page, which are linked from the tickets: http://hackage.haskell.org/trac/haskell-prime/query?status=newstatus=assignedstatus=reopenedstate=acceptedmilestone=Haskell+2010order=priority Haskell 2010 is a small but significant step on the road that was started by the Haskell' committee 4 years ago, The process has not been a smooth one, and there have been several changes of direction, but the current process is actually producing concrete results that let us move the language forward in positive steps, so I feel we're on the right track. We all owe the current committee a big thank-you for sticking with the process this long: most of them didn't realise the magnitude of what they were signing up for at the beginning. The short list of changes above tells only a small part of the story, there is a wealth of wiki content and mailing-list discussion that future language revisions can draw on. So what now? * We will produce a revised version of the Haskell language report incorporating these changes. That will happen over the next few months. * Compilers can start implementing the changes, and flags to select the Haskell 2010 revision. In GHC we expect to have support in the next major release, i.e. 6.14.1. * Right now, we will start forming a Haskell 2011 committee to mange the process of deciding on changes for next year's revision. The current committee is still discussing how to go about finding a new committee (the plan is to at least have open nominations) but I expect to be able to announce more details very soon. * Everyone can participate in the Haskell 2011 process, by discussing and refining proposals. Information about how to do that is on the Haskell Prime wiki: http://hackage.haskell.org/trac/haskell-prime/wiki Remember: this is a community effort. The changes that get adopted in each revision are drawn from the pool of fully-specified proposals, and those proposals can be written by anyone. Thanks, Simon, on behalf of the Haskell 2010 committee ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Could someone teach me why we use Data.Monoid?
On Fri, Nov 13, 2009 at 8:52 AM, Andrew Coppin andrewcop...@btinternet.comwrote: Stephen Tetley wrote: 2009/11/13 Rafael Gustavo da Cunha Pereira Pinto rafaelgcpp.li...@gmail.com: Monoid is the category of all types that have a empty value and an append operation. Or more generally a neutral element and an associative operation: The multiplication monoid (1,*) 9*1*1*1 = 9 1 is neutral but you might be hard pressed to consider it _empty_. This is the thing. If we had a class specifically for containers, that could be useful. If we had a class specifically for algebras, that could be useful. But a class that represents any possible thing that can technically be considered a monoid seems so absurdly general as to be almost useless. If you don't know what an operator *does*, being able to abstract over it isn't especially helpful... ...in my humble opinion. (Which, obviously, nobody else will agree with.) Well to your credit, many people wonder what it means for something to implement the Monoid interface, or even why the Monoid interface is useful. Programmers who don't know what Monoids are may not be aware of the varying alternatives of Monoid implementations. They're curious things to have, but are they useful? :-) Sum vs Product spells out two ways to use Ints in a Monoid context. But we could have done the same with the Functor implementation for lists via fmap now couldn't we? Is anyone really using Sum and Product where Functors get the job done? Practically speaking, I can explain to coworkers the concept of a Functor a lot easier than Monoids so I don't choose to use Monoids explicitly in my code. I do use MonadPlus though, especially with Maybe as it makes a nice short-circuit syntax around alternatives for potential Nothing results. So in a way I'm possibly shooting myself in the foot if I have to explain the code to someone who was expecting a case or an if expression. ___ 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
[Haskell-cafe] Long running Haskell program
As some of you may know, I've been writing commercial Haskell code for a little bit here (about a year and a half) and I've just recently had to write some code that was going to run have to run for a really long time before being restarted, possibly months or years if all other parts of the system cooperate as it's part of a server infrastructure management system. I recently ran into some serious space leak difficulties that would ultimately cause this program to crash some time after startup (my simulator is also written in Haskell, and runs a LOT faster than the real application ever could, this has enabled me to fast forward a bit the data growth issues and crash in minutes instead of days!) Anyway, rather than try to paste it all here with images and such I thought I'd stick it up on my blog so others could maybe benefit from the anecdote. It's difficult to disclose enough useful information as it is commercial code not under an open source license, but there's neat diagrams and stuff there so hopefully the colors are at least amusing :-) http://leimy9.blogspot.com/2009/11/long-running-haskell-applications.html Dave ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Long running Haskell program
On Wed, Nov 11, 2009 at 8:20 AM, Andy Stewart lazycat.mana...@gmail.comwrote: David Leimbach leim...@gmail.com writes: As some of you may know, I've been writing commercial Haskell code for a little bit here (about a year and a half) and I've just recently had to write some code that was going to run have to run for a really long time before being restarted, possibly months or years if all other parts of the system cooperate as it's part of a server infrastructure management system. I recently ran into some serious space leak difficulties that would ultimately cause this program to crash some time after startup (my simulator is also written in Haskell, and runs a LOT faster than the real application ever could, this has enabled me to fast forward a bit the data growth issues and crash in minutes instead of days!) Anyway, rather than try to paste it all here with images and such I thought I'd stick it up on my blog so others could maybe benefit from the anecdote. It's difficult to disclose enough useful information as it is commercial code not under an open source license, but there's neat diagrams and stuff there so hopefully the colors are at least amusing :-) http://leimy9.blogspot.com/2009/11/long-running-haskell-applications.html Can you copy you blog at here? http://leimy9.blogspot.com/2009/11/long-running-haskell-applications.html is filter by GFW (http://en.wikipedia.org/wiki/Golden_Shield_Project) i can't see it. About crash free program, you can consider multi-process design, keep Simple and Stable core running in RootProcess, and Core module won't crash, and make unstable module running in ChildProcess, if you occur some un-catch exception from ChildProcess, just reboot those sub-module. Believe it or not, this is a stack of Erlang - Haskell - C. It works via pipes and is a concurrent system of management. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Long running Haskell program
On Wed, Nov 11, 2009 at 9:51 AM, Bryan O'Sullivan b...@serpentine.comwrote: On Wed, Nov 11, 2009 at 7:43 AM, David Leimbach leim...@gmail.com wrote: I recently ran into some serious space leak difficulties that would ultimately cause this program to crash some time after startup (my simulator is also written in Haskell, and runs a LOT faster than the real application ever could, this has enabled me to fast forward a bit the data growth issues and crash in minutes instead of days!) It sounds to me like you were storing a Map in a StateT. Since the usual State and StateT monads don't force the evaluation of their payload, I'm not terribly surprised that such a leak should arise. That's exactly what was happening. The system was being far too lazy (by choices I made but didn't fully understand). By pulling the Map out of the state, and pushing it back into the state, as the definition of my looping, things got a lot better. I didn't see another *easy* way to force the state to be evaluated, except by doing IO on intermediate values. seq will only evaluate strictly if it's just underneath something else that's already been evaluated :-). The runtime doesn't look for seqs to force evaluation on. I figured I was better off just creating a dependency in the evaluation, near the outermost portion of the program (the loop) that would cause a strict evaluation, and so far I was right :-) Program behaves very well now, and responds much better too. Dave ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Long running Haskell program
On Wed, Nov 11, 2009 at 10:29 AM, David Menendez d...@zednenem.com wrote:
On Wed, Nov 11, 2009 at 1:09 PM, Matthew Pocock
matthew.poc...@ncl.ac.uk wrote:
Is there a state monad that is strict on the state but lazy on the
computation? Of course, strictness in the state will force a portion of
the
computation to be run, but there may be significant portions of it which
are
not run. Would there be a way to write a state monad such that it is
entirely lazy, but then to wrap either the computation or the state in an
'eager' strategy datatype which takes care of this in a more flexible
manner?
I think replacing put s with put $! s should guarantee that the
state is evaluated.
If you're using get and put in many place in the code, you could try
something along these lines:
newtype SStateT s m a = S { unS :: StateT s m a } deriving (Monad, etc.)
instance (Monad m) = MonadState s (SStateT s m) where
get = S get
put s = S (put $! s)
That's interesting, and once I have time to come back to this part of the
project (I was behind schedule at this point!) I'll try something like that.
--
Dave Menendez d...@zednenem.com
http://www.eyrie.org/~zednenem/
___
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] Long running Haskell program
On Wed, Nov 11, 2009 at 11:19 AM, Don Stewart d...@galois.com wrote: leimy2k: I figured I was better off just creating a dependency in the evaluation, near the outermost portion of the program (the loop) that would cause a strict evaluation, and so far I was right :-) Program behaves very well now, and responds much better too. Do you know if Control.Monad.State.Strict is enough to get the behaviour you need? I'll give that a go. Most of my trouble figuring out the space leak has been around identifying what was really responsible for the problem. The functions that were listed as eating the space in -hc runs were not ultimately the ones causing the lack of strictness, in that they would have had to have been evaluated at a higher layer in a non-lazy way. So my take away from all of this is, when you have a space leak in haskell, start from the outer most evaluations inward, not the other way around!!! I think that would have saved me a ton of time. Dave -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What's the deal with Clean?
On Tue, Nov 3, 2009 at 10:44 PM, Ben Lippmeier ben.lippme...@anu.edu.auwrote: David Leimbach wrote: I have to admit, the first time I hit the wiki page for DDC I said to myself Self, this sounds crazy complicated. Then I read part of the PDF (your thesis I believe) about Region Types on the bus ride to work and thought. Gee I think I scared myself off too quickly. Uniqueness typing is quite interesting in Clean, but to control aliasing, like really *control* aliasing, that's just far out man. So I still have to wrap my head around why this isn't going to get completely out of control and see why it's all safer than just writing C code but I must say the attention I will be paying to DDC has just gone quite a bit up. :) A correct C program is just as safe as a correct Haskell/Disciple program. Well, of course, the question is in what sort of guarantees a language or compiler provides I guess. If you're using destructive update then aliasing, side effects and mutability all start to matter. It might look complicated when you reflect all these things in the type system, but you're really just getting a handle on the inherent complications of the underlying program. So it's just really more notation to let you know which tools are being used when you use them? Does Disciple completely avoid the need for such things as unsafePerformIO? (a perhaps overly paranoid comment but...) I realize we're probably not supposed to worry about the existence of unsafePerformIO, and that library authors know what they're doing. But doesn't it automatically mean that there's a bit of implicit trust whenever I see a function that's of type (a - a) that there *isn't* IO going on in there? :-) If Disciple can guarantee that no one is allowed to cheat, is that not a better approach? I suppose the trick is to be able to ignore said complications when you just don't care, or they're not relevant for your particular problem... Yes, the Disciple documentation says that this stuff can be inferred, but I don't even let Haskell infer my types for *any* functions I write in any code. I like to restrict what can go in and out of the function even if it's more general. Perhaps this is the knee-jerk reaction of an angry Erlang programmer who really wanted some types to reign in the overly-dynamic evaluations that are allowed in that environment, but that's how I roll baby! I will admit that on occasion I will write and expression that I think does what I want, and look at in in ghci, having it tell me the type because sometimes I've not had enough coffee to do it in my head, but I either look at the inferred type and realize that it's what I originally wanted, or add further restrictions. Dave Ben. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What's the deal with Clean?
On Wed, Nov 4, 2009 at 7:11 AM, Edsko de Vries edskodevr...@gmail.comwrote: On 4 Nov 2009, at 13:36, Alberto G. Corona wrote: Artyom. I know what uniqueness means. What I meant is that the context in which uniqueness is used, for imperative sequences: (y, s')= proc1 s x (z, s'')= proc2 s' y . is essentially the same sequence as if we rewrite an state monad to make the state explicit. When the state is the world state, then it is similar to the IO monad. Yes, as long as there is a single thing that is being updated there's little difference between the state monad and a unique type. But uniqueness typing is more general. For instance, a function which updates two arrays f (arr1, arr2) = (update arr1 0 'x', update arr2 0 'y') is easily written in functional style in Clean, whereas in Haskell we need to sequentialize the two updates: f (arr1, arr2) = do writeArray arr1 0 'x' writeArray arr2 0 'y' Those sequential updates can be run concurrently on both, just with different syntax though right? You can find a more detailed comparison in my thesis ( https://www.cs.tcd.ie/Edsko.de.Vries/pub/MakingUniquenessTypingLessUnique-screen.pdf, Section 2.8.7). -Edsko ___ 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] multi-line regex
Multi-line regular expressions are indeed powerful. Rob Pike has a good
paper on it available at:
http://doc.cat-v.org/bell_labs/structural_regexps/se.pdfhttp://code.google.com/p/sregex/
http://code.google.com/p/sregex/Explains how line-based regular
expressions are limiting etc.
The Sam and Acme editors supported these.
Python does too now.
http://code.google.com/p/sregex/
On Wed, Nov 4, 2009 at 6:17 AM, kenny lu haskellm...@gmail.com wrote:
Michael,
Here is how I do it.
module Main where
import Text.Regex.Posix.ByteString
import Data.Maybe
import qualified Data.ByteString.Char8 as S
text = S.pack 11\n abcd \n22
p = S.pack 11\n(.*)\n22
main :: IO ()
main =
do { (Right pat) - compile compExtended execBlank p
; res - regexec pat text
; case res of
{ (Right (Just (_,_,_,m))) - putStrLn (show m)
; _- putStrLn not matched.
}
}
You may swap out ByteString with String,
PCRE should be similar, too.
Regards,
Kenny
On Wed, Nov 4, 2009 at 2:04 PM, Michael Mossey m...@alumni.caltech.eduwrote:
kenny lu wrote:
Hi Michael,
Could you give an example of what patterns you want to write?
Regards,
Kenny
Something like
text = 11\n abcd \n22
answer = text =~ 11.*22 :: various possibilities
and have it find the entire string. The default behavior is to stop
matching when it encounters a newline. There is mention in the
Text.Regex.Posix docs of a flag to control this behavior, but it is not easy
to figure out from the docs how to provide flags. The left-hand side of the
=~ is a very complex type.
___
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
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What's the deal with Clean?
On Tue, Nov 3, 2009 at 3:14 PM, Ben Lippmeier ben.lippme...@anu.edu.auwrote: David Leimbach wrote: Disciplined Disciple might be interesting to look at here too, but i'm not sure I'd deploy anything with DDC just yet :-) :) Nor would I (and I wrote most of it). I think the approach is right, but the compiler itself is still in the research prototype stage. Ben. I have to admit, the first time I hit the wiki page for DDC I said to myself Self, this sounds crazy complicated. Then I read part of the PDF (your thesis I believe) about Region Types on the bus ride to work and thought. Gee I think I scared myself off too quickly. Uniqueness typing is quite interesting in Clean, but to control aliasing, like really *control* aliasing, that's just far out man. So I still have to wrap my head around why this isn't going to get completely out of control and see why it's all safer than just writing C code but I must say the attention I will be paying to DDC has just gone quite a bit up. Dave ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What's the deal with Clean?
On Tue, Nov 3, 2009 at 2:16 PM, Tracy Wadleigh tracy.wadle...@gmail.comwrote: I had to implement a ring buffer, and I wanted the code using it to be written in Haskell. I ended up implementing the buffer in C, and wrapping it in FFI from Haskell because implementing a destructive array in Haskell is kind of unwieldy to someone of my experience level. In Clean, it looks like the uniqueness typing allows for destructive updates in a very controlled manner. The ST monad provides this functionality. The never-instantiated-in-a-visible-way state parameter of the ST monad provides the uniqueness required for doing destructive updates in a pure way. Someone suggested that to me on IRC once I'd already cranked out a C implementation with FFI bindings. It's just too easy to use the FFI in Haskell :-) If we raise the barrier of FFI, more people will use ST! Dave ___ 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
