- Haskell-Cafe - Haskell.org

Is it possible to have constant-space JSON decoding?
by oleg＠okmij.org 15 Dec '12

15 Dec '12

I am doing, for several months, constant-space processing of large XML files using iteratees. The file contains many XML elements (which are a bit complex than a number). An element can be processed independently. After the parser finished with one element, and dumped the related data, the processing of the next element starts anew, so to speak. No significant state is accumulated for the overall parsing sans the counters of processed and bad elements, for statistics. XML is somewhat like JSON, only more complex: an XML parser has to deal with namespaces, parsed entities, CDATA sections and the other interesting stuff. Therefore, I'm quite sure there should not be fundamental problems in constant-space parsing of JSON. BTW, the parser itself is described there http://okmij.org/ftp/Streams.html#xml

5 5

edge: compile testing
by Christopher Howard 15 Dec '12

15 Dec '12

Hey guys, to teach myself Haskell I wrote a little arcade game called The Edge, built on gloss. It is in hackage under the package name "edge". Are there a few kind souls who would be willing to compile it on their machines and let me know if there are any problems at the compiling level? In the past, I've had issues with Haskell code compiling fine on my development system but not on others (due to dependency-related issues). I want to double check this before I try to make any distro-specific packages. I developed with GHC 7.4 and cabal-install 1.16.0.2 on a Gentoo system. Requires OpenGL and OpenAL (for sound). cabal update && cabal install edge -- frigidcode.com

3 3

LGPL and Haskell (Was: Re: ANNOUNCE: tie-knot library)
by Petr P 14 Dec '12

14 Dec '12

2012/12/12 David Thomas <davidleothomas(a)gmail.com> > IANAL, but reviewing what others have written, it sounds like it may be > possible to maintain *some* distinction between LGPL and GPL in Haskell, > but it's a different distinction than with an LGPL shared library, so even > if applicable it's certainly worth being aware of. > > It sounds (and I'd very much like clarification) like providing source of > an application to users *without* license to redistribute, which can be > built using an LGPL library, would be compliant - whereas if the library > was GPL this would not be the case? > > As I understand it, this is one of the main differences: Using GPL-ed library forces the entire Combined Work to be GPL-ed (requiring to release the source codes), while using LGPL-ed library forces only the possibility to re-link with another version of it - you can distribute your own sources to users with whatever license you like (unless it's a modification of the library, of course). This could be an interesting question for FSF. Thanks to all for valuable comments. I didn't want to start a discussion about (L)GPL vs others, but since that already happened, let me give my opinion: First, LGPL has been discussed already: http://www.haskell.org/pipermail/haskell-cafe/2007-March/023158.html The problem with LGPL is that it is apparently tailored to languages that strongly rely on dynamic linking. TBH I wasn't aware of this before. One solution (taken by wxWidgets for example) is to modify LGPL so that they explicitly allow distributing the software without the re-linking requirement (which grants a little less rights to end users). I tried asking that on StackExchange: "Is there a modified LGPL license that allows static linking?" <http://programmers.stackexchange.com/q/179084/61231> Anther solution would be to focus on improvements of dynamic linking. Some links I found: http://hackage.haskell.org/trac/ghc/wiki/SharedLibraries/PlatformSupport Haskell Static vs Dynamic Linking in Deployment < http://stackoverflow.com/q/7854614/1333025> Small Haskell program compiled with GHC into huge binary < http://stackoverflow.com/q/6115459> Yet another solution would be what David Thomas suggest: To provide the source code to your users, but don't allow them to use the code for anything but relinking the program with a different version of the library (no distribution, no modification etc.). <http://www.haskell.org/pipermail/haskell-cafe/2007-March/023158.html> Second, it's my wish to use (L)GPL for FOSS programs I write. My opinion has varied for many years, but in recent years I strongly incline to GPL-like licenses. We all know that GPL-like licenses make life more complicated for us programmers. Programmers want to use libraries with as little restrictions as possible. The main reason for me for choosing (L)GPL despite the complications is the protection and rights it gives to the *users* of a program. Sadly, no users are actually aware of this and what they could gain by choosing GPL-ed programs (let me know if you find a non-programmer who is aware of GPL's benefits). Just imagine if Facebook had to use AGPL, or if your mobile phone software would be all GPL. (Knowing what a program does with your data is becoming more important, like the US intelligence report suggests: http://reut.rs/UxbLtvsection "Technology .."). The other reason for me that GPL-like licenses give an advantage to FOSS developers over private companies. I feel this is fair - anybody who develops something that can be used by everyone deserves an advantage. Another thing to consider is the aspect of adoption/marketing strategy. Using a more permissive license can make adoption of a piece of software much faster. This can be desirable in some cases, like if the OS community wants to prevent the adoption of proprietary standards (like Vorbis VS MP3). Or in the case of Haskell, to motivate private companies to use it. Richard Stallman himself recommends this in some cases http://lwn.net/2001/0301/a/rms-ov-license.php3 But if a project is strong enough, using (L)GPL can actually strengthen it, like in the case of Linux VS NetBSD: http://www.dwheeler.com/blog/2006/09/01/#gpl-bsd To quote: "So while the BSDs have lost energy every time a company gets involved, the GPL'ed programs gain every time a company gets involved." Of course I respect other opinions in that matter, every author is free to use whatever licence (s)he likes. After all, FOSS is about freedom. The important thing to know is what advantages and drawbacks each license has and what are the consequences of using them. Best regards, Petr

