News aggregator

GPU Programming in Haskell

del.icio.us/haskell - Mon, 10/20/2014 - 3:22pm
Categories: Offsite Blogs

Dynamic only GHC

glasgow-user - Mon, 10/20/2014 - 1:53pm
I'm trying to build a minimal GHC 7.8.3 on Debian Wheezy with only dynamic libraries (this is for a system where disc space is scarce). I'm using this build.mk: GhcRTSWays = thr GhcLibWays = dyn HADDOCK_DOCS = NO DYNAMIC_BY_DEFAULT = YES GhcDynamic = YES Tried with and without GhcDynamic (asked on beginners how it's different to DYNAMIC_GHC_PROGRAMS but still waiting for an answer). It gets near the end of the build, then fails with: HC [stage 1] ghc/stage2/build/Main.dyn_o HC [stage 1] ghc/stage2/build/tmp/ghc-stage2 /usr/bin/ld: cannot find -lHSrts_thr-ghc7.8.3 collect2: error: ld returned 1 exit status make[1]: *** [ghc/stage2/build/tmp/ghc-stage2] Error 1 make: *** [all] Error 2 If I build with only static libraries, everything seems to work OK.
Categories: Offsite Discussion

RTA 2015 - First Call For Papers

General haskell list - Mon, 10/20/2014 - 12:08pm
================================================================== RTA 2015 - CALL FOR PAPERS 26th International Conference on REWRITING TECHNIQUES AND APPLICATIONS 29 June - 1 July, 2015, Warsaw, Poland co-located with TLCA, as part of RDP 2015 http://rdp15.mimuw.edu.pl/ ================================================================== RTA is the major forum for the presentation of research on all aspects of rewriting. Topics of interest include: * Foundations: string, term, net and graph rewriting; higher-order rewriting; binding techniques; constrained rewriting and deduction; categorical and infinitary rewriting; stochastic rewriting; higher-dimensional rewriting; tree automata; confluence; termination; complexity; modularity; equational logic; universal algebra; rewriting logic; rewriting calculi. * Algorithmic aspects and implementation: strategies; matching; unification; anti-unification; narrowing; completion; parallel execution; certific
Categories: Incoming News

Function on a Single Member of a Sum Type

Haskell on Reddit - Mon, 10/20/2014 - 11:53am

A friend of mine was going through LYAH and encountered the example,

data Shape = Circle Float Float Float | Rectangle Float Float Float Float surface :: Shape -> Float surface (Circle _ _ r) = pi * r ^ 2 surface (Rectangle x1 y1 x2 y2) = (abs $ x2 - x1) * (abs $ y2 - y1)

Then she asked me how she could write a function that worked only on Circles, e.g. circumference. My first instinct was to reach for DataKinds and to write

circumference :: Circle -> Float circumference (Circle _ _ r) = 2 * pi * r

But this throws

Data constructor ‘Circle’ comes from an un-promotable type ‘Shape’ In the type signature for ‘circumference’: circumference :: Circle -> Float

So I guess I don't understand DataKinds as well as I thought :-). My next idea was more complicated:

data ShapeType = CircleType | RectangleType data ShapeOfType (t :: ShapeType) where Circle :: Float -> Float -> Float -> Circle Rectangle :: Float -> Float -> Float -> Float -> Rectangle type Circle = ShapeOfType CircleType type Rectangle = ShapeOfType RectangleType type Shape = forall (t :: ShapeType). ShapeOfType t surface :: Shape -> Float surface (Circle _ _ r) = pi * r ^ (2 :: Int) surface (Rectangle x1 y1 x2 y2) = (abs $ x2 - x1) * (abs $ y2 - y1) circumference :: Circle -> Float circumference (Circle _ _ r) = 2 * pi * r

However, this requires extensions that I'm not comfortable introducing to a beginner. Another option would be

data Circle = Circle Float Float Float data Rectangle = Rectangle Float Float Float Float data Shape = CircleShape Circle | RectangleShape Rectangle surface :: Shape -> Float surface (CircleShape (Circle _ _ r)) = pi * r ^ 2 surface (RectangleShape (Rectangle x1 y1 x2 y2)) = (abs $ x2 - x1) * (abs $ y2 - y1) circumference :: Circle -> Float circumference (Circle _ _ r) = 2 * pi * r

But at this point I suppose you'd want to break surface into a class so that you could call it on "wrapped" and "unwrapped" Shapes.

Returning to the first example, you could do

data Shape = Circle Float Float Float | Rectangle Float Float Float Float circumference :: Shape -> Maybe Float circumference (Circle _ _ r) = Just $ 2 * pi * r circumference _ = Nothing

But this is the worst out of all.

So my question is, how would you solve this problem? Am I really overcomplicating things?

submitted by markandrus
[link] [22 comments]
Categories: Incoming News

Darcs turns 12

Haskell on Reddit - Mon, 10/20/2014 - 11:24am
Categories: Incoming News

What is your experience with making Haskell plugins?

Haskell on Reddit - Mon, 10/20/2014 - 11:05am

I spent a lot of time this past weekend trying to implement some "plugin" functionality for my project. My program processes data written in different, custom file formats, and I thought it would make sense for each format to be handled by a different plugin. Need to read a new kind of file? There's a plugin for that. Drop the plugin into the right location and you're good to go. At least that's the idea. I wasn't looking for anything fancy like supporting arbitrary languages in plugins: just plugins written in Haskell (possibly using C library and bindings) that get used by a Haskell program.

In practice, the waters are rather muddy, and it seemed like every couple of steps I took, I would get some new insight or feedback telling me I was on the wrong path. There are old blog posts, newer blog posts, allegedly "broken" libraries (plugins), arguably newer and working libraries (hlint), the capabilities of the GHC API (again, old vs new) and digging through its scarce documentation and large codebase, pre-compile vs compile the source vs interpret the source, ghc flags -static -dynamic -shared -fPIC, static lib vs shared lib, plugins written in Haskell to be used by other languages and include the GHC RTS inside, cabal flags and options, "home modules", "interface files", including dependencies or not, not being able to find dependencies, current ghci requiring .so files (I think?), interprocess comm, and probably a quite a few other issues. These were the ones I remember off the top of my head.

So after spinning my wheels, I thought I should take a breath and ask the community. What is your experience with writing plugin functionality for Haskell? What scope is feasible, and what is possible? Is it as much a science project as my recent experience suggests? Are there smarter approaches to take? Are there any active projects that successfully make use of plugins? Any insight is much appreciated!

submitted by fluffynukeit
[link] [14 comments]
Categories: Incoming News

Limit elements of a list to a certain value

haskell-cafe - Mon, 10/20/2014 - 10:02am
Hello Cafe, I have these datatypes data Event = E1 {...} | E2 {...} | E3 {...} data Parsed = PEvent Event | PLine Text | PHeader Text I'd like to split the list of Parsed values into separate lists with a guaranty that each of those lists contains only the elements of the same type, as in [PEvent E1] [PEvent E2] [PLine Text] ... How can that be achieved on type level (without creating newtypes for each case)? I tried with type families, but failed. Also, an explanation of why the Event above (or "data Q = Q1 | Q2 String") is not promotable to kind level would be welcome. best regards, vlatko
Categories: Offsite Discussion

The GHC Team: GHC Weekly News - 2014/10/20

Planet Haskell - Mon, 10/20/2014 - 8:14am

Hi *,

It's been a few weeks since the last message - and I apologize! We actually are changing the posting time to be Friday now, so hopefully this situation will be corrected preeeeetty quickly from this point forward, and hopefully will give better context over the course of a weekly discussion.

That said, let's begin!

  • We've seen plenty of changes to GHC itself in the past few weeks. Some of the highlights include:
    • Some changes to help make Prelude combinators fuse better. David Feuer has been leading a lot of this work, and it's been quite fruitful, with several new things now fusing (like takeWhile, scanl, scanr, and mapAccumL.
    • Relatedly, Data.List.Inits should be far faster thanks to David Feuer (ref: ​Phab:D329).
    • The testsuite driver now has preliminary support for Python 3 - which should be useful for platforms out there that sport it, and ones that will use it as the default eventually (such as Fedora 22, possibly).
    • Some of the initial work by Edward Yang to remove HEAP_ALLOCED from the GHC runtime system has landed. Briefly, HEAP_ALLOCED is a check the RTS uses to determine if some address is part of the dynamic heap - but the check is a bit costly. Edward's full patchset hopes to remove this with an 8% speedup or so on average.
    • GHC now has a new macro, __GLASGOW_HASKELL_PATCHLEVEL__, which will allow you to determine the point-level release of the GHC you're using. This has been a requested feature in the past we were a little hesitant of adding, but Herbert went through and did it for us. (Ref: ​Phab:D66)
    • Template Haskell now supports LINE pragmas, thanks to Eric Mertens (ref: ​Phab:D299).
    • Sergei Trofimovich revived libbfd debugging support for the runtime system linker, which should be of use to several daring souls out there (ref: ​Phab:D193).
    • Several patches from Gintautas Miliauskas has improved the usability of msys and the testsuite on Windows - and he's not done yet!
    • A few improvements to the x86 code generator were committed by Reid Barton and Herbert Valerio Riedel, improving size/space for certain cases (ref: ​Phab:D320, ​Phab:D163).

and more besides that, including some linker improvements, and general cleanups as usual.

  • The mailing list has been busy (as usual), with some discussions including:
    • Austin posted some discussion about the tentative 7.10.1 plans - we're still hoping these are accurate, so take note! We hope to freeze mid-November, and release Feburary 2015! [1]
    • Austin also called for some feedback: GHC HQ has become convinced a 7.8.4 release is needed to fix some showstoppers - so please let him know soon if you're totally incapable of using 7.8 for something! [2]
    • Alan Zimmerman has asked for some feedback on his proposed "AST Annotations", which will hopefully allow GHC API clients to add richer annotations to GHC's syntactic representations. The motivation is for refactoring tools like HaRe - and I'm sure all input would be appreciated. [3]
    • Chris done sparked off a discussion about making GHCi awesomer, and I'm sure everyone can appreciate that! In particular, Chris wanted to discuss programmatic means of controlling GHCi itself, and naturally we need to ask - is the current API not enough, and why? [4]
    • Yuras Shumovich has implemented a proposal for allowing the Haskell FFI to support C structures natively as return values - this involves interfacing with C ABI rules to properly support structure layout. While Yuras has an initial implementation in ​Phab:D252, some questions about the feature - including its implementation complexity - remain before it gets merged. [5]
    • Richard Eisenberg made a modest request: can Phabricator patches have a 'roadmap', so people can instruct reviewers how to read a diff? The answer: yes, and it should be relatively easy to implement, and Austin can do so Real Soon Now™. [6]
    • Ben Gamari started a big discussion about one-shot event semantics in the I/O manager, with a lot of replies concerning not only the bug, but machines to test the actual change on. With any luck, Ben's fix for the I/O manager and a test machine should come quickly enough. [7]
    • Herbert Valerio Riedel opened an RFC: Should we look into using AsciiDoc for GHC? Historically, GHC's documentation has been written using DocBook, a verbose but very precise and unambiguous documentation format. However, AsciiDoc offers a much nicer markup language, while retaining DocBook support. In short, it looks like GHC may get a much more clean user manual soon. [8]
    • Yuras opened another discussion: Should we namespace proposals we create on our wiki? What seems uncontroversial can lead to surprising discussion, and the results were mixed this time it seems. [9]
    • Geoff Mainland stepped up and fixed Data Parallel Haskell to work with a new version of vector and GHC. Austin had disabled DPH a few weeks prior due to its difficulty to upgrade, and divergent source trees. With 7.10, GHC will hopefully ship a more modern vector and dph to boot.
    • Austin asks: can we warn on tabs by default for GHC 7.10? It's an easy change and a minor one - but we should at least ask first. Vote now! [10]
    • Philip Hölzenspies opens up a discussion about Uniques in GHC, and their impact on the compilers current design. Philip has a hopeful design to redo Unique values in GHC, and a patch to support it: ​Phab:D323. [11]
    • Richard Eisenberg asks: can we somehow integrate GitHub into our development process? While GitHub doesn't have as many nice tools as something like Phabricator, it has a very high inertia factor, and Richard is interested in making the 'first step' as easy as possible for newbies. Discussions about Phab<->GitHub integrations were afoot, as well as general discussion about contributor needs. There were a lot of points brought up, but the conversation has slightly dried up now - but will surely be revived again. [12]

And now, look at all these tickets we closed! Including: #9658, #9094, #9356, #9604, #9680, #9689, #9670, #9345, #9695, #9639, #9296, #9377, #9184, #9684.

[1] ​http://www.haskell.org/pipermail/ghc-devs/2014-October/006518.html
[2] ​http://www.haskell.org/pipermail/ghc-devs/2014-October/006713.html
[3] ​http://www.haskell.org/pipermail/ghc-devs/2014-October/006482.html
[4] ​http://www.haskell.org/pipermail/ghc-devs/2014-October/006771.html
[5] ​http://www.haskell.org/pipermail/ghc-devs/2014-October/006616.html
[6] ​http://www.haskell.org/pipermail/ghc-devs/2014-October/006719.html
[7] ​http://www.haskell.org/pipermail/ghc-devs/2014-October/006682.html
[8] ​http://www.haskell.org/pipermail/ghc-devs/2014-October/006599.html
[9] ​http://www.haskell.org/pipermail/ghc-devs/2014-October/006730.html
[10] ​http://www.haskell.org/pipermail/ghc-devs/2014-October/006769.html
[11] ​http://www.haskell.org/pipermail/ghc-devs/2014-October/006546.html
[12] ​http://www.haskell.org/pipermail/ghc-devs/2014-October/006523.html

Categories: Offsite Blogs

This won't compile and I can't understand ghci's reasons

Haskell on Reddit - Sun, 10/19/2014 - 9:10pm

My assignment is to create two functions to delete any pair from a list of pairs that matches a given "key" (first) or "value" (second). here is my code
module DeleteFromRelation where
import BinaryRelation
deleteWithKey :: (Eq a) => a -> BinaryRelation a b -> BinaryRelation a b
deleteWithValue :: (Eq b) => b -> BinaryRelation a b -> BinaryRelation a b
deleteWithKey a pairs = [c | c <- pairs, x <- fst c, x /= a]
deleteWithValue b pairs = [c | c <- pairs, x <- snd c, x /= b]
BinaryRelation a b = [(a,b)] for reference

The errors are given for the fst c and snd c saying could not deduce (a ~ [a]) from the context (Eq b)
The function type assignment is given and can't be changed.
Any clue as to what is wrong? Thanks.

submitted by tjstanley
[link] [13 comments]
Categories: Incoming News

FP Complete: New Stackage features

Planet Haskell - Sun, 10/19/2014 - 6:00pm

We have two new updates to Stackage: providing cabal.config files and including Haddock documentation.

Haddock documentation on snapshots

Now all new exclusive snapshots will have haddock links, which you can access via the following steps:

That link will be to an index page like this from which you can view documentation of all packages included in the snapshot. This means you can generally view everything in one place, on one high availability service.

Using Stackage without changing your repo

The recommended way to use Stackage is to simply change your remote-repo field in your .cabal/config file and run cabal update. Henceforth your dependencies will be resolved from Stackage, which is backed by high availability Amazon S3 storage servers, and you will have successful build plans, compilation and passing tests. Hurrah!

Try Haskell and the upcoming Haskell.org homepage were both developed with Stackage. This meant I could just specify the Stackage snapshot to use in the README and then the next time I want to upgrade I can just update the snapshot version to get a fresh working build plan.

The issue some people are facing is that they cannot change this remote-repo field, either because they're using a cabal sandbox, which doesn't support this yet, or because they just don't want to.

The solution to this, in my experience, has been for me to manually go and run cabal freeze in a project I've already built to get the cabal.config file and then give these people that file.

Now, it's automated via a cabal.config link on snapshot pages:

For new developers working on an application who want to use Stackage, they can do something like this:

$ cabal sandbox init $ curl http://www.stackage.org/<stackage version>/cabal.config > cabal.config $ cabal install --only-dep

Which will install their dependencies from Hackage. We can't guarantee this will always work -- as Stackage snapshots sometimes will have a manual patch in the package to make it properly build with other packages, but otherwise it's as good as using Stackage as a repo.

A cabal freeze output in cabal.config will contain base and similar packages which are tied to the minor GHC version (e.g. GHC 7.8.2 vs GHC 7.8.3 have different base numbers), so if you get a cabal.config and you get a dependencies error about base, you probably need to open up the cabal.config and remove the line with the base constraint. Stackage snapshots as used as repos do not have this constraint (it will use whichever base your GHC major version uses).

Another difference is that cabal.config is more like an “inclusive” Stackage snapshot -- it includes packages not known to build together, unlike “exclusive” snapshots which only contain packages known to build and pass tests together. Ideally every package you need to use (directly or indirectly) will come from an exclusive snapshot. If not, it's recommended that you submit the package name to Stackage, and otherwise inclusive snapshots or cabal.config are the fallbacks you have at your disposal.

Categories: Offsite Blogs

Magnus Therning: Dijkstra quotes from EWD1284

Planet Haskell - Sun, 10/19/2014 - 6:00pm

I recently read through this long post entitles Object Oriented Programming is an expensive disaster which must end. I have to agree I largely agree with what he writes, but I don’t think I ever could have written such a well-researched article, and absolutely never one of equal length ;)

