"Merge-buddy" response

Hi all If you recall I asked a while back for people to help me get my exact print annotation re-work stack merged. I had a number of people step up to offer their help (Brandon Allbery, Zubin Duggal, Ben Gamari and Alexandre Baldé). Of these, Brandon Allbery really stepped up to the plate. We

Re: "Merge-buddy" request

Thanks Zubin. And to re-iterate on what Simon said, I will cheerfully have a discussion with anyone who needs context for these. Alan On Fri, 27 Oct 2023, 12:24 Zubin Duggal, wrote: > Feel free to assign me for reviews. > > On 23/10/26 17:10, Alan & Kim Zimmerman wrote: >

"Merge-buddy" request

Hi all I have been landing a series of MRs to simplify the exact print annotations. They are split into pieces so each change is not too big. I still have quite a number of them to land, but am finding the process slow, as I - make the MR - wait for CI to go green - wait for a review, or ping

Re: How do you keep tabs on commits that fix issues?

I know if I backport anything I use 'git cherry-pick -x' which puts a reference to the original commit in the message. I am not sure how general that is though Alan On Thu, 28 Sept 2023 at 21:55, Justin Bailey wrote: > I would also love to know how to do this. I don't often contribute to GHC,

BoxedRep UNPACK pragma

I have seen the following warning on master for some time compiler/GHC/Core/TyCon.hs:1540:5: warning: • Ignoring unusable UNPACK pragma on the first argument of ‘BoxedRep’ • In the definition of data constructor ‘BoxedRep’ In the data type declaration for ‘PrimRep’ |

Exact Print Annotations Next Steps

I have put down some thoughts about simplifying the exact print annotations, prior to extending them to support printing the `RenamedSource`. See https://gitlab.haskell.org/ghc/ghc/-/issues/22319 Alan ___ ghc-devs mailing list ghc-devs@haskell.org

Re: Tags

I generally use hasktags (install via cabal-install), and you can give it a list of directories to index. I normally do it in the GHC/compiler directory, so it has just the GHC source Alan On Mon, 5 Sept 2022 at 20:51, Simon Peyton Jones < simon.peytonjo...@gmail.com> wrote: > I love emacs'

Re: 9.4.1 Final Call

I have a last exact print annotation diff, picked up from hackage roundtripping: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/8562 Alan On Tue, 05 Jul 2022, 10:39 Matthew Pickering, wrote: > Hello all, > > This is the final call for patches which need to be included in 9.4.1. > > The

Re: Release Status - 9.4.1-alpha2/9.2.3/9.0.* series

For the record, I have three exact print annotations commits that I would like to backport to 9.4. I am doing my final checks at the moment, will make an official request for them soon. On Mon, 23 May 2022 at 19:13, Matthew Pickering wrote: > Blog post:

Re: Output language of typechecking pass?

FYI, it is possible to make a "permalink" on github, which points to the code at a specific commit. Perhaps gitlab has something similar? Alan On Tue, 28 Dec 2021 at 19:28, Richard Eisenberg wrote: > We could always make a hyperlink to the source code as hosted on GitLab. > But I actually

LINE pragma behaviour

