Re: build fail with latest 8.1 sources

John Leo writes: > I just pulled again and picked up a more recent patch by Ben Gamari: > https://github.com/ghc/ghc/commit/ca1b986074757efff755c33c7f9a62c7eae43c7f > > This seems to have fixed the problem. The commit says 8 hours ago but for > some reason I didn't pick it up

OpenSearch with GHC manual

Hi, Search engines often reference old versions of the GHC user guide. For instance with Google and the request "ghc unboxed tuples" I get the manual for 7.0.3, 5.04.1 and 6.8.2 as first results. With DuckDuckGo I get 6.12.3 and then "latest" versions of the manual. So I have made a custom

Re: Windows build broken -- again

Simon Peyton Jones via ghc-devs writes: > Sigh. The Simon PJ Windows Buildbot reports > Yes, my apologies for this one. I'm currently in the process of getting this one fixed in D2700. Unfortunately my own Windows machine is having hardware issues so I progress has been a

Re: GHC pretty printer philosophy

Richard Thanks for the support. The major change in HsSyn since the pretty printer was first written is that the parser now preserves parens in the original source, which it did not used to, so this approach is now feasible. And I am starting to bump into tests failing which require updating

Re: data families syntax

Answering my own question, which means I did not do enough research before asking. I found two points that I missed earlier: 1) data families are open in contrast to value level functions i.e. you can add more instances later on hence the family and instance keywords make sense. 2) the syntax

data families syntax

I am curious about why the data families syntax was chosen to be the way it is. For example a list can be defined as follows: data family List a data instance List Char = Empty | Cons Char (List Char) data instance List () = Count Int Instead why not define it as: data List :: * -> * data