http://lpaste.net/133514 (I accidentally wrote FlexibleContexts in the lpaste title instead of FlexibleInstances).
Works just fine using ghc-7.8. Fails with No instance for (FromJSON Bar) using ghc-7.10.
I don't know why it works in either of them, since I didn't explicitly turn on OverlappingInstances.
But check this out. If we swap the let binding for a monadic binding
... for some reason this works just fine in ghc 7.10. Something sketchy is going on here.submitted by drb226
[link] [8 comments]
Let’s say you need to force (evaluate) a lazy Haskell list.
A long time ago, this was a common way to fight lazy I/O: you read a String and then force it. These days you can have normal I/O with strict Text or ByteString instead.
Anyway, let’s say you do need to force a list. This came up in a pull request for lexer-applicative. Another scenario is if you want to evaluate a lazy Text or ByteString without copying the chunks. Or, you know, for any other reason.
First of all, how exactly do you want to force it? There are two primary ways: force the spine or force the elements too. (You can’t force the elements without forcing the spine.)
Forcing the spine means forcing all cons cells without touching the elements. One way to do that is to evaluate the length of the list, but that feels ad-hoc because it computes the result that is not needed. Here’s an elegant way to walk the spine:forceSpine :: [a] -> () forceSpine = foldr (const id) ()
(Obviously, you need to force the resulting () value, by calling evaluate or seq-ing it to something else, for any evaluation to take place.)
const id, also known as flip const, returns its second argument while ignoring the first. So the evaluation goes like this:forceSpine [x1, x2] = foldr (const id) () [x1, x2] = (const id) x1 $ foldr (const id) () [x2] = foldr (const id) () [x2] = (const id) x2 $ foldr (const id) ()  = foldr (const id) ()  = ()
See how forceSpine “unpacks” the list (thus forcing the spine) and throws all elements away.
I mentioned that you may also want to force the elements of the list, too. Most of the time you want to deep-force them, and so you should just rnf the whole list. Even when the elements are atomic (like Char or Int), evaluating them to weak head normal form is still equivalent to rnf.
But occasionally you do want to shallow-force the elements. In that case, simply replace const id with seq in the definition of forceSpine to obtain forceElements:forceElements :: [a] -> () forceElements = foldr seq ()
Again, looking at the evaluation chain helps to understand what’s going on:forceElements [x1, x2] = foldr seq () [x1, x2] = seq x1 $ foldr seq () [x2] = foldr seq () [x2] = seq x2 $ foldr seq ()  = foldr seq ()  = ()
Same as before, only elements get forced before being thrown away.
And here’s a table that may help you understand better the difference between seq, forceSpine, forceElements and rnf:list `seq` () forceSpine forceElements rnf [Just True] () () () () [Just undefined] () () () undefined [undefined] () () undefined undefined True : undefined () undefined undefined undefined undefined undefined undefined undefined undefined
Since forceSpine and forceElements are based on foldr, they can be trivially generalized to any Foldable container, with the caveat that you should understand how the container and its Foldable instance work. For example, forceSpine is useless for Data.Map.Map, since it is already spine-strict, and forceElements for a tuple will only force its second element.
Reading through various tutorials online (LYAH, CIS194, etc) I'd like to be able to fire up a REPL and play along, but it seems like the REPL plays by different rules. Just trying to define a simple function in the REPL, I go to SO and see responses such as "It's because ghci executes in the IO monad, so you need to use let to bind non-IO values." Huh? I don't know what a monad is yet, I'm just trying to figure out pattern matching!
Am I the only newbie who is puzzled by this? By constrast, the REPL for other languages I've used, including Ruby, Python, Clojure, and JS, seem super easy to use and ready-to-go. Is the Haskell REPL mainly a power users tool among community members or something?submitted by thecity2
[link] [59 comments]
TL;DR: I made some GHC binaries for linux that rely on musl instead of glibc for easier static linking. Scroll down for the link.
As most of you know, musl is a linux only C standard library that is optimized for static linking. Statically linked binaries can simplify distribution and deployment. If you have tried to statically link a program with glibc, you will probably know that this does not always work as expected: for example, in many cases the resulting binary will require to be executed in a system that has the exact same version of glibc as the one that was used to compiled it. In essence, static binaries linked with glibc are oftentimes less portable than dynamic ones.
I decided to see if I could use GHC with musl. The problem was that while I could find some references online, I could not find a precompiled version of GHC that uses musl. So I decided to try and a build one myself. I was able to successfully bootstrap GHC under musl and I am posting it today in case someone else finds it useful:
I posting this on google drive, I have no better place to host this, hopefully google will not disable my account :-) This is a fully bootstrapped (i.e. stage 2) GHC and not a cross compiler. So this will not work in a typical glibc based linux distribution. You need a complete musl based environment to use it. Also, the binaries produced by this GHC will all depend on musl and not work on most glibc based distros. On the other hand, statically compiled binaries should be very portable and will not depend on any particular C standard library. I have done some minimal testing and it seems to work rather well; everything I tried to compile from hackage just worked. Additionally it can compile GHC itself which is always a good test. The size of the resulting static binaries is acceptable. In my 64 bit system, a simple hello world has the following sizes (stripped): 800K glibc dynanic, 1648K glibc static, and 1012K musl static.
Why not use a cross-compiler? I have found that in practice it is easier to have a separete environment for producing static binaries. A cross-compiler requires that you also cross-compile all the C libraries that you use. Additionally, cabal has still problems with cross-compiling and will not work out of the box.
Note that musl is not 100% compatible with glibc, so some things might work slightly differently.
If you do not like using a GHC precompiled by someone else, you can use my binaries to compile GHC under musl yourself; it would be easier than cross-compiling GHC from scratch.
EDIT: I posted some notes on github. There you can also find binaries for a (mostly working) port of GHC to uClibc.submitted by redneb8888
[link] [15 comments]
PhD Studentship in the area of applying type theory and systems design to formalize the execution model heterogeneous computing. Within the group we already have a intermediate language for SIMT execution models with a compiler and tools being developed in Haskell and formalized in Agda and it is hoped that the successful applicate would continue to work in this area.
Please feel free to contact me for more information.submitted by cuberoo
[link] [3 comments]
Hello, I have a project where I want to have servers that are easily reproducible. That is, many copies of the same structure that can communicate between themselves and also offer the same services. As Haskell is the language I'm more familiar with, it would be nice to be able to do it with it, but that brings questions:
Are there frameworks that are more mature than others? I really need them to be robust. Same question for servers.
The fact that they are Haskell based make them more difficult to install/build in other servers? Using Stackage would be a good step? What would optimize the reproducibility of the system?
Thank you!submitted by guaraqe
[link] [5 comments]
Graydon Hoare is the original developer of Rust even before Mozilla adopted it. For the 1.0 release he prepared a lightning talk on how the language changed over 10 years.
He only published some bullet points, but the topic list is interesting as well.
- Six ways Rust is fundamentally different from how it started
- Six ways Rust is fundamentally the same as how it started
- Six things we lost along the way
- Six things we gained along the way
- Six things I'm irrationally, disproportionately pleased by
Read the full blog post for the content of the five lists.
Similar to -fdefer-type-errors, it would sometimes be convenient to defer scope errors, for the same reasons: making a breaking change and then testing bits and pieces of it, rather than having to try and fix everything all at once before getting past the compilation phase.
Along the same vein, -fdefer-template-haskell-errors? -fdefer-all-the-things?
Has this been proposed yet?submitted by drb226
[link] [9 comments]