- Haskell-Cafe - Haskell.org

lightweight alternative to mtl?
by Anton Kholomiov 17 Jun '12

17 Jun '12

What are you using instead of mtl? I need simple type for State. The more classy it gets the harder error messages are to understand. I've installed new package. Silently it installed new mtl. And here I'm staring into three lines of code for half an hour trying to understand where I misused the types. Compiler tells me long story about functional dependencies. After downgrade it takes me a second to find the mistake. Ohh type mismatch, forgot to pass an argument. It's class for strict and lazy states. Maybe it's better to take approach of containers (the same interface and different modules)? Anton

4 4

Re: [Haskell-cafe] Safe Haskell at the export symbol granularity?
by Ryan Newton 17 Jun '12

17 Jun '12

Thanks David. I'm glad to see it was discussed in the wiki. (Btw, my 2 cents is that I like the comment pragmas more than new keywords.) The issue that I think doesn't make it into the wiki is of splitting, not modules, but* type-classes*. That's where I think it becomes a more serious issue. Do you think a symbol-level Safe Haskell would be able to distinguish one method of a type class as unsafe, while the others are safe? -Ryan P.S. In my two examples -- There's only one "Acc" type and Accelerate's "fold" can pretty easily be moved into an .Unsafe module, though it breaks the one-giant-module-for-the-whole-programming-model thing it has going now. In the Par example on the other hand type classes are used to abstract over different implementations, so that's where we run into the safe/unsafe factoring problem.

4 7

Data.Binary hanging when used with socket - feature?
by Paul Brenman 17 Jun '12

17 Jun '12

I'm using the 0.5.1.0 binary package (i.e. Data.Binary/Data.Binary.Get) to encode/decode a lazy bytestring. Unfortunately, decode/get are hanging, possibly due to the underlying chunking logic in Data.Binary.Get. The lazy bytestring is being populated from a socket (via "socketTohandle sock ReadWriteMode . hGetContents"). Periodically, encoded data structures are received from the socket. When the encoded data structure happens to end exactly on a chunk boundary, and in my specific case the final encoded item is an Int(64), the Data.Binary.Get.getBytes function wants to force the next chunk to be read into the lazy bytestring before returning the decoded item (see comment in file at line 333 that reads "forces the next chunk before this one is returned"). Unfortunately, since the socket is not yet ready to send anything the call to decode/get hangs. The assumption seems to be that the lazy bytestring isn't populated from a source that can potentially block. Is this reading correct? If so, are there any workarounds? Appreciate any advice - production code.

2 1

event handler
by Corentin Dupont 17 Jun '12

17 Jun '12

Hi folks, I'm trying to make a simple event driven engine. It simply consists of two functions: - "addEvent", where you pass the event name with a callback, - "triggerEvent" where you pass the event name with the data. the data shall be passed to the callback of the corresponding event. I have trouble making it correctly typed. Here is my try: * type Player = Int --dummy types for the example type Rule = Int data EventEnum = NewPlayer | NewRule deriving Eq data Data = P Player | R Rule data Handler = H (Data -> IO ()) addEvent :: EventEnum -> Handler -> [(EventEnum, Handler)] -> [(EventEnum, Handler)] addEvent e h es = (e,h):es triggerEvent :: EventEnum -> Data -> [(EventEnum, Handler)] -> IO () triggerEvent e d es = do let r = lookup e es case r of Nothing -> return () Just (H h) -> h d* The trouble is that I want the user to be only able to add an event that is compatible with its handler: For example the event NewPlayer should have a handler of type Player -> IO (). The data passed when triggering this event should be only of type Player. How can I do that? It sound like dependant typing... Thanks! Corentin

2 11

Haskell is rapidly approaching the top 20
by Henk-Jan van Tuyl 16 Jun '12

16 Jun '12

