News aggregator

Shaking up GHC

Haskell on Reddit - Sat, 10/11/2014 - 11:09pm
Categories: Incoming News

Discussion: Add safeWithFile function

libraries list - Sat, 10/11/2014 - 10:10pm
Some care is required to use withFile properly with lazy IO, and people sometimes get it wrong. In some cases, readFile is a suitable replacement. In other cases, however, it may be necessary to ensure the file gets closed in a timely manner, and it may not be necessary to read the whole file. The following seems to do the trick: safeWithFile :: (NFData a) => String -> IOMode -> (Handle -> IO a) -> IO a safeWithFile name mode f = withFile name mode $ f >=> (return $!!) Sample use: *SafeWithFile> safeWithFile "SafeWithFile.hs" ReadMode hGetContents >>= putStr module SafeWithFile (safeWithFile) where import Control.DeepSeq import System.IO import Control.Monad safeWithFile :: (NFData a) => String -> IOMode -> (Handle -> IO a) -> IO a safeWithFile name mode f = withFile name mode $ f >=> (return $!!) _______________________________________________ Libraries mailing list Libraries< at >
Categories: Offsite Discussion

Send me everything you know about using haskell as a POSIX shell, or implementing GNU type things in haskell. (Please)

Haskell on Reddit - Sat, 10/11/2014 - 5:59pm

So far I think I am probably going to use the shell called Hell, as a base to code with. I am also probably going to re-write GNU as I need it except in a haskell way.

submitted by read_harder
[link] [20 comments]
Categories: Incoming News

Pretty Printing Libraries with an Emphasis onConsistency

haskell-cafe - Sat, 10/11/2014 - 10:52am
Hi all, It seems that all of the pretty printing libraries on Hackage at the moment have an emphasis on being compact, but not necessarily consistent. By consistent, I mean that similar blocks of code are indented in the same fashion, even when not strictly necessary. Take for example, the start of "Pretty Printing with Lazy Dequeues". Here, the example is: if True then if True then True else True else if False then False else False I call this inconsistent, because the two sides of the top-level if have been formatted under different rules. A consistent formatting of this would be: if True then if True then True else True else if False then False else False The above can obviously be reached if you *always* format `if` in this style, but that's not what I'm after. If it's possible to format both sides on one-line, then that should be preferred. So an equally desirable output (that meets my "consistency" requirement) is
Categories: Offsite Discussion

Optimizing isSuffixOf (was Re: Proposal: Make a very slight change to the semantics of Data.List.isSuffixOf)

libraries list - Sat, 10/11/2014 - 10:13am
On Fri, Oct 10, 2014 at 4:18 PM, Jon Fairbairn <jon.fairbairn< at >> wrote: Is it only about wordiness & syntax? With the original a `isSuffixOf` b = reverse a `isPrefixOf` reverse b and with Jon's a `isSuffixOf` b = a `elem` tails b I'm completely convinced of the correctness, modulo that of the referenced functions. Moreover, the conviction was obtained cheaply. My finite neurons are saved for the greater task at hand. The proposal on the table snatches away that providence. I have to take it on the authority of others that it's correct. Rust recently exposed a bug in their string matching function. It's their version of Data.List.isInfixOf. See These days I point all my colleagues and friends to this article as a classic case of premature optimization. But I understand that some folks prefer their computations always rapid, if sometimes wrong. David, is there an application underlying the need for isSuffixOf speed? You might
Categories: Offsite Discussion

Why Do Monads Matter? - YouTube - Sat, 10/11/2014 - 5:37am
Categories: Offsite Blogs

Skills Matter - Sat, 10/11/2014 - 5:22am
Categories: Offsite Blogs - Sat, 10/11/2014 - 4:00am
Categories: Offsite Blogs

Lee Pike: Using GHC HEAD

Planet Haskell - Fri, 10/10/2014 - 10:23pm

