- ghc-devs - Haskell.org

API Annotations D538 call for review
by Alan & Kim Zimmerman 16 Dec '14

16 Dec '14

Hi All https://phabricator.haskell.org/D538 is now ready for review/merge. It contains a number of small changes based on actually using the API annotations in ghc-exactprint [1] which is now able to perfectly reproduce the original source using only the ParsedSource AST and API annotations. [1] https://github.com/alanz/ghc-exactprint/tree/wip Regards Alan

1 0

Customizing Phab
by Jan Stolarek 16 Dec '14

16 Dec '14

After working with Phab for a while I realize I'd like to customize layout of a revision. When I work with a revision I most often read comments and source code and write my replies (often based on comments). The problem is that comments are located at the top of a page whereas the text field for writing a reply is located at the bottom. I wonder if there is a way to: a) collapse "Revision Update History", "Local Commits", "Table of Contents" and "Open Revisions Affecting These Files"? b) or move them below "Leap Into Action" section ? I can't find any such settings so I suppose that's not possible by default. Is there any way to extend Phab's functionality do allow customizing layout in a way described above? Janek

3 3

FW: [GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages
by Simon Peyton Jones 16 Dec '14

16 Dec '14

Devs I wish there was a way to convert Trac identities to people's name and email addresses. (For committers there is, https://ghc.haskell.org/trac/ghc/wiki/TeamGHC, but no one else.) As Eric says, I think most people would be happy to do that. I like addressing real people. And syncing up with separate email conversations is also a challenge. Simon -----Original Message----- From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf Of GHC Sent: 16 December 2014 10:46 Cc: ghc-tickets(a)haskell.org Subject: Re: [GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+---------------------------------- -------------------------------------+--- Reporter: nh2 | Owner: gridaphobe Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.2 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: | Related Tickets: None/Unknown | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+---------------------------------- -------------------------------------+--- Comment (by gridaphobe): simonpj: This is Eric Seidel (eric at seidel.io). I've told trac my name and email, but it doesn't seem to expose them to others! I'd be happy to tick a "make my name+email public" box if there's one I'm missing somewhere. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9049#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ ghc-tickets mailing list ghc-tickets(a)haskell.org http://www.haskell.org/mailman/listinfo/ghc-tickets

1 0

Are empty statement lists allowed in recursive do? Possible bug
by Alan & Kim Zimmerman 16 Dec '14

16 Dec '14

I am trying to work out empirically whether empty statement lists are allowed in a stmtlist, and one of the points these are used in Parser.y is for recursive do. If I try to load the following ---------------- {-# LANGUAGE RecursiveDo #-} bar :: IO () bar = do rec {} return () ----------------------- into GHCI, I get a "Prelude.head: empty list" panic. I think this is related to `rnRecStmtsAndThen` If I try --------------------- bar :: IO () bar = do do {} return () ----------------------- I get a warning about empty do statements not being allowed. Hence the question as to wether recursive do should be allowed to have an empty statement list. I am trying to manage the API annotations for semicolons in statement lists, and the current way it is being parsed makes this difficult, I would prefer to simplify it to something like how import decls are parsed, which can also have multiple semicolons in between. Alan

1 0

Last call for 7.8.4
by Austin Seipp 15 Dec '14

15 Dec '14

Hello *, I've just pushed a final round of patches to the 7.8 branch, including the notorious Cabal fix for the -fPIC bug that was discussed earlier in the week, and a handful of other bugfixes for ARM among other things (/cc Joachim :) I am planning on making the final 7.8.4 release this week; barring any pending minor issues (e.g. build wibbles) in the tree (which I do not think should be needed), the only thing I will commit is A) release notes and B) the version number changes. There will not likely be a 7.8.4-rc2, so this is a last call for any bugs you'd like to see fixed. I may have missed something -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

3 3

RE: [Diffusion] [Build Failed] rGHC3f87866ad536: Fix dll-split problem with patch 'Make Core Lint check for locally-bound…
by Simon Peyton Jones 15 Dec '14

15 Dec '14

This failure is in STM!! I don't think that can be my fault :-( | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 15 December 2014 17:28 | To: Simon Peyton Jones | Subject: [Diffusion] [Build Failed] rGHC3f87866ad536: Fix dll-split | problem with patch 'Make Core Lint check for locally-bound… | | Harbormaster failed to build B2627: rGHC3f87866ad536: Fix dll-split | problem with patch 'Make Core Lint check for locally-bound…! | | USERS | simonpj (Author) | GHC - Core/System FC (Auditor) | GHC - Driver (Auditor) | GHC - Type checker/inferencer (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHC3f87866ad536 | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Core/System FC, GHC - Driver, GHC - Type | checker/inferencer

2 2

Re: [commit: ghc] master: Improve documentation of syntax for promoted lists (a972bdd)
by Gabor Greif 15 Dec '14

15 Dec '14

Hmm, shouldn't that be -XDataKinds (instead of -XTypeOperators)? also: umambiguous ---> unambiguous becuase ---> because Cheers, Gabor On 12/15/14, git(a)git.haskell.org <git(a)git.haskell.org> wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : > http://ghc.haskell.org/trac/ghc/changeset/a972bddfc8115d80d774383a55202a293… > >>--------------------------------------------------------------- > > commit a972bddfc8115d80d774383a55202a293dc68595 > Author: Simon Peyton Jones <simonpj(a)microsoft.com> > Date: Mon Dec 15 17:08:29 2014 +0000 > > Improve documentation of syntax for promoted lists > > THe documentation in 7.9.4 of promoted list and tuple types was > misleading, which led to Trac #9882. This patch makes explicit > that only type-level with two or more elements can have the > quote omitted. > > >>--------------------------------------------------------------- > > a972bddfc8115d80d774383a55202a293dc68595 > compiler/parser/Parser.y | 8 ++++++-- > docs/users_guide/glasgow_exts.xml | 19 ++++++++++++++++--- > 2 files changed, 22 insertions(+), 5 deletions(-) > > diff --git a/compiler/parser/Parser.y b/compiler/parser/Parser.y > index bffe6e1..235d34a 100644 > --- a/compiler/parser/Parser.y > +++ b/compiler/parser/Parser.y > @@ -1483,6 +1483,10 @@ atype :: { LHsType RdrName } > [mo $2,mc $4] } > | SIMPLEQUOTE var { sLL $1 $> $ HsTyVar $ > unLoc $2 } > > + -- Two or more [ty, ty, ty] must be a promoted list type, just as > + -- if you had written '[ty, ty, ty] > + -- (One means a list type, zero means the list type constructor, > + -- so you have to quote those.) > | '[' ctype ',' comma_types1 ']' {% ams (sLL $1 $> $ > HsExplicitListTy > placeHolderKind ($2 : > $4)) > [mo $1, mj AnnComma $3,mc > $5] } > @@ -1503,11 +1507,11 @@ inst_types1 :: { [LHsType RdrName] } > | inst_type ',' inst_types1 {% addAnnotation (gl $1) AnnComma > (gl $2) > >> return ($1 : $3) } > > -comma_types0 :: { [LHsType RdrName] } > +comma_types0 :: { [LHsType RdrName] } -- Zero or more: ty,ty,ty > : comma_types1 { $1 } > | {- empty -} { [] } > > -comma_types1 :: { [LHsType RdrName] } > +comma_types1 :: { [LHsType RdrName] } -- One or more: ty,ty,ty > : ctype { [$1] } > | ctype ',' comma_types1 {% addAnnotation (gl $1) AnnComma > (gl $2) > >> return ($1 : $3) } > diff --git a/docs/users_guide/glasgow_exts.xml > b/docs/users_guide/glasgow_exts.xml > index e12703f..7edca07 100644 > --- a/docs/users_guide/glasgow_exts.xml > +++ b/docs/users_guide/glasgow_exts.xml > @@ -6882,9 +6882,9 @@ is a single quote.</para> > </sect2> > > <sect2 id="promoted-lists-and-tuples"> > -<title>Promoted lists and tuples types</title> > +<title>Promoted list and tuple types</title> > <para> > -Haskell's list and tuple types are natively promoted to kinds, and enjoy > the > +With <option>-XTypeOperators</option>, Haskell's list and tuple types are > natively promoted to kinds, and enjoy the > same convenient syntax at the type level, albeit prefixed with a quote: > <programlisting> > data HList :: [*] -> * where > @@ -6893,8 +6893,21 @@ data HList :: [*] -> * where > > data Tuple :: (*,*) -> * where > Tuple :: a -> b -> Tuple '(a,b) > + > +foo0 :: HList '[] > +foo0 = HNil > + > +foo1 :: HList '[Int] > +foo1 = HCons (3::Int) HNil > + > +foo2 :: HList [Int, Bool] > +foo2 = ... > </programlisting> > -Note that this requires <option>-XTypeOperators</option>. > +For type-level lists of <emphasis>two or more elements</emphasis>, > +such as the signature of <literal>foo2</literal> above, the quote may be > omitted because the meaning is > +umambiguous. But for lists of one or zero elements (as in > <literal>foo0</literal> > +and <literal>foo1</literal>), the quote is required, becuase the types > <literal>[]</literal> > +and <literal>[Int]</literal> have existing meanings in Haskell. > </para> > </sect2> > > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

2 1

more parser conflicts?
by Richard Eisenberg 15 Dec '14

15 Dec '14

Hi devs, In unrelated work, I saw this scroll across when happy'ing the parser: > shift/reduce conflicts: 60 > reduce/reduce conflicts: 16 These numbers seem quite a bit higher than what I last remember (which is something like 48 and 1, not 60 and 16). Does anyone know why? Thanks, Richard

7 7

RE: Reachable modules from DynFlags out of date
by Simon Peyton Jones 15 Dec '14

15 Dec '14

Aha. I think I have it. "Hooks" shouldn't import DsMonad. Working on it now | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel@gmail.com] | Sent: 15 December 2014 13:45 | To: Simon Peyton Jones | Subject: Re: Reachable modules from DynFlags out of date | | Hello Simon, | | On 2014-12-15 at 11:58:13 +0100, Simon Peyton Jones wrote: | > Hum. "Reachable modules from DynFlags out of date" What can I do | now? | > Validated ok on my windows laptop. So I'm sorry but it looks as if | I | > have broken HEAD. Could revert but I'd prefer to fix. | > I did change some imports. | | ...do you mind if I revert that one (to unbreak GHC HEAD), and you re- | push that commit once it's sorted out? | | Cheers, | hvr

1 0

RE: Reachable modules from DynFlags out of date
by Simon Peyton Jones 15 Dec '14

15 Dec '14

| ...do you mind if I revert that one (to unbreak GHC HEAD), and you re- | push that commit once it's sorted out? yes, go ahead. I just wish I *understood* what was going on. Sorry about this S | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel@gmail.com] | Sent: 15 December 2014 13:45 | To: Simon Peyton Jones | Subject: Re: Reachable modules from DynFlags out of date | | Hello Simon, | | On 2014-12-15 at 11:58:13 +0100, Simon Peyton Jones wrote: | > Hum. "Reachable modules from DynFlags out of date" What can I do | now? | > Validated ok on my windows laptop. So I'm sorry but it looks as if | I | > have broken HEAD. Could revert but I'd prefer to fix. | > I did change some imports. | | ...do you mind if I revert that one (to unbreak GHC HEAD), and you re- | push that commit once it's sorted out? | | Cheers, | hvr

1 0