News aggregator

Haskell practice -- Plotting library

haskell-cafe - Tue, 03/25/2014 - 4:58am
Hi, I've been playing with Haskell for a while. In order to improve my Haskell skills and also due to the lack of an intuitive plotting library, I decided to write a simplified plotting interface for the haskell-chart library. Any comments or suggestions would be very welcome! Kai _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >
Categories: Offsite Discussion

Yesod Web Framework: Package consolidation

Planet Haskell - Tue, 03/25/2014 - 2:07am

A few weeks ago, there was a pretty heated debate about the PVP on the libraries mailing list. I've seen a few different outcomes from that discussion. One is to reduce dependency footprints to try and avoid some of the dependency problems. (Another one is concrete proposals for changes to the PVP; I intend to post a proposal as well in the coming days, but wanted to get the easier stuff out of the way first.)

This blog post is about some plans I have for consolidating multiple packages together, hopefully to result in simpler dependency trees without causing users to have unneeded package dependencies- at least not too often. The reason I'm writing up this blog post is to let the community know about these changes in advance, and let me know if any of these changes will cause them problems. Also, if I list a package as deprecated, and you'd like to take over maintainership, please let me know.

One of the guiding principles I've used in setting this up is that I belive some dependencies should be considered incredibly cheap. Depending on process, for example, is a cheap dependency, since it comes with GHC. (Unless you place restrictive bounds on process, which can instead cause dependency problems.) For more information on these principles, please read my description.

I'll start at the bottom of the dependency tree and build up.

streaming-commons, zlib-bindings, text-stream-decode, conduit and pipes

Currently, there are about six core conduit packages: conduit, zlib-conduit, attoparsec-conduit, etc. In addition, for some of these packages, I've split off helper packages providing functionality to be used by other streaming data libraries as well, such as zlib-bindings and text-stream-decode.

I want to collapse that into just three packages. All of the streaming helpers will end up in a new package, streaming-commons. I've talked with Gabriel Gonzalez about this, and we'll be collaborating together on creating a high-quality, low-dependency library. This library will also include some features currently baked into conduit itself, like lock-free Windows file reading and directory traversals.

All of the conduit core packages on top of that would then be merged into a new package, conduit-extra. So we'd end up with conduit, conduit-extra, and streaming-commons. The only downside is that, if you only needed zlib support, you'll now get a few extra packages as well. However, following the principle I listed above, these extra dependencies should all be coming from the "basically free" dependency category.

Crazier ideas for streaming-commons

This may be taking the idea too far, but we could include some even more advanced tooling in streaming-commons. This could include not only the data types from xml-types and json-types- which provide both streaming and tree based data structures for those data formats- but also attoparsec parsers and blaze-builder renderers. This could allow quite a bit of the xml-conduit codebase to be shared by the pipes world, for example.

I'm curious if people think this is a cool idea, or too radical (or both!).

Deprecate failure, attempt, and safe-failure

This one's been on my list for a while, pending some details being worked out with Edward Kmett. The goal is to completely deprecate failure and attempt in favor of the exceptions package, and within exceptions split out MonadThrow from MonadCatch.

This will also mean removing some redundant functionality from resourcet. It will be nice to be rid of the custom MonadThrow and MonadUnsafeIO defined there.


A few simple moves: merge http-client-multipart into http-client, and merge http-client-conduit into http-conduit. The latter change will mean that it's a bit more difficult to use http-client in conduit without depending on tls, but that's a use case anyone has expressed interest to me in.

Another change I'm planning to do at the same time is to add a new module to http-conduit, with an alternate API. There are a few places where I'm dissatisfied with the current API, and this module will work as an experimental next-gen http-conduit. I'm planning on keeping both versions of the API around for quite a while for backwards compatibility, however. The changes I'm looking at are:

  • Avoiding ResumableSource
  • Using with-semantics (like http-client) to avoid accidentally keeping connections open.
  • Don't bake in the need for ResourceT
  • Possibly use lenses for field modifiers on the Request data type.