14 19

Re: [Haskell-cafe] ANNOUNCE: tie-knot library
by Niklas Larsson 14 Dec '12

14 Dec '12

Yes, if you link statically, if you want to distribute without giving away source (or relinkable object files) you can link dynamically or use integer-simple in your GHC. Niklas ----- Ursprungligt meddelande ----- Från: "Herbert Valerio Riedel" <hvr(a)gnu.org> Skickat: ‎2012-‎12-‎14 11:55 Till: "Brandon Allbery" <allbery.b(a)gmail.com> Kopia: "Ramana Kumar" <Ramana.Kumar(a)cl.cam.ac.uk>; "haskell-cafe" <haskell-cafe(a)haskell.org> Ämne: Re: [Haskell-cafe] ANNOUNCE: tie-knot library Brandon Allbery <allbery.b(a)gmail.com> writes: > Haskell libraries are mostly BSD licensed, as is GHC itself. (Oddly > enough, GPL is not the only open source license.) btw, what about GHC's reliance on the LGPLed GMP library? Doesn't that already taint the whole GHC eco-system? Quoting [1]: | GMP is licensed under the GNU Lesser General Public License (LGPL), a | kind of "copyleft" license. According to the terms of the LGPL, | paragraph 5, you may distribute a program that is designed to be | compiled and dynamically linked with the library under the terms of | your choice (i.e., commercially) but if your program incorporates | portions of the library, if it is linked statically, then your program | is a "derivative"--a "work based on the library"--and according to | paragraph 2, section c, you "must cause the whole of the work to be | licensed" under the terms of the LGPL (including for free). | | The LGPL licensing for GMP is a problem for the overall licensing of | binary programs compiled with GHC because most distributions (and | builds) of GHC use static libraries. (Dynamic libraries are currently | distributed only for OS X.) The LGPL licensing situation may be worse: | even though The Glasgow Haskell Compiler License is essentially a | "free software" license (BSD3), according to paragraph 2 of the LGPL, | GHC must be distributed under the terms of the LGPL! [1]: http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes#ReasonsforReplac… cheers, hvr _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

2 1

ANNOUNCE: tie-knot library
by Petr P 14 Dec '12

14 Dec '12

Dear Haskellers, I'd like to announce a small library "tie-knot": "Ties the knot" on a given set of structures that reference each other by keys - replaces the keys with their respective values. Takes Map k (v k) and converts into Map k v' where v' is the fixed point of v. Motivation: I needed to assemble a finite-state machine from an external description where each node was described by some identifier. I needed a simple library that would replace all key referencess with the actual values. See https://github.com/ppetr/tie-knot for examples. Hackage: http://hackage.haskell.org/package/tie-knot - Petr Pudlak

13 18

How to start with GHC development?
by Janek S. 14 Dec '12

14 Dec '12

Dear list, I would like to learn about internals of GHC and contribute to its development in the future. I read a couple of papers that give a very general overview of GHC (chapter from AoS, papers about inliner and multicore support) and I'm thinking what direction should I pursue now. I was thinking about: a) getting GHC sources, reading the commentary on the GHC wiki and hacking the code b) reading SPJs "Implementing Functional Languages: a tutorial" c) reading SPJs "The Implementation Of Functional Languages" book I would definitely go for a), but I don't know if I'll manage to understand the code without knowing how functional languages are compiled. I have a rather basic knowledge of compilers in general - I took Stanford's online course on Compilers at Coursera. Should I get more theoretical knowledge? Any advice is greatly appreciated. Janek

5 8

Second Call for Copy: Monad.Reader #21
by Edward Z. Yang 13 Dec '12

13 Dec '12