L.S., From the TIOBE web site[0]: -----✂---- TIOBE Programming Community Index for June 2012 June Headline: Haskell is rapidly approaching the top 20 Last month we asked ourselves the question what language could become the next big new programming language. We suggested several candidates such as Scala, Erlang and Clojure. Clearly, the new thing was expected to come from the functional programming field. A functional language not explicitly mentioned was Haskell. And this month it was Haskell that jumped from #35 to #25. Looking at the TIOBE trend graph of Haskell (starting in 2003) it shows a constant rise, with peaks in 2006, 2010 and now in 2012. This certainly sounds promising. -----✂---- Regards, Henk-Jan van Tuyl [0] http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming --

2 1

ANN: GHC-7.4.2-Eden - Parallel Haskell on multicore and cluster systems
by Eden - Functional parallel Programming (Mischa Dieterle) 16 Jun '12

16 Jun '12

We are happy to announce a new release of Eden, a parallel extension of Haskell. The release comprises: * The GHC-7.4.2-Eden compiler: GHC-7.4.2 extended with the Eden parallel runtime system. * The Eden modules: a library defining the Eden language constructs. * The Eden skeleton library: a comprehensive library with common task and data parallel patterns. * The Eden trace viewer EdenTV: an visualisation and analysis tool for eventlogs of parallel program runs. All resources are available via: http://www.mathematik.uni-marburg.de/~eden Eden extends Haskell with a small set of syntactic constructs for explicit process specification and creation. While providing enough control to implement parallel algorithms efficiently, it frees the programmer from the tedious task of managing low-level details by introducing automatic process handling, synchronisation and communication (via head-strict lazy lists). Eden is tailored for distributed systems but works equally well on multicore architectures. Processes work within disjoint address spaces and do not share any data. This simplifies Eden's implementation as there is no need for global garbage collection. A tutorial is available from http://www.mathematik.uni-marburg.de/~eden/paper/edenCEFP.pdf The compiler release includes binary packages for Linux and Windows, and a source distribution, available from http://www.mathematik.uni-marburg.de/~eden/?content=down_eden_7_4&navi=down Other features: - Extensions for GHC's event logging support. - Built-in serialisation of Haskell data structures (orthogonal to evaluation), see "Orthogonal Serialisation for Haskell", available from http://www.diku.dk/hjemmesider/ansatte/berthold/jbpubl.html - Optimised local communication. - Stand-alone version for multicore, using middleware MPI or PVM for clusters. Eden libraries and tools are available separately from hackage: - Eden modules: http://hackage.haskell.org/package/edenmodules (already included in the Eden compiler) - Eden skeleton library: http://hackage.haskell.org/package/edenskel - EdenTV: http://hackage.haskell.org/package/edentv (uses gtk2hs and glade) When built using a standard GHC, the packages will produce a threaded simulation of Eden.

1 0

FunctionalOWL: FP Usergroup in Germany, area Bielefeld
by raichoo 16 Jun '12

16 Jun '12

Announcing FunctionalOWL in Bielefeld! Next Wednesday will be the first meetup of the FunctionalOWL at Hackerspace Bielefeld. The meetup is aimed at people who are interested in functional programming. FunctionalOWL wants to provide a wide range of interesting topics and opportunities to share and acquire knowledge. Become a part of it. When: Wed 20 June @ 19:00 Where: Sudbrackstraße 42, Bielefeld Followup meetups are planned to happen every 3rd Wednesday at the same location. We have various beamers and whiteboards. Internet and caffeinated lemonade are also available. For more information and contact, check out our website. Feel free to drop a message on our pubML or in our Chatroom. www.hackerspace-bielefeld.de Kind regards, raichoo, Hackerspace Bielefeld

1 0

Performance with do notation, mwc-random and unboxed vector
by Dmitry Dzhus 15 Jun '12

15 Jun '12

