I'm a rising junior in college, and this summer I found out about the magic that is Haskell. I've fallen head over heels for it: with every tutorial I do I am more and more impressed with the capabilities, the performance, and the power of the language. However, wherever I look, Haskell is eschewed in favor of languages like O'Caml, F# and Scala when it comes to productive development environments. Many complain about the libraries, the steepness of the learning curve, the lack of examples and thorough documentation, and more. That said, rather than identify elements of the experience of using Haskell that are troublesome, I was wondering what kind of things I/we could try to do to make the adoption of Haskell easier for programmers from beginners to experts, from hobbyists to full-time professional coders.
submitted by myucht [link] [31 comments]
(Apologies for multiple copies of this announcement)
CALL FOR PARTICIPATION:
15th International Symposium on
Principles and Practice of Declarative Programming
Madrid, Spain, September 16-18, 2013
23rd International Symposium on
Logic-Based Program Synthesis and Transformation
Madrid, Spain, September 18-19, 2013
Registration is open now. There is a significant discount if you
register for both events.
You can access the PPDP 2013 scientific program at:
You can access the LOPSTR 2013 scientific program
Perhaps some saddening news for Markdown fans out there. As you might
remember, there was a fair amount of push for having Markdown as an
alternate syntax for Haddock.
Unfortunately, this is probably not going to happen for reasons listed
on the post I just published at .
This thread is meant to be for discussion about the post as many people,
myself included, felt that Markdown would be a nice thing to have.
I feel like I covered the topic fairly well on the post but feel free to
give suggestions or ask questions.
I would also like to remind you that if there's something that you'd
like to see in Haddock or something that you feel is broken, a good way
express this is to make a ticket on the Haddock Trac.
I will close the relevant Markdown ticket on the Trac in about 3
days, unless someone can come up with a reasonable solution that meets
the initial intent of this part of the project: a widely known markup
format that could be used as an alternate syntax for Haddock so that
I can't install tasty with cabal. Anyone with the same issue or a fix?
$ cabal install tasty
Test\Tasty\Core.hs:147:11: Not in scope: `witness'
Haskell-Cafe mailing list
Haskell-Cafe< at >haskell.org
I've just uploaded my new th-desugar package, which enables easier processing of Template Haskell source syntax by desugaring it into a much simpler core language. The meaning of the code after desugaring is identical to before desugaring, but the syntax is much simpler. To wit, th-desugar simplifies out all of the following constructs:
- guarded expressions in both functions and case statements
- "where" declarations
- do syntax
- list/monad comprehensions
- record creation / updates
- as patterns
- non-trivial patterns in a lambda expression
- multi-way if
- several more
If you are writing a library that manipulates Template Haskell syntax, you may wish to consider if th-desugar will make your job easier by forcing you to consider fewer cases. The one source Haskell construct supported by Template Haskell but not supported by th-desguar is view patterns, mostly because these interact quite non-trivially with pattern binders. It's possible this hole will be closed in a future version.
I have a bunch of BSON documents that I convert to ByteStrings, put in a
Map, and write to a socket based on the response. I noticed some high
memory usage (in the GBs) so I decided to investigate. I simplified my
problem into a small program that demonstrates clearer what is happening.
I wrote two versions, one with a Lazy Map and Lazy ByteStrings and one with
a Strict Map and Strict ByteStrings. Both share the same memory behavior
(except the lazy BS one is faster)
Here is the strict version:
And here is the lazy version:
I wrote this and compared the memory and speed behavior of ByteStrings
generated by converting it from a BSON document and ByteStrings generated
The length of the ByteString from a BSON document is 68k and the length of
the "pure" BS is 70k.
This is my weird memory behavior, both BSON and "pure" methods use the same
amount of memory after inserting 10k of them (90mb)
However when I go to lookup a value, the BSON Map
(in case you don't read /r/haskell : ))
Stephen Blackheath and I are extremely happy to report that as of today,
GHC can natively build binaries for iOS devices and the iOS Simulator.
You'll find everything you need here:
The short of it is you can use "ghc-ios myFiles.hs" to get a universal
ARMv7/ARMv7s/i386 static library to drop straight into an Xcode project.
Stephen's already working on some wonderful FRP-powered games, I'm working
on a project called SpaceTime that I'll announce shortly, and you may now
all begin creating insanely great iOS software using the finest language in
the world : ).
Stephen deserves the lion's share of the credit for this project — it's
been over 3 years in the making! Many thanks to Maxwell Swadling for
generalizing static library builds into a -staticlib flag for GHC, Carter
Schonwald for compilation guidance, and the venerable Austin Seipp for
reviewing and merging our patches.
While hacking in one of my projects, one of my modules stopped to compile
for apparently no reason. The compiler just freezes (like if it where in an
infinite loop) while trying to compile that particular module. Since I had
this problem I have been trying to reduce the problem as much as I could,
and I came out with this small piece of code:
The module I am importing comes from package vector-0.10.0.1. The compiler
I am using is ghc-7.6.3. The problem arises when compiling using the
ghc Blah.hs -O1 -fspec-constr
If I compile it verbosely (with -v), I can see that the compiler stops in
the SpecConstr optimization step. I have tried to reduce the -O1 flag to a
particular set of flags, but I didn't manage yet to find the complete set
of flags that -O1 translates to (optLevelFlags  seems to give not enough
Since this problem can be OS-dependent, my system is Debian 7 and I didn't
try yet to reproduce my problem in other systems (mainly because I don't
I am positive about the following situation, but I can't find any
concrete answer on the Web. Can anyone confirm this ?
In template-haskell-2.7.0, the following quote
[t| () |]
appears as a (ConT name), where "name" is the name for unit. However,
in template-haskell-2.8.0, the same quote appears as (TupleT 0).
Is this the expected behaviour ?
There was a lot of discussion about separating "pure" from Applicative
and putting it into a Pointed class. If I remember correctly, the main
counter argument was that 'pure' alone does not satisfy interesting
laws. There are only such laws in connection with the Applicative class.
Now, in some situations I liked to have a generalized unfoldr. I can
build this from "pure" and "sequenceA" using the State monad:
unfoldr :: (Pointed t, Traversable t) => (s -> (a, s)) -> s -> t a
unfoldr = evalState . sequenceA . pure . state
One could state a law like:
traverse f (pure a) == traverse id (pure (f a))
Would this justify to move "pure" into a new Pointed class?
Thanks to John Lato and Duncan Coutts for the latest bugfix release! The latest packages should be buildable on GHC 7.6, and the cairo package should behave a bit nicer in ghci on Windows. Thanks to all!