I wanted to try out a recent feature in GHC this week, so I was using HEAD. When I say using, I mean it: I wasn’t developing with it, but using it to build Ivory, our safe C EDSL, as well as some libraries written in Ivory. I want to point out a few dragons that lay ahead for others using HEAD ( today.

  • The Functor, Applicative, Monad hierarchy (as well as the Alternative and MonadPlus hierarchy) is no longer a warning but an error. You’ll be adding a lot of instances to library code.
  • You’ll need to update Cabal, which comes as a submodule with the GHC sources. Unfortunately, building Cabal was a pain because of the bootstrapping problem. The script in cabal-install is broken (e.g., outdated dependency versions). Getting it to work involved using runhaskell directly, modifying a bunch of Cabal’s dependencies, and getting a little help from Iavor Diatchki.
  • Some of the datatypes in Template Haskell have changed; notably, the datatypes for creating class constraints have been folded into the datatype for constructing types (constraint kinds!). Many libraries that depend on Template Haskell breaks as a result.
  • I won’t mention the issues with package dependency upper bounds. Oops, I just did.

Fortunately, once Cabal is updated, Cabal sandboxes work just fine. I wrote a simple shell script to swap out my sandboxes to switch between GHC versions. (It would be a nice feature if Cabal recognized you are using a different version of GHC than the one the cabal sandbox was originally made and created a new sandbox automatically.)

Because I’m on OSX and use Homebrew, I tried using it to manage my GHC versions, including those installed with Brew and those built and installed manually. It works great. When building GHC, configure it to install into your Cellar, or wherever you have Brew install packages. So I ran

> ./configure --prefix=/usr/local/Cellar/ghc/7.9

which makes Brew aware of the new version of GHC, despite being manually installed. After it’s installed,

> brew switch ghc 7.9

takes care of updating all your symbolic links. No more making “my-ghc-7.9″ symbolic links or writing custom shell scripts.

Categories: Offsite Blogs

happstack-lite - Fri, 10/10/2014 - 8:25pm
Categories: Offsite Blogs - Fri, 10/10/2014 - 8:18pm
Categories: Offsite Blogs

[OS X] Quick Question on Leskah Setup

Haskell on Reddit - Fri, 10/10/2014 - 7:00pm

The first time Leskah is launched, it presents a dialog box wherein the user can specify the "[p]aths under which Haskell sources for packages may be found":

Which path(s) should a user using Haskell Platform 2014.2.0.0 on OS X select?

edit: Apologies, s/Leskah/Leksah/g

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

cabal sandbox using absolute path on symlinked dir

haskell-cafe - Fri, 10/10/2014 - 3:14pm
Hello Cafe, On Ubuntu, after creating a sandboxed project in a symlinked directory, cabal.sandbox.config contains absolute (canonical) paths of the directory, and not the symlinked paths. Is this a bug, and is there a way to correct that behavior? There is no way to move the project to a different place without recreating the whole sandbox. Best regards, vlatko
Categories: Offsite Discussion

Chaining a map over lists with lenses

haskell-cafe - Fri, 10/10/2014 - 2:51pm
Hi! I’m sure the answer to this question is under my eyes but I can’t understand it only from the docs. Suppose a data type like this: data Type1 = Type1 { _myField :: [Type2] } makeLenses ‘’Type1 data Type2 = Type2 { _otherField :: String } Then with t^.myField I get access to the [Type2] list. Now, i would like to go through each element of the list, apply the otherField lens to each element, and get the list of the results. Of course this means: map (view otherField) (t^.myField) but I’m sure there’s some combinator to do the same thing by chaining lenses/prisms/traversals/whatever, right? E.g. something like t^.myField.something.otherField I’m still trying to understand the full picture about lenses, but afaik what I need is a prism, because a list is a sum type, right? Thank you for your help, Nicola
Categories: Offsite Discussion

Mathematics of Program Construction (MPC 2015): firstcall for papers

General haskell list - Fri, 10/10/2014 - 1:59pm
Apologies for multiple copies. FIRST CALL FOR PAPERS 12th International Conference on Mathematics of Program Construction (MPC 2015) Königswinter, Germany, 29 June - 1 July 2015 BACKGROUND The MPC conferences aim to promote the development of mathematical principles and techniques that are demonstrably practical and effective in the process of constructing computer programs, broadly interpreted. The 2015 MPC conference will be held in Königswinter, Germany, from 29th June to 1st July 2015. The previous conferences were held in Twente, The Netherlands (1989), Oxford, UK (1992), Kloster Irsee, Germany (1995), Marstrand, Sweden (1998), Ponte de Lima, Portugal (2000), Dagstuhl, Germany (2002), Stirling, UK (2004, colocated with AMAST), Kuressaare, Estonia (2006, colocated with AMAST), Marseille, France (2008), Québec City, Canada (2010, colocated with AMAST), and Madrid, Spain (2012). TOPICS Papers are solicited on mathematical methods and tools put to use
Categories: Incoming News

Skills Matter - Fri, 10/10/2014 - 12:55pm
Categories: Offsite Blogs