It does include some nice quotes and references and so far I’ve only read one of the many that I bookmarked, Computing Science: Achievements and Challenges (EWD1284). It does include a few quips that, based on other articles I’ve read, seem fairly typical to Dijkstra. I simply love the way he expressed his opinions at times.

This one really ought to have been in the lengthy post on the OOP disaster:

After more than 45 years in the field, I am still convinced that in computing, elegance is not a dispensable luxury but a quality that decides between success and failure; in this connection I gratefully quote from The Concise Oxford Dictionary a definition of “elegant”, viz. “ingeniously simple and effective”. Amen. (For those who have wondered: I don’t think object-oriented programming is a structuring paradigm that meets my standards of elegance.)

And his thoughts on formal methods are well-known of course, as are his thoughts on iterative design. However, I rather like how he expresses a certain level of disgust of the Anglo-Saxon world when writing about those topics:

The idea of a formal design discipline is often rejected on account of vague cultural/philosophical condemnations such as “stifling creativity”; this is more pronounced in the Anglo-Saxon world where a romantic vision of “the humanities” in fact idealizes technical incompetence. Another aspect of that same trait is the cult of iterative design.

It amazes me every time I read something by someone like Dijkstra, just how much things stay the same, even in a field like computing science, which is said to be moving so fast.