Second Call for Copy: The Monad.Reader - Issue 21 ------------------------------------------------- Whether you're an established academic or have only just started learning Haskell, if you have something to say, please consider writing an article for The Monad.Reader! The submission deadline for Issue 21 will be: **Tuesday, January 1** Less than half a month away, but that's what Christmas break is for, right? :-) The Monad.Reader ~~~~~~~~~~~~~~~~ The Monad.Reader is a electronic magazine about all things Haskell. It is less formal than journal, but somehow more enduring than a wiki- page. There have been a wide variety of articles: exciting code fragments, intriguing puzzles, book reviews, tutorials, and even half-baked research ideas. Submission Details ~~~~~~~~~~~~~~~~~~ Get in touch with me if you intend to submit something -- the sooner you let me know what you're up to, the better. Please submit articles for the next issue to me by e-mail (ezyang(a)mit.edu) Articles should be written according to the guidelines available from http://themonadreader.wordpress.com/contributing/ Please submit your article in PDF, together with any source files you used. The sources will be released together with the magazine under a BSD license. If you would like to submit an article, but have trouble with LaTeX please let me know and we'll work something out.

1 0

ANNOUNCE: hoodle : Pen note-taking program written in haskell
by Ian-Woo Kim 13 Dec '12

13 Dec '12

Hi, Haskellers! I am happy to announce hoodle : pen note-taking program written in haskell. Hoodle is a continuation of the development of hxournal. I renamed it to hoodle, apparently meaning Haskell + doodle. It has undergone many changes and bug fixes. Hopefully, this program is now useful to users. See how it works in action : http://www.youtube.com/watch?v=Z2wzpyxsVSU Hoodle has been uploaded on hackage and is installable using cabal. After the installation of gtk2hs, you can install it by simply typing > cabal install hoodle As a default, pdf annotation is turned off, but if you have installed poppler, then you can install hoodle with pdf-annotation function by typing > cabal install -fpoppler hoodle-render hoodle-core hoodle Hoodle Homepage is http://ianwookim.org/hoodle Have fun with hoodle! Thanks. best, Ian-Woo Kim

1 0

Kernel Loops in Accelerate
by Clark Gaebel 13 Dec '12

13 Dec '12

Hi Trevor (and cafe), I've been playing more and more with accelerate, and I find it quite annoying that there are no loops. It makes implementing many algorithms much harder than it should be. For example, I would love to submit a patch to fix issue #52 [0] on github by implementing MWC64X [1], but it's very hard to port the OpenCL code on that page when it's impossible to write kernel expressions with loops. Also, that means there are no high-level combinators I'm used to for my sequential code (such as map and fold) that would work on an accelerate CUDA kernel. As a nice strawman example, how would one implement the following kernel in accelerate, assuming 'rand_next', 'rand_get', and 'rand_skip' can all be implemented cheaply? : typedef uint64_t rand_state; __device__ rand_state rand_next(rand_state s); __device__ uint32_t rand_get(rand_state s); __device__ rand_state rand_skip(rand_state s, uint64_t distance); __device__ uint32_t round_to_next_pow2(uint32_t n); // Fills an array with random numbers given a random seed, // a maximum random number to generate, and an output // array to put the result in. The output will be in the range // [0, rand_max). __kernel__ void fill_random(rand_state start_state, uint32_t rand_max, uint32_t* out) { rand_state current_state = start_state; int i = blockDim.x*blockIdx.x + threadIdx.x; // assumes we skip less than 1 million times per element... current_state = rand_skip(current_state, i*1e6); uint32_t mask = round_to_next_pow2(rand_max) - 1; uint32_t result; do { result = rand_get(current_state); current_state = rand_next(current_state); } while(result & mask >= rand_max); out[i] = result; } // note: code was neither debugged, run, nor compiled. Thanks, - Clark [0] https://github.com/AccelerateHS/accelerate/issues/52 [1] http://cas.ee.ic.ac.uk/people/dt10/research/rngs-gpu-mwc64x.html

2 2

Control.bimap?
by Gregory Guthrie 13 Dec '12

13 Dec '12

I found a nice idiom for a graph algorithm where the pairs of nodes representing links could be merged into node lists by something like: ns = nub $ map fst g --head nodes ne = nub $ map snd g -- tail nodes And found a nicer approach: (ns,ne) = (nub***nub) unzip g Or perhaps: (ns.ne) = bimap nub nub $ unzip g -- from Control.Bifunctor The SO reference I saw described bimap as a way to map a function over a pair, and it seemed like a great match, but I cannot find the bimap function, and cabal reports no package Control.Bifunctor. ?? -------------------------------------------------------

4 5