I am working through some ghc-exactprint test cases with GHC 9.2.1 and came across an oddity. If I parse some source with {-# LINE 93 "Foo.chs" #-} on line five, it shows up in the ParseSource as (L (Anchor { LINE:5:1-25 } (UnchangedAnchor)) (EpaComment (EpaLineComment "{-#

Re: Exact Print Annotations : Anchor in a SrcSpan

I agree on not re-using accidentally available structures. But it got me thinking that maybe the BufSpan could be something else. I’m somewhat confused by the fact that we agreed to do it post-merge, but > all further work has been in some other direction. > > My work since the merge has been on

Exact Print Annotations : Anchor in a SrcSpan

I have been updating the ghc-exactprint library for real world use cases on the about to be released GHC 9.2.1, and realised I need to be able to put an Anchor into every SrcSpan in the ParsedSource AST. I prepared !6854 to sort it out in master and turned to the problem of GHC 9.2.1, where I had

Re: Optics?

ompose, so that if you need > nested access, you could define several lenses, compose them together, and > then reach deep into a data structure. Then lenses might offer some > simplification. Otherwise, an ordinary getter/setter pair is just as good. > > - Vlad > > > On 3 Oct 20

Optics?

Hi all I am working on a variant of the exact printer which updates the annotation locations from the `EpaSpan` version to the `EpaDelta` version, as the printing happens data EpaLocation = EpaSpan RealSrcSpan | EpaDelta DeltaPos The function doing the work is this markAnnKw

Re: value of documenting error messages?

I think in practical terms for IDE-based people, a short standardised alphanumeric identifier makes sense. These typically get displayed along with the full error text in the error pane, and it helps to be able to allocate a known, standard amount of real estate to them. Fundamentally they are

Re: Errors in haddock git fetch

You can get rid of the errors by doing git remote prune Where is the name you have for the upstream repo, normally 'origin'. Alan On Thu, 27 May 2021 at 16:11, Sylvain Henry wrote: > > error: cannot lock ref 'refs/remotes/origin/wip/hsyl20/dynflags': >

Re: instance {Semigroup, Monoid} (Bag a) ?

I wonder if it would be possible to have an hlint rule to check for mempty instead of emptyBag. On Wed, 14 Apr 2021 at 19:27, Richard Eisenberg wrote: > Hi devs, > > In the work on simplifying the error-message infrastructure (heavy lifting > by Alfredo, in cc), I've been tempted (twice!) to

Re: GHC Exactprint merge process

standable and maintainable. > > Thanks, > Richard > > On Mar 6, 2021, at 12:39 PM, Alan & Kim Zimmerman > wrote: > > I have been running a branch in !2418[1] for just over a year to migrate > the ghc-exactprint functionality directly into the GHC AST[2], and

GHC Exactprint merge process

I have been running a branch in !2418[1] for just over a year to migrate the ghc-exactprint functionality directly into the GHC AST[2], and I am now satisfied that it is able to provide all the same functionality as the original. This is one of the features intended for the impending 9.2.1

Re: MR template text

I'm not sure if it would work here, but I have seen some issue templates, e.g. for haskell-language-server on github[1], use comment markup in the template. e.g. This is not rendered on the web or email views, but is seen when editing. Alan [1]

Re: Lexing / Parsing and final token

FYI I did the horrible thing for now, optimisations welcome. The change is at [1] Alan [1] https://gitlab.haskell.org/ghc/ghc/-/commit/742273a94c187f51e3b143f9c206c42024486ecf?merge_request_iid=2418 On Tue, 19 Jan 2021 at 22:04, Alan & Kim Zimmerman wrote: > And if there is a commen

Re: Lexing / Parsing and final token

s and semis" is taken > more literally for semis than for curlies. > > Richard > > On Jan 19, 2021, at 4:58 PM, Alan & Kim Zimmerman > wrote: > > Changing it to remove the final ';' gives a last token of ITccurly. > > Changing it to > > module Bug where &g

Re: Lexing / Parsing and final token

, I tried > > module Bug where { > x = 5; > y = 6; > }; > > and GHC rejected because of the trailing ;. > > Richard > > > On Jan 19, 2021, at 4:35 PM, Alan & Kim Zimmerman > wrote: > > > > I am (still) working on !2418 to bring the API A

Lexing / Parsing and final token

I am (still) working on !2418 to bring the API Annotations into the GHC ParsedSource, and making good progress. I am currently making a rough port of ghc-exactprint, to ensure I can get all the tests around modifying the AST to work. One of the last pieces is being able to capture the spacing

HsPragTick

I am working through the API Annotations, and have come across HsPragTick. In source it appears as c = {-# GENERATED "foobar" 1 : 2 - 3 : 4 #-} 0.00 But it does not seem to be used anywhere. It is passed through for renaming and type checking, and Coverage.hs uses it as addTickHsExpr

Re: GHC 9.0?

Which sounds like we have agreed on 9.0? Alan On Thu, 23 Jul 2020, 00:28 Ben Gamari, wrote: > Artem Pelenitsyn writes: > > > Does Quick Look still have chances to make it into the next release? > > It'd be fascinating if the major version bump got both linear and > > impredicative types! > >

Re: in-tree API Annotations

And to reply to my own question, yes we do, we use them to tie up the ParsedSource RdrName to the renamed Name when considering refactorings. On Mon, 25 May 2020 at 23:33, Alan & Kim Zimmerman wrote: > I am trying to get my head around the best way to put the API annotations > in

in-tree API Annotations

I am trying to get my head around the best way to put the API annotations into the GHC ParsedSource directly, so ghc-exactprint can move in to GHC and make the development/testing process easier. Prior to API Annotations, there were very few locations in the AST, as they were added as anchor

Re: Inclusion of the parser refactor in 8.12

This would also help to resolve https://github.com/digital-asset/ghcide/pull/350#discussion_r370878197, where we cannot get ApiAnnotations and Haddock comments at the same time. On Tue, 12 May 2020 at 18:38, Karpov, Mark wrote: > Hello, > > I'd like to mention that it would be nice if this

Extension.hs ForallXXX constraints

I have got back into some GHC dev, and noticed that the various ForallXXX type synonyms in Extension.hs are unused in GHC. In the early iteration, they were needed, but it seems not any more. Is there any reason they should not be removed? Alan ___

Re: Proposed changes to merge request workflow

What about some sort of script that detects MR older than x time without a reviewer, and asks a group of people to take a look. On Fri, 8 Nov 2019 at 19:36, Richard Eisenberg wrote: > I wonder if it would alleviate the concerns to have a ghc-maintainers > mailing list. This is distinct from

Re: How to navigate around the source tree?

I use `hasktags -b .` in the compiler directory, and it generates a `tags` file with lines in it like ``` tags\021080:mkHsPar ./GHC/Hs/Utils.hs 142 tags\021081:mkHsParPV ./parser/RdrHsSyn.hs 1920 tags\021082:mkHsParPV ./parser/RdrHsSyn.hs 2019 tags\021083:mkHsParPV ./parser/RdrHsSyn.hs 2072

Re: Urgent: git problem

I do git pull origin master And it then works Alan On Wed, 23 Oct 2019, 17:29 Simon Peyton Jones via ghc-devs, < ghc-devs@haskell.org> wrote: > a completely fresh clone seems ok. but that’s a bit brutal > > > > *From:* ghc-devs *On Behalf Of *Simon > Peyton Jones via ghc-devs > *Sent:* 23

Re: [ANNOUNCE] GHC 8.6.4 is now available

I'm impressed, 'stack setup 8.6.4` brings it down already. Alan On Tue, 5 Mar 2019 at 23:58, Phyx wrote: > Thanks! To be fair I'm not really sure how popular it is. I was wondering > since once I upload the chocolatey packages it's immutable. > > If there's anything I can help with let me

Re: Marge has been stabilised

> Every 30 minutes whilst idle she will try to find new MRs to batch > together. If she finds at least two MRs to batch together then she > creates a batch as a new merge request. A batch is the series of MRs > rebased on top of each other from oldest to newest. Does this mean that on a quiet

Re: [GHC DevOps Group] Welcome to GitLab!

Congratulations, and well done. Changing basic infrastructure is a huge and thankless job. Alan On Thu, 27 Dec 2018 at 08:27, Ben Gamari wrote: > TL;DR. https://gitlab.haskell.org/ghc/ghc.git is now the official >upstream GHC repository. Various introductory notes are >

Re: [GHC DevOps Group] The future of Phabricator

As part of the silent bystander grouping, I just want to voice a weak ok for switching to gitlab, especially as a way to eventually bring the code, issues, wiki, etc into one place. To me the main benefit is that it is open source, allows own deployments and is under active development, which

Re: Parser.y rewrite with parser combinators

I am not against this proposal, but want to raise a possible future concern. As part of improving the haskell tooling environment I am keen on making GHC incremental, and have started a proof of concept based in the same techniques as used in the tree-sitter library. This is achieved by

Re: TTG hsSyn for Batch and Interactive Parsing

On 18 May 2018 at 16:13, Simon Peyton Jones wrote: > > > We can’t make the result type depend on DynFlags! (Yet)( > > *parser :: DynFlags -> String * > > * -> HsSyn (GhcPass (Parsed (if … * > > *then WithApiAnnotations* > > *

Re: TTG hsSyn for Batch and Interactive Parsing

I have updated the Wiki with the clearer names, and noted that a single parser definition would still be used, as at present, but would only keep the extra info if it was requested to. The naming around interactive and batch is to anticipate a further step I would like to take, to make the parser

Re: TTG hsSyn for Batch and Interactive Parsing

larifying on the wiki page, so that it is a > persistent record of the design debugged in dialogue by email. > > > > Simon > > > > *From:* Alan & Kim Zimmerman <alan.z...@gmail.com> > *Sent:* 08 May 2018 21:02 > *To:* Simon Peyton Jones <simo...@micros

Re: TTG hsSyn for Batch and Interactive Parsing

y mind. One seems quite local (how to run the > parser). The other seems more pervasive. > > > > Can you say more about your proposed design, perhaps even on a wiki page? > > > > Simon > > > > *From:* ghc-devs <ghc-devs-boun...@haskell.org> *On Beha

TTG hsSyn for Batch and Interactive Parsing

I want to be able to run the GHC parser in one of two modes, batch which functions as now, and interactive which will (eventually) be incremental. In addition, the hsSyn AST for each will have different TTG[1] annotations, so that it can better support IDE usage. I think this can be done by

Re: Eight GHC projects for Google Summer of Code

Congratulations to all. I look forward to seeing these move forward. Alan On 23 April 2018 at 18:55, Matthew Pickering wrote: > Hi all, > > I am glad to report that eight GHC related projects have been selected > for this years GSoC. > > Chitrak Gupta - Help

Re: Type family constraints

Thanks Richard Ryan Scott has also put together a solution[1], which is basically what you proposed. But in terms of trying to clean up the code by removing a straightforward constraint type, I think this solution adds more complexity than it removes. So I will leave it as it is. Alan [1]

Type family constraints

Given data GhcPass (c :: Pass) deriving instance Eq (GhcPass c) deriving instance Typeable c => Data (GhcPass c) data Pass = Parsed | Renamed | Typechecked deriving (Data) Is there any way to express that `pass` must be valid for each value of `Pass` in the following instance head?

HsVectInstIn is dead code?

If I grep through the GHC source, or do a github search[1] It seems that HsVectInst exists, and can be renamed, typechecked, zonked, desugared. But it does not get parse, and does not appear to be introduced in any other way. Am I missing something? Should it be deleted (as hinted at in one of

Re: [GHC] #14490: TTG Snags

Yes, but it is not feasible before GHC 8.6, due to needing GHC >= 8.2 for bootstrapping. On 22 November 2017 at 15:26, GHC wrote: > #14490: TTG Snags > -+-- > --- > Reporter: alanz |

Re: Trees that Grow and constraints

I have updated the page, with a bit more detail and an additional plan > OK. It’s hard to keep this straight in email. Take a look at >> >> https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/Instances >> >> >> >> Please edit and improve it. >> >> Alan

Re: Trees that Grow and constraints

ow/Instances > > > > Please edit and improve it. > > > > Simon > > > > > > *From:* Alan & Kim Zimmerman [mailto:alan.z...@gmail.com] > *Sent:* 13 November 2017 13:30 > > *To:* Simon Peyton Jones <simo...@microsoft.com> > *Subject:*

Re: Trees that Grow and constraints

) = Type (modelling existing PostTc) Alan On 13 November 2017 at 11:23, Alan & Kim Zimmerman <alan.z...@gmail.com> wrote: > At the moment the Trees that Grow implementation in GHC master makes use > of massive constraint types to provide Data instances for the hsSyn AST. > >

Re: Trees that Grow and constraints

> So why not use one? > > > > Simon > > If I do instance (Data p) => Data (Experiment p) then GHC does not know that the type instances for type instance XEOverLit (GhcPass 'Parsed ) = PlaceHolder type instance XEOverLit (GhcPass 'Renamed) = PlaceHolder type instance

Re: Trees that Grow and constraints

riving instance (Data GhcTc) => Data (Experiment GhcTc) works, but only for GHC 8.2.1, not GHC 8.0.2 Alan On 13 November 2017 at 11:23, Alan & Kim Zimmerman <alan.z...@gmail.com> wrote: > At the moment the Trees that Grow implementation i

Trees that Grow and constraints

At the moment the Trees that Grow implementation in GHC master makes use of massive constraint types to provide Data instances for the hsSyn AST. I am trying to remove the need for this, and have hit a problem. The example I have reduced it to is here [1] The essence of the problem is

Re: [Haskell-cafe] [ANNOUNCE] GHC 8.2.2 release candidate 2

To me this is just further evidence that we need a first class API for tool makers. Which is a (slow) work in progress. Alan On 6 November 2017 at 19:46, Sven Panne wrote: > 2017-11-06 17:54 GMT+01:00 Ben Gamari : > >> Next time something like this

Re: forall in constraint

In Shayan's implementation he has [1] data ImplicitBndrs x thing = IB (XIB x thing) thing | NewImplicitBndrs (XNewImplicitBndrs x thing) type family XIB x thing type family XNewImplicitBndrs x thing type ForallXImplicitBndrs c x thing = ( c (XIB

forall in constraint

I am working on the Trees that Grow stuff, and hit a small problem I have type family XIB x thing type family XNewImplicitBndrs x thing type ForallXImplicitBndrs (c :: * -> Constraint) (x :: *) (thing :: *) = ( c (XIB x thing) , c (XNewImplicitBndrs x

Wildcards in HsTypes

It seems to me that HsWildCardInfo is unnecessary. It is defined as newtype HsWildCardInfo pass -- See Note [The wildcard story for types] = AnonWildCard (PostRn pass (Located Name)) -- A anonymous wild card ('_'). A fresh Name is generated for -- each individual anonymous

haddock specializeInstHead

I am working the next stage of Trees that Grow into GHC [1], and need to update Haddock. The `Specialize` module[2] exports a single function, `specializeInstHead` which is called once, specialised to `GhcRn`. So all it needs to be for haddock use is specializeInstHead :: InstHead GhcRn ->

Re: Phab: conditional approval

William Casarin recently tweeted a link to the bitcoincore devs ACK system[1], which are Concept ACK - Agree with the idea and overall direction, but haven't reviewed the code changes or tested them. utACK (untested ACK) - Reviewed and agree with the code changes but haven't actually tested

Re: Operating on HsSyn

I agree. 4 is the current GHC invariant. i.e., re-parsing a pretty printed parse tree gives you back a parse tree identical to the original (ignoring SrcSpans) Alan On 28 July 2017 at 20:34, MarLinn wrote: > by > > (parser . prettyPrint . parser) = id > > I meant > >

Re: Proposed: Language.Haskell.TH.Internal

This can serve as a starting point for the Trees that Grow implementation too, I understand Shayan Najd is intending to eventually harmonise the hsSyn AST and the TH one. Alan On 18 July 2017 at 14:27, Richard Eisenberg wrote: > Hi devs, > > This is a brief proposal for

Re: Removing Hoopl dependency?

But equally, stackage is a major part of the haskell ecosystem. As such, implications and paths forward need to be considered. Alan On 9 June 2017 at 11:16, Herbert Valerio Riedel wrote: > Hi Simon, > > On 2017-06-09 at 09:50:51 +0200, Simon Peyton Jones via ghc-devs

Trees that Grow / D3609

This is a heads up that D3609[1], the first step toward implementing Trees that Grow[2] for the hsSyn AST is about to land in master. The key change is that it is replacing the HsSyn type parameter with one that is an index into a set of type families, enabling the extension points (for a future

Re: Interested to help with error messages

Thanks Ben, a great summary. Is there a Wiki page for this? It feels like it should be on one, so we can easily comment/update the individual points. In terms of the pretty-printer and its string type. Perhaps we could backpackify it to use http://next.hackage.haskell.org:8080/package/str-sig,

Re: HsParTy

See 3b23f680c2b1f80b693eb8896fb21e4bbf8edc7e On 26 May 2017 at 13:32, Simon Peyton Jones wrote: > I can try to strip then all out and see what happens. > > That’d be good! With a Note to explain why… > > > > We still need ctxt_prec, I think, to pass to the ordinary type

Re: HsParTy

When I was working through the ppr to use HsParTy everywhere it was not clear whether there were any usages that required maybeParen, so I left it in. I can try to strip then all out and see what happens. Alan On 26 May 2017 at 10:54, Simon Peyton Jones wrote: > Alan >

Trees that Grow in the hsSyn AST

Hi all You may be aware that Shayan Najd presented the paper "Trees that Grow"[1] at HIW last year. Based on the following mandate > As in my previous email to Shayan (attached). Wiki page, describe goals, design, > approach. Point to prototype implementation. Seek comments. You can say

Re: Type families and classes

)) => SyntaxExpr x id Alan On 18 May 2017 at 09:04, Alan & Kim Zimmerman <alan.z...@gmail.com> wrote: > Hi all > > I am experimenting with Trees that Grow [1] in the context of the GHC > HsSyn AST, and wanting to express that a given extension point needs to

Type families and classes

Hi all I am experimenting with Trees that Grow [1] in the context of the GHC HsSyn AST, and wanting to express that a given extension point needs to have certain properties. The specific case is to be able to contain a SourceText, in the context of HsLit So I have (stripped down) data GHCX

Re: GHC 8.2.1-rc1 source tarball availability

There is no tag in the source tree, which commit has been used? Alan On 4 April 2017 at 06:21, Ben Gamari wrote: > > tl;dr: If you would like to produce a binary distribution for GHC >8.2.1-rc1 then let me know, grab the source distribution and >start

Re: Why are there no Show instances for internal types

And I guess it would be bad to use Show, but make custom instances for the problematic types that did not loop? Alan On 18 Mar 2017 9:44 pm, "Edward Z. Yang" wrote: > We can't add Show instances for these types because many types > below them, e.g., Type, are cyclic, and would

Re: Travis again over time

FYI, liquidhaskell switched from travis to circleci.com because of timeout problems. It seems the time available is larger there. And you get access to the build artifacts afterward, as per your configuration. Alan On 9 March 2017 at 19:17, Joachim Breitner wrote: >

Re: Disable messages with GHC API

Here [1] is the tweak we do in HaRe to get the right dynflags Alan [1] https://github.com/alanz/HaRe/blob/master/src/Language/Haskell/Refact/Utils/Utils.hs#L224 On 3 Feb 2017 5:59 p.m., "Matthew Pickering" wrote: > You are right. I looked more closely now and it

Re: Cannot build GHC using the Newcomers guide

FWIW, I use the docker image, as per https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Linux#Docker, where I have the invocation in a one-line script Alan On 26 January 2017 at 19:38, Phyx wrote: > But do you really want to do this? > > It seems to me you don't

Re: Including remote-iserv upstream?

As a matter of interest, are you making use of `createIservProcessHook` which allows you to set the FDs to be used when communicating with the iserve process? ___ ghc-devs mailing list ghc-devs@haskell.org

Re: Confused about the sub-modules

For the utils/haddock submodule there is a ghc-head branch, and the commit should be on that before pushing to GHC master with a submodule update. I do not know if that convention is followed on any of the other libraries. Alan On Wed, Dec 21, 2016 at 8:48 AM, Edward Z. Yang

Re: Reading source annotations during type checking

I did, and thought I saw a reply. They are captured in the AST. data AnnDecl name = HsAnnotation SourceText -- Note [Pragma source text] in BasicTypes (AnnProvenance name) (Located (HsExpr name)) Alan On Tue, Dec 20, 2016 at 2:54 AM, Ben Gamari

Fwd: [Ann] Haskell Ecosystem Proposals

I am forwarding this mail to ghc-devs and cabal-devs in case anyone missed the original which went to haskell-cafe only. Alan -- Forwarded message -- From: Alan & Kim Zimmerman <alan.z...@gmail.com> Date: Sun, Dec 11, 2016 at 9:39 PM Subject: [Ann] Haskell Ecosystem

Re: Measuring performance of GHC

I agree. I find compilation time on things with large data structures, such as working with the GHC AST via the GHC API get pretty slow. To the point where I have had to explicitly disable optimisation on HaRe, otherwise the build takes too long. Alan On Sun, Dec 4, 2016 at 9:47 PM, Michal

Paren removal in renamer

Hi all I have been wrestling with something silly most of today. T12530 has the following splice in it, which has parens around the "(Maybe Int)". $([d| -- Test the Template Haskell pretty-printing for TypeApplications f = id @(Maybe Int) |]) the parsed source has these parens,

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

GHC pretty printer philosophy

I am currently working on #3384, with the intent of ensuring that parse (ppr (parse source)) == parse source I have hit the issue where foo :: (Int) has the parens reflected in the original parsed AST, but the types pretty printer goes to a lot of trouble to remove any parens not

Re: ppr of HsDo

As a follow up, I will be continuing with the least-invasive change, which is to keep the existing braces/semis, and make sure that they are all produced correctly. Alan On Thu, Nov 10, 2016 at 12:06 PM, Alan & Kim Zimmerman <alan.z...@gmail.com> wrote: > For context, I am putt

Re: ppr of HsDo

hers! > > > > Simon > > > > *From:* Alan & Kim Zimmerman [mailto:alan.z...@gmail.com] > *Sent:* 10 November 2016 08:31 > *To:* Simon Peyton Jones <simo...@microsoft.com> > *Cc:* ghc-devs@haskell.org > *Subject:* Re: ppr of HsDo > > > > Thanks. &

Re: ppr of HsDo

gt; > foo > = do { let x = 1; Just 5 } > > > > So it’s a bug in the pretty-printer, not the parser > > > > SImon > > > > > > *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Alan > & Kim Zimmerman > *Sent:* 10 November 2

ppr of HsDo

The pretty printer turns foo = do let x = 1 Just 5 into foo = do { let x = 1; Just 5 } which does not parse, complaining about "parse error on input ‘Just’" Is this a parser error or a ppr problem? I am keen to fix the ppr to output foo = do let x = 1 Just 5 but I

Compilation optimisation performance example - HaRe

At the moment HaRe has -O0 set for the library. Here are some timing differences on my machine with optimisation on and off With normal optimisation, we get $ rm -fr dist-newstyle/ $ cabal new-configure --enable-test $ time cabal new-build real6m54.778s

Re: How to best display type variables with the same name

This sounds like a thing that should be in the GHC API (the tyvar to provenance lookup). Alan On Wed, Oct 19, 2016 at 2:48 PM, Richard Eisenberg wrote: > Interesting problem & solution. > > Here's a wacky idea, from a position of utter ignorance about your > environment:

Re: How, precisely, can we improve?

For me the biggest problem is that each of the three Wiki's has a different markup syntax. So the mental motivation to do anything is tempered by having to look up everything to make sure you are using the right markup for *this* Wiki. Reducing it to one, wherever it is, would help a lot. Alan

Re: Grand Plan for 8.0.2

Done, see https://phabricator.haskell.org/D2518 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Tooling-friendly ModSummary

At the moment the standard way to use the GHC API is something like _ <- load LoadAllTargets modSum <- getModSummary mn p <- parseModule modSum And likewise if renamed or typechecked ASTs are needed. But the `load` step

RdrName and decorations

Hi all At the moment I am working through ghc-exactprint, adding a feature to add standard API annotations to any constructed AST so that it can be (pretty)-printed. One of the major headaches is the decorations on a RdrName. What I mean by this is that an item appearing in the AST as a RdrName

Re: Note [Api annotations]

Hopefully at a future date they will be a part of the AST itself, so this will be clearer. In reality, looking at Parser.y is not enough, as there are some workings in RdrHsSyn.hs too, and the process of attachment in Parser.y is sometimes quite complex. Basically the best reference is indeed

Re: Proposal process status

I think the most important thing is to be able to point to a designated point where discussions must take place. This means if anything comes up elsewhere it can be routed there to be "official". Alan On Wed, Jul 20, 2016 at 1:42 PM, Yuras Shumovich wrote: > > Looks like

Re: Why upper bound version numbers?

I think "hard" upper bounds would come about in situations where a new version of a dependency is released that breaks things in a package, so until the breakage is fixed a hard upper bound is required. Likewise for hard lower bounds. And arguments about "it shouldn't happen with the PVP" don't

Re: instances for closed type families

a > different story. But I doubt that such a thing is possible in this > case (based on the definition of NameOrRdrName you gave), so I think > we'll just have to settle for turning on UndecidableInstances and > writing code that we know won't throw the typechecker into a loop. > >

Re: [GHC] #11140: add command-line option to GHC to dump raw parse trees of Haskell programs

I'm with mpickering on this one. Each stage has a debug format that makes sense for the stage. For parsing it is the exact ast Alan On 18 May 2016 12:43 PM, "GHC" wrote: > #11140: add command-line option to GHC to dump raw parse trees of Haskell > programs >

Re: ORF and renamer

Regards Alan On Tue, Feb 23, 2016 at 8:29 PM, Alan & Kim Zimmerman <alan.z...@gmail.com> wrote: > Hi Adam > > Thanks for the response. My initial mail was more of a sanity check to > see if anything had in fact changed, as I saw that the ambiguous case > is pushed to t

  1   2   3   >