Categories: Offsite Blogs

When this post is ~1hr old, Hackage will be moving to a new server - with a new IP (and DNS change)

Haskell on Reddit - Sun, 10/19/2014 - 5:15pm

In 1 hour, Duncan and I will be finalizing the move of Hackage to a new server with much better hardware and performance. I wrote about this a bit a week ago.

To do this, we'll have to roll out to a new IP, which means it may take a little while for changes to propagate to you (but hopefully not very long; CloudFlare TTLs are nearly automatic it seems).

I'll put up a maintenance page once the old server goes down, so you can at least see something until the new page resolves.

In the mean time, you can use Luite's awesome mirror: http://hdiff.luite.com/

EDIT: Also follow in (un)real-time at the status site - https://status.haskell.org/

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

Neil Mitchell: HLint now spots bad unsafePerformIO

Planet Haskell - Sun, 10/19/2014 - 3:23pm

Summary: I've just released a new version of HLint that can spot an unsafePerformIO which should have NOINLINE but doesn't.

I've just released HLint v1.9.10, a tool to suggest improvements to Haskell code. I don't usually bother with release announcements of HLint, as each version just fixes a few things and adds a few hints, it's all in the changelog (plus there have now been 102 releases). The latest release attempts to make using unsafePerformIO a little bit safer. A common idiom for top-level mutable state in Haskell is:

