News aggregator

SIGPLAN John C Reynolds Doctoral Dissertation Award

General haskell list - Sun, 11/22/2015 - 2:02pm
Dear All, I would like to draw your attention to the SIGPLAN John C. Reynolds Doctoral Dissertation Award. If you are (or will be) a 2015 PhD graduate with a great thesis or a supervisor of such a graduate can I suggest you consider applying? Obtaining such an award makes a person stand out when applying for positions. The nomination process is straightforward and nominations are due on the 5th of January. Details of the award can be found at . If you have any questions, please contact Susan Eisenbach (CC'd). Cheers, Jeremy Jeremy.Gibbons< at > Oxford University Department of Computer Science, Wolfson Building, Parks Road, Oxford OX1 3QD, UK. +44 1865 283521 _______________________________________________ Haskell mailing list Haskell< at >
Categories: Incoming News

type operators and colon in GHC

haskell-cafe - Sun, 11/22/2015 - 6:40am
According to sections 7.4.3 and 7.4.4 of the latest Haskell documentation you can define (7.4.3) an infix type constructor as long as it begins with a colon, for example data a :*: b = Foo a b and furthermore (7.4.4) you can define an infix operator without having to use a colon if you enable the TypeOperators extension: data a * b = Foo a b However if I try the former without using TypeOperators I get this compiler error in 7.10.2: Illegal declaration of a type or class operator ‘:*:’ Use TypeOperators to declare operators in type and declarations Using TypeOperators fixes this, but then * without colon also works so I don't see the point of using colon anymore. My guess is this was some some kind of historical distinction which is no longer valid and the documentation needs to be updated. Is this true, or am I missing something? John _______________________________________________ Haskell-Cafe mai
Categories: Offsite Discussion

ANN: prefix-units 0.2.0

haskell-cafe - Sun, 11/22/2015 - 4:03am
Hi all, New version of my small library prefix-units (for parsing and formatting things like "10K"). Changes: * Incompatible API change to cleanup some initial design decisions: the two level `FormatOption`/`FormatMode` model is removed, the fixed unit of `FormatOption` is moved to a new constructor `FormatMode`, and `FormatOption` is removed entirely. This should be a simpler API, at the cost of breaking compatibility. * Fixed issue #3 (No support for negative numbers). * Worked around issue #1 (Add 'base' unit) by adding a mode that disables scaling; it should have the same effect without introducing an artificial unit. Feedback welcome, either via email or at happy hacking, iustin
Categories: Offsite Discussion

Warning: Tab Character

haskell-cafe - Sat, 11/21/2015 - 9:12pm
Hello everyone. I am a newbie of Haskell, using Textmate on mac. I got the following warning. How can I fix it? Warning: Tab character Ok, modules loaded: Main. Sincerely, Young _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >
Categories: Offsite Discussion

NNOUNCE: Haskell Communities and Activities Report (29th ed., November 2015)

haskell-cafe - Sat, 11/21/2015 - 8:13pm
On behalf of all the contributors, we are pleased to announce that the Haskell Communities and Activities Report (29th edition, November 2015) is now available, in PDF and HTML formats: Many thanks go to all the people that contributed to this report, both directly, by sending in descriptions, and indirectly, by doing all the interesting things that are reported. We hope you will find it as interesting a read as we did. If you have not encountered the Haskell Communities and Activities Reports before, you may like to know that the first of these reports was published in November 2001. Their goal is to improve the communication between the increasingly diverse groups, projects, and individuals working on, with, or inspired by Haskell. The idea behind these reports is simple: Every six months, a call goes out to all of you enjoying Haskell to contribute brief summar
Categories: Offsite Discussion

Another Thrift-related question

Haskell on Reddit - Sat, 11/21/2015 - 6:33pm

I'm trying to make a cabal package that uses Thrift and some Thrift specifications to generate a nice library. I've got it working to the point of generating code and exposing the basics: this leads to being able to import a lot of interdependent data type definitions with long fields like "typeName_fieldName".

Now I'd like to take these exposed types, and in another module, import them all and create lenses for each of them. This, too, is pretty much working, but I have the ugly problem of needing to get the list of data types and their fields, so that I can tell what needs to be lensed and exported. I could parse the generated files, but was wondering if there's a better way to do this (or even a completely trivial solution to "take every data type in this module and create a lens" and "export everything from this module." Thanks!

submitted by logical_space
[link] [2 comments]
Categories: Incoming News

filterM for Sequence ?

Haskell on Reddit - Sat, 11/21/2015 - 5:55pm

I'm replacing Vector with Sequence in my code to compare performance and I was surprised that I couldn't find a equivalent of filterM for Data.Seq. I've looked in Foldable and Traversable but I didn't find it. Am I missing something obvious or is there no filterM for Seq ? (If so why ?). Thanks

submitted by maxigit
[link] [23 comments]
Categories: Incoming News

A small Image-to-ASCII-Converter in Haskell

Haskell on Reddit - Sat, 11/21/2015 - 3:01pm

I saw someone blogging about this the other day. He did some Images and "painted" them in ASCII-Art in the console. I wanted to do the same for arbitrary images so i load the images using Juicy-Pixels, fold them with 2 functions and convert the resulting pixels into Strings for display.

You can preview the result of this in your terminal with:


currently you still have to specify the resulting dimensions of the ASCII-Art - this should become optional and just use the whole size of your terminal while preserving the aspect-ratio - but thats a thing for the future.

You can even pipe in arbitrary images from the web like

wget -O - 2> /dev/null | ./img2ascii - 100 40

As said, this was just a little fun-project, but maybe someone can learn from this by looking at the source - or improve it..

Getting this to run is just

git clone cd img2ascii stack build

the result is then somewhere in .stack-work/dist/$system/$cabal/build/img2ascii/ so a

ln -s ./stack-work/dist/*/*/build/img2ascii/img2ascii .

should do the trick and you can run it with

./img2ascii --help

pull requests welcome :)

submitted by Drezil
[link] [9 comments]
Categories: Incoming News

RDF with Haskell

haskell-cafe - Sat, 11/21/2015 - 4:35am
I am a newbie learning Haskell. I'd like to import RDF in Haskell as well as to do SPARQL. I went through RDF4H, Swish, and so on. But it is still difficult to understand them for me. Anyone can suggest me to learn that? or recommend any kinds of books or tutorials? Sincerely, Jeon-Young
Categories: Offsite Discussion

Leon P Smith: Announcing linux-inotify 0.3

Planet Haskell - Sat, 11/21/2015 - 3:13am

linux-inotify is a thin binding to the Linux kernel’s file system notification functionality for the Glasgow Haskell Compiler. The latest version does not break the interface in any way, but the implementation eliminates use-after-close file descriptor faults, which are now manifested as IOExceptions instead. It also adds thread safety, and is much safer in the presence of asynchronous exceptions.

In short, the latest version is far more industrial grade. It is the first version I would not hesitate to recommend to others, and the first version I have talked much about publicly. The only downside is that it does require GHC 7.8 or later, due to the use of threadWaitReadSTM to implement blocking reads.

File Descriptor Allocation

These changes were motivated by lpsmith/postgresql-simple#117, one of the more interesting bugs I’ve been peripherally involved with. The upshot is that it’s very probably a use-after-close descriptor fault: a descriptor associated with a websocket would close, that descriptor would be associated with a new description that would be a database connection, and then a still-active websocket thread would ping the database connection, causing the database server to hang up due to a protocol error. Thus, a bug in snap and/or websockets-snap manifested itself in the logs of a database server.

This issue did end up exposing a significant deficiency in my understanding of the allocation of file descriptors: for historical reasons, the POSIX standard specifies that a new description must be indexed by the smallest unused descriptor.

This is an unfortunate design from several standpoints, as it necessitates more serialization than would otherwise be required, and a scheme that seeks to delay reusing descriptors as long as practical would greatly mitigate use-after-close faults, as they would almost certainly manifest as an EBADF errno instead of a potentially catastrophic interaction with an unintended description.

In any case, one of the consequences of the POSIX standard is that a use-after-close descriptor fault is a pretty big deal, especially in a server with a high descriptor churn rate. In this case, the chances of an inappropriate interaction with the wrong descriptor is actually pretty likely.

Thus, in the face of new evidence, I revised my opinion regarding what the linux-inotify binding should provide; in particular protection against use-after-close. And in the process I made the binding safer in the presence of concurrency and asynchronous exceptions.

The Implementation

Due to the delivery of multiple inotify messages in a single system call, linux-inotify provides a buffer behind the scenes. The new implementation has two MVar locks: one associated with the buffer, and another associated with the inotify descriptor itself.

Four functions take only the descriptor lock: addWatch, rmWatch, close, and isClosed. Four functions take the buffer lock, and may or may not take the descriptor lock: getEvent, peekEvent, getEventNonBlocking, and peekEventNonBlocking. Two functions only ever take the buffer lock: getEventFromBuffer and peekEventFromBuffer.

The buffer is implemented in an imperative fashion, and the lock protects all the buffer manipulations. The existence of the descriptor lock is slightly frustrating, as the only reason it’s there is to correctly support the use-after-close protection; the kernel would otherwise be able to deal with concurrent calls itself.

In this particular design, it’s important that neither of these locks are held for any significant length of time; in particular we don’t want to block while holding either one. This is so that the nonblocking functions are actually nonblocking: otherwise it would be difficult for getEventNonBlocking to not block while another call to getEvent is blocked on the descriptor.

So looking at the source of getEvent, the first thing it does is to take the buffer lock, then checks if the buffer is empty. If the buffer not empty, it returns the first message without ever taking the descriptor lock. If the buffer is empty, it then also takes the descriptor lock (via fillBuffer) and attempts to read from the descriptor. If the descriptor has been closed, then it throws an exception. If the read would block, then it drops both locks and then waits for the descriptor to become readable before it tries again. And of course if the read succeeds, then we grab the first message, then drop the locks, and return the message.

getEvent :: Inotify -> IO Event getEvent inotify@Inotify{..} = loop where funcName = "System.Linux.Inotify.getEvent" loop = join $ withLock bufferLock $ do start <- readIORef startRef end <- readIORef endRef if start < end then (do evt <- getMessage inotify start True return (return evt) ) else fillBuffer funcName inotify -- file descriptor closed: (throwIO $! fdClosed funcName) -- reading the descriptor would block: (\fd -> do (waitRead,_) <- threadWaitReadSTM fd return (atomically waitRead >> loop) ) -- read succeeded: (do evt <- getMessage inotify 0 True return (return evt) )

So there are two points of subtlety worth pointing out in this implementation. First is the idiom used in loop: the main body returns an IO (IO Event), which is turned into IO Event via join. The outer IO is done inside a lock, which computes an (IO Event) to perform after the lock(s) are dropped.

The second point of subtlety is the case where the read would block. You may want to think for a minute why I didn’t write this instead:

\fd -> do return (threadWaitRead fd >> loop)

Because we don’t want to block other operations that need the buffer and/or file descriptor locks, we need to drop those locks before we wait on the descriptor. But because we are dropping those locks, anything could happen before we actually start waiting on the descriptor.

In particular, another thread could close the descriptor, and the descriptor could be reused to refer to an entirely new description, all before we start waiting. Essentially, that file descriptor is truly valid only while we hold the descriptor lock; thus we need to go through the process of registering our interest in the file descriptor while we have the lock, and then actually blocking on the descriptor after we have released the lock.

Now, this race condition is a relatively benign one as long as the new description either becomes readable relatively quickly, or that the descriptor is closed and GHC’s IO manager is aware the fact. In the first case, the threadWaitRead fd will unblock, and the thread will loop and realize that the descriptor has been closed, and throw an exception. In the second case, GHC’s IO manager will cause threadWaitRead fd to throw an exception directly.

But if you get very unlucky, this might not happen for a very long time, if ever, causing deadlock. This might be the case if say, the new descriptor is a unix socket to /dev/log. Or, if the reallocated descriptor is managed by foreign code, and is closed without GHC’s IO manager being made aware, it is quite possible that this could deadlock.

Categories: Offsite Blogs

ANN: cacophony 0.4.0, pipes-cacophony 0.1.2

General haskell list - Sat, 11/21/2015 - 12:18am
cacophony[1] is a library which implements the Noise[2] protocol. Noise is a framework for cryptographic protocols based on ECDH key agreement authored by Trevor Perrin. pipes-cacophony[3] builds on cacophony to provide pipes that facilitate key agreement and secure messaging (in conjunction with, for example, pipes-network).
Categories: Incoming News

On Hiatus Until January 2016: Haskell Weekly News

haskell-cafe - Fri, 11/20/2015 - 7:53pm
Regrettably, I must announce that Haskell Weekly News will go on hiatus until the new year. I recognize that the last issue was back in September. It's been said that "The more a man possesses over and above what he uses, the more careworn he becomes." In my case, mundane possessions have indeed insisted on being attended to. I wish every reader a fine holiday season.
Categories: Offsite Discussion

ANN: linearscan, linearscan-hoopl 1.0.0

General haskell list - Fri, 11/20/2015 - 7:44pm
linearscan[1] is a linear scan register allocator[2], written in Coq[3], and extracted to Haskell, as a library for Haskell programs that need to allocate registers. It may also be used directly from Coq. This project is the result of a year-long effort, funded by BAE Systems[4], to explore the application of dependent-types and mathematical verification to a typical engineering task. During the course of construction, several hundred theorems about the code were proven -- although exhaustive coverage was not, in the end, achievable given our time constraints. To remedy this, and as a test of the extraction to Haskell, an optional runtime verifier was built to certify the resulting allocations. Coq 8.5b2[5] was used, as well as the ssreflect[6] library created for that version[7]. linearscan further relies on another library, coq-haskell[8], that I created to facilitate inter-operation between Haskell and Coq. For those using Hoopl[9] to represent program graphs, incorporating linearscan is quite easy: pr
Categories: Incoming News

I want to create an automated prop. logic theorem verifier. Is Haskell a good choice?

Haskell on Reddit - Fri, 11/20/2015 - 6:09pm


As stated, I'd like to write a program that takes structured propositions like "[~P, P or Q]", a conclusion like "Q", and return whether the argument is valid and also provide a Fitch-style proof (, in addition to the truth-table method).

Is Haskell a good choice for this? I was also considering OCaml, not sure if the choice would be that relevant for this application. I know Python and Clojure well, but have never done anything in Haskell or OCaml.

submitted by deathofthevirgin
[link] [10 comments]
Categories: Incoming News