This change is pretty simple: collapse shakespeare, shakespeare-css, shakespeare-js, shakespeare-text, shakespeare-i18n, and hamlet into a single package. It made sense to keep these separate when APIs were changing rapidly, but things are basically stable now.


Since they don't add any extra dependencies, I'd like to merge wai-test and wai-eventsource into wai-extra. Once again, since we're dealing with stable APIs, this shouldn't cause too much trouble.

I'm also considering deprecating wai-handler-devel, since it's no longer used at all by yesod devel.

Deprecate pool-conduit

pool-conduit used to be a resource pool implementation based on code in conduit. Since then:

  • The actual resource pool implementation is provided by resource-pool.
  • The code I used from conduit has moved to resourcet.

At this point, pool-conduit doesn't really have much in it. If there's code that people are using from it, I'd like to get it merged into resource-pool itself.


The next iteration of Yesod will have a significantly simpler dispatch system. This new code doesn't really make sense as a general-purpose routing tool, so I'm planning on moving that code into yesod-core itself and deprecate yesod-routes. I know there are other users of yesod-routes; I think it makes sense to rename yesod-routes to do something like merging yesod-routes into wai-routes, as yesod-routes has no Yesod-specifics in it.

Another minor change: merge yesod-eventsource into yesod-core. No extra dep, and a stable API.

Finally, the big (and somewhat controversial) one: merge most of the yesod-* core packages into the yesod package itself. A number of year ago, we did precisely the opposite. However, given API stability, I think the time has come to simplify our dependency list again here. This will have the added benefit that when a user reports "I'm using Yesod version 1.2.3", it will give us more information.


I'm planning on deprecating dtd, uri-conduit, and xml-catalog, as I don't use them any more and have no time to maintain them.

Another idea I'm playing with is merging html-conduit into xml-conduit. This would add a tagstream-conduit dependency. Alternatively, perhaps tagstream-conduit could be merged into xml-conduit as well.


Merge classy-prelude-conduit in with classy-prelude. Downside: classy-prelude will depend on conduit-combinators, but that doesn't actually add more than 3 extra packages.

Next step: trimming dependencies in general

I'm not planning on rushing any of these changes. The goal is to take them slowly and methodically, and release changes incrementally. For example, after the conduit changes are done, I'd release new versions of wai, yesod, etc, that are compatible with both the new and old versions. Hopefully the user facing changes will simply be tweaking import lists and cabal files, but users will be able to take their time on this.

Ultimately, I'm planning on releasing new version of persistent (2.0) and Yesod (1.4). You can see the Persistent 2.0 goals. The Yesod 1.4 release doesn't actually have any breaking changes planned, aside from upgrading its dependencies.

One other thing I'm going to be doing in this process is a more general trimming down of dependencies. I'll be going through yesod-platform to find packages we don't need. I also want to avoid redundant packages if possible (e.g., we only need one cryptographic hash packages). In many cases, as a community, we have multiple package options available. I think a great move for the community would be to start consolidating those options as well where it makes sense. If I have concrete ideas on that, I'll certainly share them.

Categories: Offsite Blogs

New release of Haskelm: Shared code/types between Haskell servers and Elm clients

Haskell on Reddit - Tue, 03/25/2014 - 12:08am

I've released a new version of Haskelm, a library which translates from Haskell to Elm. This lets you seamlessly share both datatypes and function definitions between your server-side Haskell program and your Elm clients.

The package and docs are here:

The code is on Github:

New features include:

  • Updated version scheme (middle digits correspond to Elm version)
  • Updated to output code that compiles with 0.12
  • Interface vastly simplified
  • ToJson and FromJson Elm functions which are generated use the same format as Data.Aeson.TH
  • Fixed Hackage/Haddock docs

The interface is quite simple now, you can just do:

elmSource = $(translateToElm defaultOptions "path/to/myFile.hs")

and elmSource will be a String variable with the contents of your Elm code.

Similarly, if you run the command "haskelm" and pipe in a Haskell source file it will translate it.