myGlobalVar :: IORef Int
myGlobalVar = unsafePerformIO (newIORef 17)

That is, define a top-level CAF (function with no variables) and bind it to unsafePerformIO of some created mutable state. But the definition above is unsafe. GHC might decide myGlobalVar is cheap and inline it into several uses, duplicating the variable so that some functions update different versions. Running this code through the latest version of HLint we see:

Sample.hs:2:1: Error: Missing NOINLINE pragma
Found:
myGlobalVar = unsafePerformIO (newIORef 17)
Why not:
{-# NOINLINE myGlobalVar #-}
myGlobalVar = unsafePerformIO (newIORef 17)

HLint has spotted the problem, and suggested the correct fix.

Trying it for real

Let's take the package slave-thread-0.1.0 and run HLint on it. Slave thread is a new package that helps you ensure you don't end up with ghost threads or exceptions being thrown but missed - a useful package. Running HLint we see:

Sample.hs:19:1: Error: Missing NOINLINE pragma
Found:
slaves = unsafePerformIO $ Multimap.newIO
Why not:
{-# NOINLINE slaves #-}
slaves = unsafePerformIO $ Multimap.newIO

Sample.hs:20:3: Warning: Redundant $
Found:
unsafePerformIO $ Multimap.newIO
Why not:
unsafePerformIO Multimap.newIO

Sample.hs:25:1: Error: Eta reduce
Found:
fork main = forkFinally (return ()) main
Why not:
fork = forkFinally (return ())

Sample.hs:55:28: Warning: Redundant $
Found:
PartialHandler.totalizeRethrowingTo_ masterThread $ mempty
Why not:
PartialHandler.totalizeRethrowingTo_ masterThread mempty

Sample.hs:72:5: Error: Use unless
Found:
if null then return () else retry
Why not:
Control.Monad.unless null retry

HLint has managed to spot the missing NOINLINE pragma, and also a handful of tiny cleanups that might make the code a little more readable. Fortunately (and independent of HLint), the NOINLINE pragma was added in slave-thread-0.1.1, so the library no longer suffers from that bug.

Categories: Offsite Blogs

FilePath modification proposal

libraries list - Sun, 10/19/2014 - 1:35pm
Hi, As maintainer, it's kind of a grey area if I need to make proposals for the filepath library, but since I'm a relatively new active maintainer for a Core library, I thought I'd err on the side of caution. Please yell if you think these are a bad idea, otherwise I'll just do them (probably over the next few weeks). * Change 1: Add -<.> as an alias for replaceExtension with the same precedence as <.> This change has been in Shake for a while now, and seems generally useful. It isn't an operator in the lens library, and it reads nicely as a combination of - (remove something) and <.> (addExtension). The argument order of replaceExtension is a bit unfortunately, since replace functions usually have the thing to replace with first, but since extensions are at the end of the FilePaths that suggests making it the second argument (which is what filepath does). In contrast, -<.> has a very obvious argument order. * Change 2: Stop testing as part of GHC The test suite is complicated enough, since it generates
Categories: Offsite Discussion

Recommended way to install,use and maintain haskell tools on OS X

haskell-cafe - Sun, 10/19/2014 - 12:42pm
Hi I know this question might be a little old, but I happen to have a from scratch installation of OS X (yosemite) on my machine and I want to install the haskell tools in the currently best way. So I summarize the options that I understand are available: 1) A non-option first: the Homebrew formula for haskell-platform is no longer available, but… 2) There are formulas for GHC (7.8.x) and cabal, so I can install those and install the other packages with the homebrew cabal. 3) I can install the binary distribution of the Haskell Platform for OS X directly from the website, and then install any needed package with cabal. 4) I’ve heard of Nix, what is this all about? 5) Installing manually the binary distributions of ghc and cabal. No thanks. That said, what is the recommended way to manage packages once I have cabal and ghc? 1) Installing everything locally into ~/Library/Haskell, which afaik is the default behavior of cabal. That also means having ~/Library/Haskell/bin in the PATH. But do I have to a
Categories: Offsite Discussion