Hello everyone. I wonder why using do notation with `<-` can ruin the performance. In essence the problem is that, for some action `f :: m Double`, running the code (in my case, `standard` from mwc-random). f for million times is fast but the code do v <- f return v is slower about a hundred times. Consider this simple source where we generate an unboxed vector with million pseudo-random numbers: ---- 8< ----- import qualified Data.Vector.Unboxed as VU import System.Random.MWC import System.Random.MWC.Distributions (standard) count = 1000000 main = do g <- create e' <- VU.replicateM count $ standard g return () ---- >8 ----- Being compiled with -O2, this runs for 0.052 s on my machine. Changing the replicateM line to use do notation brings the runtime down to 11.257 s! See below: ---- 8< ----- import qualified Data.Vector.Unboxed as VU import System.Random.MWC import System.Random.MWC.Distributions (standard) count = 1000000 main = do g <- create e' <- VU.replicateM count $ do v <- standard g return v return () ---- >8 ----- I don't quite understand why this happens. I'm using GHC 7.4.1 on Linux x86_64 system. Compiling *both* versions with profiling enabled changes runtime to 5.673 sec, which is exactly half the runtime of slow version without profiling, and this is awkward (double calculations occuring in do block?). Does anybody have an idea if this is a problem with my do, or with mwc-random, or with vector (my notation disallowing efficient unboxing?).

5 7

Re: [Haskell-cafe] ANN: Portackage - a hackage portal
by Andrew Seniuk 15 Jun '12

15 Jun '12

Hi ___, Thank you for your suggestion to provide JSON, which seconds Derek's earlier suggestion. I have anonymised your name since you wrote to me but didn't CC the list. :) As much as I wish the web interface was up to snuff, it is really too slow. While I continue to try to resolve that, there is something like a JSON feed available now. I'm new to these things and may be doing it wrong. Any advice would be appreciated, either in accelerating the web interface or in providing the JSON. I have no idea whether it parses or not. JSON Schema: http://www.fremissant.net/portackage/packages.schema.json.txt Hopefully compressed JSON data: http://www.fremissant.net/portackage/packages.php Raw JSON data in case the compressed doesn't work: http://www.fremissant.net/portackage/packages.json The hackage data updated as of today (June 14). For now this is only the packages which expose modules (i.e. not including binary packages). No particular reason, I just ran out of time this afternoon and thought I'd post what I've got. The fields present in the JSON are those available on the HTML table version. There are several dozen other fields which come up more or less infrequently in the Hackage packages, and they could all be included. The complete list of modules is included (rather than the summary versions used in the HTML table version). A next step would be for the server to incrementally update the JSON data based on the Hackage RSS feed. Kind Regards, Andrew On Wed, Jun 13, 2012 at 7:58 AM, ___ wrote: > Hi Andrew > > Portackage is a great site for browsing packages, but it's really > really slow for filtering per column. What about offering an > additional non-javascript version of the pages -- searching with plain > text in a browser works quite well. > > On 4/30/12, Andrew Seniuk <rasfar(a)gmail.com> wrote: >> Oops, the three links in summary are: >> >> module tree: http://fremissant.net/portackage/modules.php >> library packages: http://fremissant.net/portackage/portackage.php >> other packages: http://fremissant.net/portackage/binary.php >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > -- > ___

1 2

Installing pandoc / json with ghc 6.12.1
by Rico Moorman 15 Jun '12

15 Jun '12

Hello, I recently tried to install the latest version of pandoc on my debian stable box (with ghc 6.12.1) using virthualenv as sandboxing mechanism. But instead of a normal installation, compilation of the json package (more specifically the Text.JSON.Parsec module) hangs and causes ghc to consume around 2GB of RAM (out of 3GB) and the system to swap and hang. For reference ... I just created a plain virthualenv (for sandboxing) and after that ran (tmp) foo@bar:/tmp$ cabal install json I also tried if this has something to do with version 0.5 (the latest version) only, to no avail. Are there other users of pandoc/json or related packages who encountered/solved this issue? Am I doing something wrong here? Best regards, Rico

2 1