I'm definitely open to comments, criticisms and pull requests, so feel free to give me feedback!

If you haven't heard of Elm, it's a pure, functional language centered around Functional Reactive Programming, which compiles to Javascript. You can find out more about it at

submitted by jmite
[link] [comment]
Categories: Incoming News

HaL-9 - Call for Contributions

haskell-cafe - Mon, 03/24/2014 - 11:00pm
HaL ist ein lokaler Haskell-Workshop mit überregionaler Bedeutung, der nun bereits das 9. Mal stattfindet. Dieses Jahr laden wir für den 20. Juni ins Institut für Informatik an der Martin-Luther-Universität Halle-Wittenberg ein. Wir suchen Beiträge zu Haskell im Besonderen und der funktionalen Programmierung im Allgemeinen, aber auch Anknüpfungen an andere Programmierparadigmen. Dabei interessieren wir uns unter anderem für die Themenbereiche * Neues von Sprache, Bibliotheken, Werkzeugen, * Anwendungen von Kunst bis Industrie, * Lehre und Forschung an Schulen und Hochschulen. Die Beiträge können präsentiert werden als * Tutorium (etwa 90 min) * Vortrag (etwa 30 min) * Demonstration, künstlerische Aufführung Die Veranstaltungssprache ist Deutsch, nach Absprache auch Englisch. Presentations will be given in German but we can switch to English if requested. Bitte reichen Sie Kurzfassungen der Beiträge ein (max. 3 Seiten), die dem Programmkomitee eine Ein
Categories: Offsite Discussion

Brendan Eich, CEO of mozilla

Lambda the Ultimate - Mon, 03/24/2014 - 5:34pm

Correct me if I'm wrong, but I think this is the first case of a language designer making it to the top slot of a company!

Categories: Offsite Discussion

Question (beginner): Is Haskell type system as strong as claimed?

Haskell on Reddit - Mon, 03/24/2014 - 4:36pm

As a new enthusiastic Haskell learner (a new Reddit subscriber too, BTW), it was a little disappointing to me that the following code compiles without error (GHC 7.6.3), but fails at runtime:

data Shape = Rect Int Int | Circle Int Rect x y = Rect 33 22 -- pattern matches, OK Circle z = Rect 11 24 -- pattern mismatch, obviously main = do putStrLn ("the value of x is: " ++ show x ++ ", the value of y is: " ++ show y) putStrLn ("the value of z is: " ++ show z)

The first output line is something like:

the value of x is: 33, the value of y is: 22

