I don't recall ever being excited about a compiler release before, but this has got me excited. Typed holes, overloaded lists, pattern synonyms, new IO manager, new code generator, interruptible FFI calls, parallel compilation, and tons of other new features.
One thing I'm particularly excited about is the switch to use the system's dynamic linker instead of a custom one in GHCi. The custom linker GHCi used before didn't support some features used by C++ code, which meant that some of my FFI-based projects weren't usable in GHCi. This also affected other things that used a GHCi-like code path like Template Haskell and the GHC APIs used by ghc-mod/hdevtools. This will be huge for usability for me when working on projects that link to C++.
Hat tip to all the GHC developers for a truly amazing release!
The dynamic switch isn't without its pain points. In particular, the way we currently implement it leaves some things to be desired, and it's lead to some other rather unfortunate ramifications for Windows right now.
Truthfully, me and Simon now have reservations about if this is the right way to go, and we should instead invest more infrastructure into our own Linker (which, independently, got some nice bug fixes this time around - constructors and weak pointers now work, for example.) ELF support is quite complete (and very stable) for example. It's just a question of what's the most work.
This extension allows programmers to use the list notation for construction of structures like: Set, Map, IntMap, Vector, Text and Array. The following code listing gives a few examples:
I think OverloadedStrings makes things more ambiguous. It's a power-feature, to be sure, but it also makes the use of Text and ByteString much more available in much the same way that numeric literals do (literally the same way, actually).
I think that sort of ambiguity is part of Haskell. It rescinds a bit on the HM promise of never having to write types, but Haskell has long rescinded on that in spirit and practice. It leads to a bit of beginner trouble, but, again, not any more than numeric literals do.
I welcome overloaded lists because I feel it'll make more libraries willing to expose Set-typed interfaces when that's the honest contract that should be upheld by the interface. That's what I want my types to tell me—not just what's syntactically convenient.
I somewhat agree on the last point. The temptation is often too great to use those horrible, horrible O(n^2) set functions (nub, difference, intersection) from Data.List just because of the immediate availability.
It just makes programs ambigious when reading. The amount of typing you save is the amount of type information the reader loses. It's okay if there's just one instance of IsString you're actually using, but if you're using few of them in the same module it turns out to not be satisfactory for my tastes.
When you use OverloadedStrings in conjunction with Data.ByteString.Char8 it becomes OverloadedStrings' issue as well. Compile-time transformations are not supposed to break your program.
Ahh, very good. Then perhaps our target of inquiry ought to be the IsString class. Ought it have some laws we can expect instances to follow, akin to the Monad laws? At the moment, we can write:
That's true. Similarly, I expect that for types with weird Eq or Ord instances overloaded lists might give strange results. That said, those issues still exist when someone types
A reasonable objection, but I don't see that it applies to OverloadedLists either directly or by analogy (though I could totally be missing something).
I've been playing around with the new PatternSynonyms extension. In combination with the existing ViewPatterns extension, I'm going to really have to change the way I think about API design. This is actually pretty fantastic.
{-# LANGUAGE ViewPatterns, PatternSynonyms #-}
import Data.Set as S
-- patterns that a library might provide
pattern x :< m <- (minView -> Just (x, m))
pattern m :> x <- (maxView -> Just (x, m))
pattern Null <- (S.null -> True)
-- a really dumb test function using those patterns
doubleMin :: (Ord a, Num a) => Set a -> Set a
doubleMin (x :< s) = insert (2 * x) s
doubleMin x = x
Ignore how dumb my test function is, and just focus on how lightweight it becomes to match views of the data structure. Figuring out what patterns to include my libraries is going to be a fun new design point.
I haven't had a look at the extension definition itself, but I find this really hard to read. Can you or someone else give an explanation of what's going on? It seems to me that the brackets are all wrong, I would've expected
pattern (x :< m <- minView) -> Just (x,m)
but that's just basically view patterns/pattern guards. Basically I can sort of see what's going on here, but only in this specific case; I can't see how one uses this elsewhere.
There are a couple terrible examples. Bidirectional pattern synonyms must be valid as both expressions and pattern matches, or you get a compile error
My example was using unidirectional pattern synonyms. They allow any pattern match whatsoever as the body; the expression restriction is dropped because they aren't allowed to be used in expression contexts. They are defined using <- instead of =.
pattern MinView x m <- (minView -> Just (x, m))
That's functionally the same as the :< example above, but possibly a bit simpler to read, because the precedence of the symbols is more obvious. It defines a pattern synonym named MinView that is translated to the view pattern in parens.
It's quite possible you were conflating view pattern syntax with pattern guard syntax as the source of your confusion.
I was reading the paper and got stuck somewhere when I saw this:
> With Mio, realistic HTTP servers in Haskell scale to 20 CPU cores, achieving peak performance up to factor of 6.5x compared to the same servers using previous versions of GHC. The latency of Haskell servers is also improved: <snip> under a moderate load, reduces expected response time by 5.7x when compared with previous versions of GHC
I really want to get into Haskell, but I just don't understand it. The tutorial on the official site doesn't do it for me. Can anyone suggest alternative resources for learning? I'm used to C-like languages.
Thanks for all the responses. I'll start with LYAH.
If anybody is learning Haskell and needs help, please email me.
Edit: I agree with nnq, I think LYAH moves too slowly and fails to show you what about Haskell is truly different and worthwhile in a compact enough format. That said, it is great as a reference as the explanations of concepts are stand-alone. (unlike RWH which is more project-oriented)
Edit2: You are going to feel a bit lost after Haskell Fast & Hard. This is natural. That's why I have you do the NICTA course. It firms things up.
Edit3: I think RWH is a great reference as well, but the mid-to-late chapters have a bit of an "in media res" thing going on because there are projects being walked through cross-chapter. That said, it has a very nice and simple example of, "pre-monads, ugly code; post-monads, pretty code". RWH also covers topics that you'll care about if you're doing Haskell in production.
I sincerely recommend against LYAH! It takes sooooooooo loooooong to get to the interesting bits that actually make Haskell worth learning an has so many try-to-be-funny examples that it makes you run away screaming... I tried going through it but it was literally oscillating between putting my mind to sleep and making wish to grab a chainsaw :) And the "humor" and "pretty pictures" don't help either... they were more like poignant guide to ruby, something that you either love or they annoy the hel out of you (this was for me), but either way they don't help the learning experience at all.
I suggest HFH ("Haskell Fast & Hard") as the introductory tutorial to start with instead. You can pick from 2 formats:
I accidentally upvoted you, but I disagree. LYAH is a great book to actually read through, and I enjoyed the humor. real world haskell introduces things without explaining and it's quite confusing and inconsistent.
Others have linked tutorials. I'm going to leave some advice: pretend like you're learning to program from scratch. Not just mentally but in how you invest. It will likely take some amount of time, it will likely happen in stages of progressively receding complete astonishment and confusion, and you will be served to be proud of silly things like getting simple programs to even compile.
Sounds kind of miserable, right?
That's why you should also prepare for it with some of that early curiosity and wonder that drove us all to learn programming to begin with.
Haskell is probably unlike anything you've used before.
This is most certainly the best advice you can give to someone coming from other languages. I constantly see people I very much respect for their skills in other programming disciplines get very angry and make otherwise irrational rants about Haskell because they can't translate their hard won skills over to this new model. Learning Haskell will make one feel like a beginner again, should just embrace that from the start.
When I learn something, I would like to simultaneously read several books on the same topic, so that I could learn same things from different perspective. It works great for me when I learn Haskell, Scala, and other things.
Here is the list of materials I used to learn Haskell:
One thing to keep in mind: Haskell is different enough that it's almost as hard as learning to program the first time.
To learn something that hard, you need to be exposed to it multiple times. You'll probably get overwhelmed even with LYAH, but give it some time and come back to it.
Learn You a Haskell for Great Good! has already been recommended, which I would have said if it had not yet been.
There is also Real World Haskell [0]. It's a lot less long winded than LYaH, which is good or bad depending on how you like to digest information.
Also, check out FP Complete's FP Haskell Center [1]. It contains community written tutorials with inline runnable code examples, so you can really get a feel for Haskell by manipulating and playing with the examples right on the site.
All questions have solutions you can learn from; most have multiple solutions. I have learned a lot from doing these problems and doing additional research where needed.
(This is in addition to the other good learning resources like the oft mentioned LYAH.)
I tried getting into haskell probably 3 times before it really stuck with me. After getting over the initial hump it's heavenly. I started with LYAH like others have recommended. Persistence!
I've found the "24 Days of Hackage" series incredibly useful - each day is a brief introduction to a useful Haskell library, many of which show off features of Haskell that aren't available in 'standard' languages. Even better, each one comes with working example source on GitHub, so you've got a starting point if you do want to experiment.
(I'm a Haskell beginner, currently experimenting with using Scotty, Persistent and Esqueleto to make a web API - and these articles have been so useful to me - I'm finally getting my head around monad transformers, using them to extend the standard Scotty one. Proud moment for me.)
No one's mentioned the wikibook. I've not read through it much, but a colleague found it far more readable than LYAH: http://en.wikibooks.org/wiki/Haskell (I loved LYAH myself, though, so YMWillProbablyV).
Also, there's no substitute for talking to people. Hop on the Haskell Beginners mailing list (http://www.haskell.org/mailman/listinfo/beginners) or drop by the IRC channel (#haskell on freenode), where people couldn't be friendlier.
Miran Lipovaca's LYAH is one of the best intro to programming, not just intro to Haskell, books I've read. He's great at explaining complicated technical concepts clearly.
I can recommend reading SICP first if you know nothing about functional programming. It will likely help a lot.
And forget everything you know from C-like languages (I'm not joking).
To me, the core of Haskell is that: "Haskell is C with one semi-colon per function."
This forces you to put all your code into method signatures. This, in turn, means Haskell (or C, if you follow the 1 semicolon rule in C) can understand almost everything about your program.
If you actually follow the 1 semicolon rule in C, you'll get very verbose syntax. All of Haskell's syntax is in service of making programming in this style palatable.
Yes. Everything but certain naive use of template Haskell or use of ghci is supported for targeting IOS. There's also some related engineering to provide android support
I'm also intrigued. How would one program for iOS in a practical sense with Haskell? A great deal of iOS programming, as I understand it, is navigating the APIs and libraries provided by the SDK... is this a simple task in Haskell? The FFI is something I haven't really dealt with much yet. I guess people could/will start writing wrapper libraries?
Haskell has one of the best FFIs I've ever seen; calling C code from Haskell is quite trivial, and you can write all of the necessary wrapper code and objects (such as automatic memory management or object destruction) in Haskell using common wrappers.
I'd also highly recommend c2hs for writing new wrapper libraries.
It's not that easy. I mean, just sending a message could entail one of objc_msgSend, obj_msgSend_stret or objc_msgSend_fpret, and which one you want to use is not always as clear-cut as you might prefer (http://www.sealiesoftware.com/blog/archive/2008/10/30/objc_e...). And then there's the hassle of defining classes dynamically, which entails six function calls just to create a class with one empty method, and one of those essential functions is not actually provided for you AFAIK unless you're using Apple's compiler where it's a builtin, so you'll need to write it yourself.
It's not ridiculously hard, but it's somewhat less easy than normal C FFI.
The other hard part about it is that Haskell's FFI doesn't support variadic functions in a friendly way, which makes argument passing that much trickier.
If you just need to call variadic functions with a specific parameter list determined at compile time, that's easy with the existing FFI; just write a prototype for the function for any given set of arguments you want to call it with. (For instance, you can have an FFI binding printf_int_float :: CString -> CInt -> CFloat -> IO CInt .)
If you really need to construct calls at runtime and you don't know the argument list at compile time, there's a Haskell binding to libffi. However, you generally only need that if you're writing a language interpreter or similar.
There is a similar problem with objc_msgSend in C: Methods with certain argument types can't be called with a normal objc_msgSend(). Instead, you need to create a specifically typed function pointer and assign objc_msgSend to it. I think a similar solution would be necessary with Haskell.
I'd appreciate seeing a link to an example of this. I put a decent amount of work (a few years ago) into writing some bindings in Haskell to the objc runtime, but ended up shelving it until I could come up with a satisfactory solution to the variadic function dilemma.
Doesn't calling C code interact poorly with green threading? (I assume that handlers that make it act slightly sanely exist, but I imagine the cost of setting up native threads for FFI is rather high.)
I think the idea is that you would use the standard tools for the edges of the program with a Haskell core underneath handling the thinky bits. (I have no experience at all doing this, but it seems like the natural use case.)
While this is nice, it results in a big static lib(27M) to include in your app. This might be okey for some games, but maybe not for small apps. I was very interested in a Haskell app, but eventually gave up because of this...
the twitter app is 30M, we have already past the point of sensible app sizes.
edit: fb messenger is 60M, a ghc-ios app with the elm compiler baked in is 24M.
Yes - you can now compile Haskell code to run on iOS. There are still a few unusual steps that involve ffi but its pretty easy to get a trivial project up and running. I have an unfinished project that shows the process.
https://github.com/schell/blocks
I know enough about Haskell to be excited, but recently, I implemented a few systems with F# and am really happy with the language. If we forget about the .net/MS thing (and all the hatred that comes from that), are there real true advantages of going Haskell for a greenfield project over F# ? (I have a couple heavy algorithm heavy Haskell projects done, but having worked with F# more and more, I feel like it is so much nicer as a modern, not bend over your back to deal with the purity/lazy aspects language than Haskell).
Even better, if you use vector library, prefetch instructions are automatically (and nearly optimally) inserted for your loops written in higher-order functions like fold.
Nope. That's not in the release version. Simd is still second class in ghc. Should be viable for ghc 7.10 though. Note well, the prefetches in that paper aren't optimal. In many cases prefetch is over issued.
You should only use prefetch when benchmarks show that the hardware prefetch isn't performing up to sniff. Or when your access pattern for data doesn't have good locality and doesn't resemble a linear arithmetic sequence. (Just rules of thumbs mind you. For more precise heuristics, please read your CPU vendors optimization manual. The intel manual has quite a few tricks that should apply to most modern CPUs overall)
Now I'm kind of curious. The GHC is listed there as being 113 megabytes. When I try to install it on Arch Linux, the size is listed as 736MB! What in God's name is Arch doing to nearly septuple the size of this package— and more to the point, does anyone know any way of getting it to not do that? I'd very much like to learn Haskell, but taking up that much space on my laptop's SSD is a dealbreaker.
That's because they're measuring the tarball, which is a worthless metric anyway (for example, we just switched to supporting .tar.xz, which reduced the size of Linux binary distributions close to 50% for a ~65MB total. But that doesn't tell you anything about what's inside.)
The unpacked binary distribution is closer to 1GB, which sounds about right. I speculate Arch Linux is doing a regular build with nothing special.
If 1GB is undoable for your laptop (which I find odd, as someone even on a 100GB device), then that's unfortunate. You're best to wait for some other build with things removed or to just build it yourself (for example, no dynamic linking).
You can shoot me an email (davidleothomas@gmail.com) or hit me on irc (davidthomas on freenode - I typically lurk in #haskell and #snowdrift, amongst other places). I don't want to get hopes up too high - sufficiently little isn't going to be much in the short term.
Luite is probably going to announce something like that in a few days. Ghcjs getting ready for general release was blocked by ghc 7.8.1 not being released.
They are packaged for Ubuntu, technically (12.04 Precise) but you can just add the apt-repository line to your `sources.list` and it will work fine, and plenty of people are doing this.
A repository for the STABLE branch will eventually appear on http://deb.haskell.org, but I'm not sure when Joachim will do this.
GHC 7.8 is already packaged in Debian experimental, so if you're running current testing, you may find it easiest to just add sources for experimental and sid, set the default release to testing (so you don't upgrade anything else), and then install GHC 7.8 directly. You'll end up upgrading a pile of Haskell packages to versions from experimental, but mostly not the rest of your system.
The binary distributions install alongside your system packages or other bindists quite nicely (they might overwrite the /usr/bin/ghc symlink, but that's it) and you can select which ghc version you want to use when using cabal with the `-w` flag. Each will keep a separate package db, etc. So be bold!
One thing I'm particularly excited about is the switch to use the system's dynamic linker instead of a custom one in GHCi. The custom linker GHCi used before didn't support some features used by C++ code, which meant that some of my FFI-based projects weren't usable in GHCi. This also affected other things that used a GHCi-like code path like Template Haskell and the GHC APIs used by ghc-mod/hdevtools. This will be huge for usability for me when working on projects that link to C++.
Hat tip to all the GHC developers for a truly amazing release!