But a runtime error is thrown for the second ("Irrefutable pattern failed for pattern Main.Circle z".

So isn't this type mismatch an easy one to catch at compilation time? I know that both Circle and Rect in my example are 2 value constructors for the same type, though I still think that such error could be caught by compiler. Am I missing something here?

submitted by johnkirollos
[link] [71 comments]
Categories: Incoming News

I want to use Haskell for my first real world software project, but I don't know if I can.

Haskell on Reddit - Mon, 03/24/2014 - 4:31pm

I'm finally starting to venture outside the scope of my class assignments and want to start writing the software I always wanted to make. I've always been highly fascinated with Haskell ever since I heard about it and now that I'm taking a fantastic class based on SICP and Scheme, I'm falling in love with functional programming in a big way and see that Haskell is really starting to become a serious contender in the functional programming space with all the great libraries and tools along with the really solid design of the language itself.

One of the most important criteria for choosing a language is to be able to easily deploy the software on Linux, Mac and Windows.

Does Haskell have great cross-platform support? That also goes for all the major libraries that make Haskell so brilliant: haddock, the testing one, autoparsec, etc ..

submitted by jollybobbyroger
[link] [8 comments]
Categories: Incoming News

Cabal robustness

haskell-cafe - Mon, 03/24/2014 - 3:40pm
I have seen the dreaded "ExitFailure 1" many times when a package fails to install (under Linux or Windows), and I wonder why something more helpful cannot be printed? Sometimes one gets a variant of this where the message is "this system is not compatible with this package," but the user must study the foo.cabal file to determine what is missing. Also, it seems that the only way to determine if a package will install under Windows is to try and hope for the best (often getting "ExitFailure 1" if it fails). Wouldn't it make more sense to tag packages with the OS and other dependencies and fail with a helpful message like "Windows not supported" if appropriate? It appears that some packages (like lens-4.1) have version dependencies that cannot be satisfied (at least not on my Linux and Windows boxes), so it appears that the Hackage hosting process suffers from a variant of the well-known "dll hell" problem. I tried the new (Cabal 1.18.0) sandbox feature but this did not help in my case. Any comments on th
Categories: Offsite Discussion

Malicious link in docs for 6 years, 6 months, 6 days

Haskell on Reddit - Mon, 03/24/2014 - 1:13pm

The change in question. This appears to be user Unmarshal's only edit. Following the link eventually lands you on a page offering a convenient flash player update (called MediaPlayerClassic.exe).

Someone with privileges (apparently you have to email nominolo), please point that link here instead. It would also be a good idea to look for occurrences of the sftank domain elsewhere in the documentation. I'm surprised it escaped notice this long. Evidently automatic account creation was possible before, so I assume this was from that period.

I might have picked an inauspicious time to find it, though; according to WolframAlpha, 9/18/2007 was 6 years, 6 months, and 6 days ago. Unmarshal would probably be thrilled by the coincidence.

submitted by jnwatkins
[link] [6 comments]
Categories: Incoming News

Help with Eratosthenes Sieve

Haskell on Reddit - Mon, 03/24/2014 - 10:41am

Hey guys,

I'm new to Haskell and I'm trying to implement some simple algorithms so I get the hang of the language. I tried implementing the Eratosthenes Sieve algorithm for generating prime numbers.

It works, but it's really slow. Could anyone give me any tips on how to improve it?

eratosthenesSieve :: Int -> Integer eratosthenesSieve n = sieveHelp [2 .. floor . sqrt $ fromIntegral] [2..n] where sieveHelp [] acc = acc sieveHelp (x:xs) acc = sieveHelp xs (removeMults x acc) removeMults i lst = filter (\x -> notElem x [i*i, i*i + i .. n]) lst

Edit: fixed parameters when calling sieveHelp

submitted by flamingsushi
[link] [6 comments]
Categories: Incoming News

Philip Wadler: How nasty can you get? Grayling's ban on prisoners receiving books

Planet Haskell - Mon, 03/24/2014 - 10:18am
Chris Grayling has banned sending of books to prisoners, a counter-productive act if ever there was one. It is hard to think of a nastier act from a government responsible for numerous nasties, from the bedroom tax to cutting legal aid. Thank goodness the Scottish justice system is devolved!

Yet another reason to vote for independence. Who would want to be part of a country that could do such a thing?

Spotted via Boing Boing.
Categories: Offsite Blogs

Mateusz Kowalczyk: New Haddock released! A visual guide to changes.

Planet Haskell - Mon, 03/24/2014 - 9:33am
Posted on March 24, 2014 by Fūzetsu

We’ve just uploaded Haddock 2.14.1 and while you can view the CHANGES file, here I’ll attempt to present all new features added since A quick note that while 2.14.0 is in the CHANGES file, it was never officially released to the public. Consider it an internal release if you will. This basically covers 2.14.0 and 2.14.1. I am posting this now as I hear GHC 7.8.1 is supposed to come out in a few hours and this is the version that you’ll be getting. I had only just realised this but this integrates the changes I have made over the last GSoC into a stable GHC release. FYI, I’m using GHC 7.8-rc2 for any code snippets presented here. Last thing to mention is that any ticket numbers you see here are the tickets as seen on Haddock Trac. We’re actually planning to move everything to GitHub soon so keep that in mind if you’re reading this further in the future. Note that pretty much everything here is described in Haddock documentation (although without nice examples) so please refer to that if you need further information.

Let’s begin!

  • Print entities with missing documentation (#258)

    This adds a --print-missing-docs flag to Haddock. Given a file like this:

    module Foo where f :: () f = () -- | Doc for 'g' g :: () g = () class FooClass a where

    we can ask Haddock to tell us which docs are missing:

    $ haddock Foo.hs -h -o /tmp --print-missing-docs Haddock coverage: 25% ( 1 / 4) in 'Foo' Missing documentation for: Module header f (Foo.hs:3) FooClass (Foo.hs:10)

    There has been a suggestion to make this flag default. I’m personally not against it. What do you think?

  • Print a warning message when given -optghc instead of --optghc (#5)

    This is just a quick fix to a long-standing feature request. The problem was that -optghc actually means --odir=ptghc which is probably not what you wanted. We now warn when we see -optghc in the flags. The warning is:

    Warning: `-optghc' means `-o ptghc', did you mean `--optghc'?

  • Add --compatible-interface-versions (#231)

    This simply prints the versions of the .haddock interface files that your Haddock binary knows how to work with.

    $ haddock --compatible-interface-versions 25

    We had some fairly big changes to the interface file so current Haddock can only work with a single version: this means it can’t re-use .haddock files that your previous versions might have generated.

  • Allow to generate latex documentation for FFI declarations (#247)

    Fairly self-explanatory. Note that I don’t encourage actually trying to use the LaTeX back-end, it is not maintained and has many bugs. It is meant to serve a sole purpose of generating the Haskell Report when that time comes. If you are interested in using this back-end and are willing to put in some time to breathe some life into it, we’d love to have you, contact us!

  • Add copyright and license information to generated documentation

    We let you document modules with a comment containing some special fields. The header is documented here. Consider the following module:

    {-| Module : W Description : Short description Copyright : (c) Some Guy, 2013 Someone Else, 2014 License : GPL-3 Maintainer : Stability : experimental Portability : POSIX Here is a longer description of this module, containing some commentary with @some markup@. -} module W where

    Here’s how it renders using 2.13.2:

    Old module info box

    and here is how it renders with 2.14.1:

    New module info box

    As you can see, perhaps copyright holders could be presented better. Perhaps in the next release each author will be on its own line, see ticket #279.

  • Improved Unicode support

    Unicode support previously was very finicky. We now have a new parser which can handle unicode much better. Here’s an example comment with a single definition list:

    -- | [灼眼のシャナ] ℕ ℤ ℚ f :: () f = ()

    Here’s how 2.13.2 renders it:

    Old unicode rendering

    and here’s how 2.14.1 renders it:

    New unicode rendering

    Much better! Notice a character missing in the old rendering.

  • Bold markup support

    I have covered this one in the past so here’s only a brief mention. Double underscores are used to denote that something is bald.

    -- | This is bold: __Hello world. Underscores_are_allowed__ f :: () f = ()

    Bold support

    Note that just like with other such markup (emphasis), we do not allow the user to stretch it over multiple lines.

    -- | This is not bold: __Hello world. -- Underscores_are_allowed__ f :: () f = ()

    No multiline support

    This is by design. We feel that extra complexity of implementation and the fact that it changes how 2.13.2 behaved does not warrant such support. See ticket #126 for minor discussion.

  • Nested paragraphs

    This is a pretty big addition and if you are the type of person that tries to format their comments so that they look nice in source, you’ll probably need to pay attention. Basically, we allow something like what Markdown allows: nesting things under list elements (such as more list elements and so on). A simple example would be nesting some a code snippet and another list under some other list. I’m actually showing off two features here. Consider

    {-| * This is some list @ This is code @ * Another list * Second element of inner list, not separated by line break. -} f :: () f = ()

    2.13.2 makes a mess out of it:

    Old nested lists

    but 2.14.1 does what you might expect:

    New nested lists

    The rule is that everything to be nested under a list element is to be indented 4 spaces from the start of the comment. Note that this is not 4 spaces relative from start of the previous list. You also have to make sure that the nested paragraph is separated by a line break so that Haddock doesn’t simply think it’s the continuation of the list.

    A double nesting will therefore look like this:

    {-| * Top level * First nested * Second nested -} f :: () f = ()

    Twice nested

    Those with sharp eyes will notice that I have two list elements not broken up by the line break in the initial example. This in now allowed as long as the list elements are of the same type:

    This is now fine:

    -- | -- * foo -- * bar

    but this is not fine:

    -- | -- * foo -- 1. bar

    Haddock will think it’s just a single list element and it will look something like this:

    Different type no break

    Please refer to list section of the docs for details. These changes mean that you can write much nicer docs but they also mean that if you wrote something that wasn’t exactly model Haddock before, it might now look radically different! I know that even GHC is guilty of this.

  • Better escaping

    We now have much better escaping behaviour. Consider

    -- | < http:/ loves \>\>= >

    2.13.2 messes up:

    Old link escape

    But 2.14.1 works as we’d like it to:

    New link escape

    It is actually impossible to have the > character in the link or alt text even with HTML escapes because we don’t accept markup there so it won’t get converted.

    If you don’t need the alt text, we now even automatically try to convert text to links. Consider

    -- | is cool f :: () f = ()

    2.13.2 doesn’t do what we want at all and even swallows up the forward slashes because it thinks it sees (empty) emphasis:

    Old autolink

    2.14.1 does something much more reasonable:

    New autolink

    You should notice that escaping things is much more reasonable now.

  • Header markup

    Headers in regular comments (rather than just for sections) are now allowed. The syntax is multiple = characters, from 0 up to 6. Each back-end decides how to render the different header levels itself.

    {-| = Top level * Hello * World == Subheader === Subsubheader @More stuff!@ -} f :: () f = ()


    Note that headers have to be at the beginning of a paragraph but we do allow a paragraph to follow without a line break right after it. This allows you to write down things like lists and another header straight after.

  • Parser should no longer fail to parse any markup

    We now aim to be able to parse everything. This means that you should never see a parse failure caused by bad Haddock syntax. For example

    -- | [ hello f :: () f = ()

    fails on 2.13.2 with a parse error: doc comment parse failed: [ hello. This will render as you’d expect on 2.14.1:

    No parse error

    This means that if you had a documentation that failed to parse due to such error before, it will now (silently) succeed.

    Important: please note that you can still have a different kind of parse error. If your comment is at a place where we don’t expect it, that’s an error. For example, the following will throw a parse error:

    data F = F () -- ^ Doc for first () () -- ^ Doc for second ()

    gives us W.hs:18:12: parse error on input ‘(’ because we don’t support documentation of each parameter to the constructors.

    Please do not report these as bugs! If you do get a doc comment parse failed then report that, you should not be seeing any of these anymore.

  • {-# OPTIONS_HADDOCK show-extensions #-} pragma will show the GHC extensions enabled in the module.

    I think this is a pretty nifty one. Consider

    {-# LANGUAGE UnicodeSyntax #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE FlexibleInstances #-} {-# OPTIONS_HADDOCK show-extensions #-} module W where

    You can now ask Haddock to list all enabled extensions (even those implicit ones) with the Haddock pragma that I show above. This particular example renders like this:

    Ext pragma

    If you have a Haskell98/2010/whatever pragma too, that will also get shown. Any extension implied by the current language (H98,2010) is not shown.

    I decided to show all the extensions, including the ones pulled in by stronger ones to discourage enabling the most powerful extensions without a good reason.

    This option is not a default. Do you think it should be?

  • Properly render License field (#271)

    There was a bug where we rendered the wrong thing in the License field. I can’t show you because it already has been patched up. I simply mention this for completeness.

  • Print type/data family instances (for exported types only)

    Fairly self explanatory, your type/data family instances now get shown in the documentation.

    This example is a pretty big one because there’s a fair amount of stuff going into it. This is actually a stripped down version used by Haddock for testing.

    {-# LANGUAGE TypeFamilies, UndecidableInstances, PolyKinds, TypeOperators, DataKinds, MultiParamTypeClasses, GADTs #-} module W where -- | Doc for: data X data X = X -- ^ Doc for: X | XX -- ^ Doc for: XX | XXX -- ^ Doc for: XXX -- | Doc for: data Y data Y -- | Doc for: class Test a class Test a -- | Doc for: instance Test X instance Test X -- | Doc for: instance Test Y instance Test Y -- | Doc for: type family Foo a type family Foo a :: k -- | Doc for: type instance Foo X = Y type instance Foo X = Y -- | Doc for: type instance Foo Y = X type instance Foo Y = X -- | Doc for: class Assoc a class Assoc a where -- | Doc for: data AssocD a data AssocD a :: * -- | Doc for: type AssocT a type AssocT a :: * -- | Doc for: instance Assoc X instance Assoc X where -- | Doc for: data AssocD X = AssocX data AssocD X = AssocX -- ^ Doc for: AssocX -- | Doc for: type AssocT X = Foo X type AssocT X = Foo X -- | Doc for: instance Assoc Y instance Assoc Y where -- | Doc for: data AssocD Y = AssocY data AssocD Y = AssocY -- ^ Doc for: AssocY

    and here’s part of how it looks

    Type families

  • Fix display of poly-kinded type operators (#189)

    Old poly-kinded rendering

    New poly-kinded rendering

    We’re still unsure how to display this to the user but at least now it’s not completely wrong. Suggestions are most welcome, please comment on #189.

  • PatternSynonyms support

    GHC 7.8 now has support for pattern synonyms. Here’s an example right from Haddock test-suite.

    {-# LANGUAGE PatternSynonyms, PolyKinds, TypeOperators #-} -- | Testing some pattern synonyms module W where -- | FooType doc data FooType x = FooCtor x -- | Pattern synonym for 'Foo' x pattern Foo x = FooCtor x -- | Pattern synonym for 'Bar' x pattern Bar x = FooCtor (Foo x) -- | Pattern synonym for (':<->') pattern x :<-> y = (Foo x, Bar y) -- | Doc for ('><') data (a :: *) >< b = Empty -- | Pattern for 'Empty' pattern E = Empty

    The rendering is still pretty experimental so suggestion welcome!

    Pattern Synonyms

  • Fix display of implicit parameters (#260)

    {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ImplicitParams #-} module W where data Configuration c :: String -> ((?configuration :: Configuration) => IO b) -> IO b c = undefined

    Broken implicit params rendering

    Fixed implicit params rendering

  • Fix rendering of Contents when links are present (#276)


    module W where -- * Section header with 'f' link -- | f doc f :: () f = ()

    We used to have a problem where a link in the header would break the Contents box rendering.

    Old contents

    That is now fixed. Note that you can no longer click on ‘f’ in the Contents box to be taken there. I feel that it’s the expected way.

    New contents

  • Fix documentation duplication on record fields (#195)

    I think this is going to be a pretty controversial one. Consider

    module W where data F = FOne { field :: () -- ^ Doc for FOne field } | FTwo { field :: () -- ^ Doc for FTwo field }

    As ‘field’ is actually the same function, in the past Haddock would join the comments (it’s in the weird order due to an unfixed bug):

    Old record doc rendering

    We now instead take the doc of the first field to occur. Note that is used even if the first field has no comment and others do.

    New record doc rendering

    See ticket #195 if you want to discuss this change. Both behaviours are weird but I think no one intentionally used the old behaviour.

  • Add --source-entity-line for exact line links (eg. things defined inside TH splices) (#79)

    This allows HsColour to insert anchors for TH declarations. Nothing to show here, check the ticket for details.

  • Display fixity information for names with nonstandard fixities

    There’s no a mechanism in place to display fixity of (type) operators and infix functions. Includes exotic things like type families and pattern synonyms. Code omitted but there’s nothing special you have to do, your new docs should automagically have fixities shown.

    Fixity rendering

  • Bird tracks specified like “> code” no longer suffer from an extra leading space in the code output

    Pretty self explanatory. We strip a leading space from code blocks generated by bird tracks.

    -- | -- > hello -- > world f :: () f = ()

    Old bird tracks

    New bird tracks

    This is also planned for the ‘@’ style code blocks which should have this implemented in the next Haddock release, most likely 2.15.0 coming out with GHC 7.8.2.

  • Render * and -> with their UnicodeSyntax equivalents if -U is enabled

    Replaces * and -> in extra places compared to 2.13.2.

    Old unicode syntax

    New unicode syntax

  • Display minimal complete definitions for type classes

    I feel this is a nice feature. GHC now supports MINIMAL pragmas and we are now able to display it in the docs. Another example right out of the Haddock test-suite:

    module W ( Foo(..) , Weird(..) , NoMins(..) , FullMin(..) , PartialMin(ccc) , EmptyMin(..) ) where class Foo a where -- | Any two of these are required... foo, bar, bat :: a -- | .. or just this fooBarBat :: (a,a,a) {-# MINIMAL (foo, bar) | (bar, bat) | (foo, bat) | fooBarBat #-} class Weird a where a,b,c,d,e,f,g :: a {-# MINIMAL ((a, b), c | (d | (e, (f | g)))) #-} class NoMins a where x,y,z :: a -- | Has a default implementation! z = x class FullMin a where aaa,bbb :: a class PartialMin a where ccc,ddd :: a class EmptyMin a where eee,fff :: a eee = fff fff = undefined

    Minimal pragma

    Again I ask you to ignore the silly ordering of some grouped functions, this is the aforementioned old bug. Hopefully we can fix it by the next release.

  • Hide right hand side of TF instances with hidden names on the RHS

    Changes a bit which TF RHSs are hidden. It is a change between 2.14.0 and 2.14.1 and is only mentioned for completeness.

This is it for all the changes I can think of but I’m sure I missed something! There was some other minor stuff fixed up that doesn’t deserve a mention on its own (such as fixing bullet point rendering in constructor docs, #281) so I encourage you to read the commit history if you need to know all the little details.

While I’d love to end it here, I do have to admit that there’s a regression in this release which we don’t get to fix until GHC 7.8.2.

Namely, if you have a (very common) comment like this:

-- | -- @ -- some code -- goes here -- @ f :: () f = ()

2.13.2 will render it like this:

Old codeblock rendering

and 2.14.1 like this:

New codeblock rendering

The problem is that while Haskellers are used to putting a space after the comment marker --, that space is actually a part of a comment and we end up with an extra ‘empty’ line which actually has a single space in front of it. This is the line with the closing @ on it.

All of the following let you workaround the problem:

-- | -- > some code -- > goes here f :: () f = () -- | --@ --some code --goes here --@ g :: () g = () {-| @ some code goes here @ -} i :: () i = ()

Surprisingly, that second form is allowed. If you care a lot about the extra line, please use a workaround for now and I’m sorry! If you don’t care that it looks a bit on the ugly side for a while, we’ll have a fix in the next release, most likely to ship with GHC 7.8.2.


Categories: Offsite Blogs

[JOB] Summer internships at Jane Street

General haskell list - Mon, 03/24/2014 - 8:33am
Jane Street is looking to hire functional programmers for our offices in New York, London and Hong Kong. Right now we're especially looking for interns for this upcoming summer. Interning at Jane Street is a challenging and varied experience. Here are some of the projects our interns have completed. - Developing an FRP-style toolkit for building sophisticated text-mode UIs - Rewriting and generalizing our RPC messaging library using session types - Prototyping optimizations to the OCaml compiler - Working on the internals of Async, our monadic concurrency library Many of our intern projects make their way out as open-source projects. Interns also learn about Jane Street's trading business through lectures and more interactive training sessions. Plus, there are a lot of fun social activities throughtout the summer. If you're interested in an internship, or know someone who might be, applications can be submitted here. And as usual, we're also hiring developers for f
Categories: Incoming News