"Merge-buddy" response

[Alan & Kim Zimmerman]

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 got into a
daily rhythm and have now landed 37 Merge Requests, completing my initial
rework.  Thank you very much.

There has been further discussion of next steps at
https://gitlab.haskell.org/ghc/ghc/-/issues/23447, and I will be starting
on the further simplification we have discussed there.

Thanks again all.

Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: "Merge-buddy" request

[Alan & Kim Zimmerman]

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:
> >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 people on chat to do the review
> >- once approved, land it.
> >
> >I don't want to loudly shout for reviewers each time, and become a general
> >irritant.
> >
> >Is there anyone (ideally with an interest in the exact print annotations)
> >that would like to be my "merge buddy" that I can easily ask to do the
> >reviews?
> >
> >I am happy for each one to take a couple of days, so it is not a high
> >pressure thing, I just want to get into a cadence on them.
> >
> >My current one is
> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11496.
> >Admittedly only one reviewer requested, and he is always busy, and I do
> not
> >want to make him even more so.
> >
> >Alan
>
> >___
> >ghc-devs mailing list
> >ghc-devs@haskell.org
> >http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

"Merge-buddy" request

[Alan & Kim Zimmerman]

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 people on chat to do the review
- once approved, land it.

I don't want to loudly shout for reviewers each time, and become a general
irritant.

Is there anyone (ideally with an interest in the exact print annotations)
that would like to be my "merge buddy" that I can easily ask to do the
reviews?

I am happy for each one to take a couple of days, so it is not a high
pressure thing, I just want to get into a cadence on them.

My current one is https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11496.
Admittedly only one reviewer requested, and he is always busy, and I do not
want to make him even more so.

Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

[Alan & Kim Zimmerman]

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,
> but I follow bug fixes closely. In fact, the one time I did contribute (
> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10245), it turned out
> i was duplicating work already done elsewhere! If I had known how to
> understand if the issue I wanted fixed (
> https://gitlab.haskell.org/ghc/ghc/-/issues/22516) was backported, it
> would have saved me and the maintainers' time.
>
> On Wed, Sep 27, 2023 at 11:56 PM Bryan Richter via ghc-devs <
> ghc-devs@haskell.org> wrote:
>
>> I am not sure of the best ways for checking if a certain issue has been
>> fixed on a certain release. My past ways of using git run into certain
>> problems:
>>
>> The commit (or commits!) that fix an issue get rewritten once by Marge as
>> they are rebased onto master, and then potentially a second time as they
>> are cherry-picked onto release branches. So just following the original
>> commits doesn't work.
>>
>> If a commit mentions the issue it fixes, you might get some clues as to
>> where it has ended up from GitLab. But those clues are often drowning in
>> irrelevant mentions: each failed Marge batch, for instance, of which there
>> can be many.
>>
>> The only other thing I can think to do is look at the original merge
>> request, pluck out the commit messages, and use git to search for commits
>> by commit message and check each one for which branches contain it. But
>> then I also need to know the context of the fix to know whether I should
>> also be looking for other, logically related commits, and repeat the dance.
>> (Sometimes fixes are only partially applied to certain releases,
>> exacerbating the need for knowing the context.) This seems like a mechanism
>> that can't rely on trusting the author of the original set of patches
>> (which may be your past self) and instead requires a deep understanding to
>> be brought to bear every time you would want to double check the situation.
>> So it's not very scalable and I wouldn't expect many people to be able to
>> do it.
>>
>> Are there better mechanisms already available? As I've said before, I am
>> used to a different git workflow and I'm still learning how to use the one
>> used by GHC. I'd like to know how others handle it.
>>
>> Thanks!
>>
>> -Bryan
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

BoxedRep UNPACK pragma

[Alan & Kim Zimmerman]

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’
 |
1540 |   | BoxedRep {-# UNPACK #-} !(Maybe Levity) -- ^ Boxed, heap value
 | ^^^

Is it something that needs to be fixed? Can the code be updated to remove
the warning?

Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Exact Print Annotations Next Steps

[Alan & Kim Zimmerman]

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
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Tags

[Alan & Kim Zimmerman]

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' tags-query-replace function, which allows me to do a
> search-and-replace across an entire repo.  But to do that I need a TAGS
> file that, at least, lists all the Hsakell files in GHC.
>
> What is the approved way to construct a TAGS file for a bunch of Haskell
> modules?  Is this documented anywhere?
>
> Thanks
>
> Simon
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: 9.4.1 Final Call

[Alan & Kim Zimmerman]

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 status of which I do not know the answer:
>
> * GHC 9.4 infinite loop in typechecker - #21530 (@simonpj, @rae) ?
>
> To my knowledge the remaining unfinished work list is:
>
> * Resolve static linking issues with text-2.0 - #21787 (Unresolved)
> (Matt/Ben/Zubin/Tamar/Andreww)
> * CAF reachability bug with -fprof-late - !7797 (WIP) (Andreas/Ben)
> * XMonad segfault - #21708 (WIP) (Ben/Andreas)
> * HIE File Fixes - !7888 (landing) (Zubin)
> * template-haskell-2.19.0.0 depends on filepath - !8516 (landing) (Matt)
> * Module loops and multiple home units leads to a panic - !8573
> (nearly ready to land) (Matt)
> * extendMG leaks memory - #21816 (Zubin/Matt)
>
> To my knowledge, the following are not making it into 9.4.1.. but are
> not critical to revert:
>
> * Tidy up withDict and friends - #21568
>
> Looking like a great release.
>
> Matt
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

[Alan & Kim Zimmerman]

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: https://www.haskell.org/ghc/blog/20220523-release-status.html
>
> On Mon, May 23, 2022 at 10:33 AM Matthew Pickering
>  wrote:
> >
> > Hi all,
> >
> > I will shortly prepare a blog post which describes the situation in
> > more detail for a general audience but for the subscribers here is a
> > summary of the release status.
> >
> > 9.4.1-alpha2: The release is imminent, and fixes a number of packaging
> > issues identified with alpha1. Slightly delayed due to regression
> > involving deb9 toolchains. (Ben)
> >
> > 9.2.3: The release will follow shortly (within 1 week) after the
> > 9.4.1-alpha2 release. Slightly delayed due to 9.4.1-alpha2 delay. (Zubin)
> >
> > 9.4.1: The target for the final release is end of July.
> >
> > 9.0.* series: We do not intend to do any more releases in the 9.0.*
> series.
> >  - The 9.2 series is more stable
> >  - The 9.2 series does not contain significant breakage (when
> > upgrading from 9.0)
> >  - Anecdotal evidence suggests users are upgrading straight from 8.10.7
> to 9.2.2
> >  - We do not have capacity to manage 4 active branches.
> >
> > Any thoughts, please reply promptly before I communicate these facts
> > with the community.
> >
> > Best Wishes,
> >
> > Matt
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Output language of typechecking pass?

[Alan & Kim Zimmerman]

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 argue not to: such links would quickly become outdated, in
> one of two ways: either we make a permalink, in which case the linked Note
> text will become outdated; or we make a link to a particular file & line,
> in which case the Note might move somewhere else. Instead, just by naming
> the Note title, we have a slightly-harder-to-use link, where you use it by
> grepping the source code. This is less convenient, but it will stay
> up-to-date. Until we have better tooling to, say, create an HTML anchor
> based on a Note, I think this is the best we can do.
>
> Richard
>
> On Dec 28, 2021, at 12:10 PM, Benjamin Redelings <
> benjamin.redeli...@gmail.com> wrote:
>
> I was thinking about the relationship between the wiki and the notes in
> the GHC source.
>
> Would it be possible to link directly to [compiler notes] in the GHC
> source from the wiki, using hyperlinks?  Right now, I'm seeing references
> that look like: (See Note [Constraint flavours].)
>
> (I can see the motivation to include comments in the source, but I also
> think that the wiki is more discoverable than the compiler source code.
> So, in the interests of pursuing both approaches, it would be nice to be
> able to link to notes FROM the wiki.  I suppose one could include a
> hyperlink to the file on github that contains the note...)
>
> I'm not sure how much web infrastructure would be required to make
> hyperlinks for notes...
>
> -BenRI
> On 11/8/21 5:35 AM, Simon Peyton Jones wrote:
>
> Is there anywhere on the GHC wiki that explains how to interpret this
> output, and says that the type and dictionary applications ARE there, just
> not shown by '-ddump-tc'?
>
> Perhaps it would be helpful to add some basic description of what comes
> out of the typechecker to a page like this one? (below)
>
>
> https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/compiler/hsc-main
> 
> Yes it would!  Would you care to start such a wiki page (a new one; don’t
> just clutter up the one you point to)?You can write down what you
> know.  Don’t worry if you aren’t 100% sure – we can correct it.  And if you
> outright don’t know, leave a “What should I say here?” note.
>
>
> "This late desugaring is somewhat unusual. It is much more common to
> desugar the program before typechecking, or renaming, because that presents
> the renamer and typechecker with a much smaller language to deal with.
> However, GHC's organisation means that
> This note is now slightly out of date.  We are now, very carefully, doing
> some desugaring *before* typechecking.  See
>
>- Note [Handling overloaded and rebindable constructs]  in
>GHC.Rename.Expr
>- Note [Rebindable syntax and HsExpansion] in GHC.Hs.Expr
>
>
> You can and should point to these and similar Notes from the wiki page you
> write.  Indeed there may be some part of what you write that would be
> better framed as Note in GHC’s source code.
>
> Thanks!
>
> Simon
>
> PS: I am leaving Microsoft at the end of November 2021, at which point
> simo...@microsoft.com will cease to work.  Use simon.peytonjo...@gmail.com
>  instead.  (For now, it just forwards to simo...@microsoft.com.)
>
> *From:* ghc-devs 
>  *On Behalf Of *Benjamin Redelings
> *Sent:* 08 November 2021 13:12
> *To:* Richard Eisenberg  
> *Cc:* ghc-devs@haskell.org
> *Subject:* Re: Output language of typechecking pass?
>
>
> Hi,
>
>
>
> Questions:
>
>
>
> 1. It seems like this separation is actually necessary, in order to apply 
> generalization only to let arguments written by the programmer, and not to 
> let bindings introduced during desugaring. Is that right?
>
>
>
> I don't think so. That is, if we did it all in one pass, I still think we 
> could get generalization right.
>
> I guess I asked this question wrong.  I mean to say, if we did the two
> passes in the reverse order (desugaring first, followed by typechecking),
> that would not work, right?
>
> As the wiki says:
>
> "This late desugaring is somewhat unusual. It is much more common to
> desugar the program before typechecking, or renaming, because that presents
> the renamer and typechecker with a much smaller language to deal with.
> However, GHC's organisation means that
>
>- error messages can display precisely the syntax that the user wrote;
>and
>- 

LINE pragma behaviour

[Alan & Kim Zimmerman]

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
"{-# LINE 93 \"Foo.chs\" #-}")
   { LINE:5:1-25 }))

and the following item locations are unchanged.

The effect seems to be to change the name of the file in the RealSrcSpan to
"LINE", but just for that line, and no other effect.

Is this expected?

Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Exact Print Annotations : Anchor in a SrcSpan

[Alan & Kim Zimmerman]

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 consolidating the actual use-case for
the exact print annotations, which means making sure that the (still
external) ghc-exactprint library is still able to support the existing
use-cases.  My current driver for that is porting retrie[1] to use it,
which has brought up the changes that I have been doing to GHC recently.

Once that is done, I plan to update the in-tree exact printing to match,
and then contemplate actioning plan B.

Alan

[1] https://github.com/alanz/retrie/tree/ghc-9.2
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Exact Print Annotations : Anchor in a SrcSpan

[Alan & Kim Zimmerman]

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 missed the boat.

And then I discovered that we have SrcSpan defined as

data SrcSpan =
RealSrcSpan !RealSrcSpan !(Maybe BufSpan)
  | UnhelpfulSpan !UnhelpfulSpanReason

and the (Maybe BufSpan) is only used for attaching haddock comments after
parsing.

This means there is an isomorphism between the RealSrcSpan variant and an
Anchor, which I take advantage of with the code in [1], by using the Maybe
to encode the AnchorOperation and the BufSpan to encode the DeltaPos.

And it struck me that perhaps we should make this a more official
approach.  The only problem is the detail of the BufSpan, to be able to
play both roles cleanly.

Alan

[1] https://gist.github.com/alanz/5e262599ab79138606cdfcf3792ef635
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Optics?

[Alan & Kim Zimmerman]

With a pointer from Vlad and some study of the lens tutorial, I made a
proof of concept at [1].
I am deliberately not using the existing lens library as I envisage this
code ending up in GHC.

Alan

[1]
https://github.com/alanz/ghc-exactprint/blob/f218e211c47943c216a2e25d7855f98a0355f6b8/src/Language/Haskell/GHC/ExactPrint/ExactPrint.hs#L689-L723



On Sun, 3 Oct 2021 at 18:52, Vladislav Zavialov 
wrote:

> Hi Alan,
>
> Your pair of functions can be packaged up as a single function, so that
>
> getEpa :: a -> EpaLocation
> setEpa :: a -> EpaLocation -> a
>
> becomes
>
> lensEpa :: forall f. Functor f => (EpaLocation -> f EpaLocation)
> -> (a -> f a)
>
> And the get/set parts can be recovered by instantiating `f` to either
> Identity or Const.
>
> The nice thing about lenses is that they compose, 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 2021, at 20:40, Alan & Kim Zimmerman 
> wrote:
> >
> > 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 :: (Monad m, Monoid w)
> >   => EpAnn a -> (a -> EpaLocation) -> (a -> EpaLocation -> a) ->
> AnnKeywordId -> EP w m (EpAnn a)
> >
> > which gets an annotation, a function to pull a specific location out,
> and one to update it.
> >
> > I do not know much about lenses, but have a feeling that I could
> simplify things by using one.
> >
> > Can anyone give me any pointers?
> >
> > Alan
> >
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Optics?

[Alan & Kim Zimmerman]

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 :: (Monad m, Monoid w)
  => EpAnn a -> (a -> EpaLocation) -> (a -> EpaLocation -> a) ->
AnnKeywordId -> EP w m (EpAnn a)

which gets an annotation, a function to pull a specific location out, and
one to update it.

I do not know much about lenses, but have a feeling that I could simplify
things by using one.

Can anyone give me any pointers?

Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: value of documenting error messages?

[Alan & Kim Zimmerman]

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 just an index into something else, you will either copy/paste it,
or click on it.

Alan

On Wed, 2 Jun 2021 at 20:16, Jakob Brünker  wrote:

> For what it's worth, there is an existing proposal about this topic, maybe
> that's the right place to discuss it for a user-focused perspective.
>
> See https://github.com/ghc-proposals/ghc-proposals/pull/325
>
> Jakob
>
> On Wed, Jun 2, 2021 at 9:10 PM Tom Ellis <
> tom-lists-haskell-cafe-2...@jaguarpaw.co.uk> wrote:
>
>> On Wed, Jun 02, 2021 at 07:03:25PM +, Richard Eisenberg wrote:
>> > > To me this seems like a rare opportunity to do something where people
>> > > will say "Hey look, that formidable Haskell compiler is doing
>> > > something that's friendlier than the equivalent in any other
>> > > compiler!".  For such an important user-facing feature I don't
>> > > understand why we're not asking users what they prefer.
>> >
>> > I agree completely here! Let's ask! (Remember that this thread,
>> > posted to ghc-devs, was originally about documenting the GHC source
>> > code, something that would not affect users.)
>>
>> Yes indeed.  Let's one of us start a user-focused thread elsewhere
>> (whoever gets round to it first) and post a link here so interested
>> parties here can join in.
>>
>> Tom
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Errors in haddock git fetch

[Alan & Kim Zimmerman]

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':
> 'refs/remotes/origin/wip/hsyl20/dynflags/exception' exists; cannot create
> 'refs/remotes/origin/wip/hsyl20/dynflags'
>
> This one is because I've removed some of my wip branches already merged
> upstream. Their names were conflicting with a new branch name
> (wip/hsyl20/dynflags).
>
> I forgot that everyone fetches every /wip branch so now it conflicts for
> everyone... I need to remember to remove the branch when !5845 will be
> merged.
>
> > Should I worry?
>
> No. The submodule seems to be checked out correctly even with the error.
>
> Sylvain
>
> PS: I still think we shouldn't have that many wip branches in the main
> repositories (cf
> https://mail.haskell.org/pipermail/ghc-devs/2019-February/017031.html)
>
>
> On 27/05/2021 15:40, Simon Peyton Jones via ghc-devs wrote:
>
> I’m getting these errors from `git submodule update`.  Should I worry?
>
> Simon
>
>
>
> From https://gitlab.haskell.org/ghc/haddock
>
> * [new branch]
> az/T19834->
> origin/az/T19834
>
> * [new branch]
> az/T19834-2  ->
> origin/az/T19834-2
>
> * [new branch]
> az/T19845->
> origin/az/T19845
>
> * [new branch]
> az/T19845-2  ->
> origin/az/T19845-2
>
> * [new branch]
> az/T19845-3  ->
> origin/az/T19845-3
>
> * [new branch]
> dependabot/npm_and_yarn/haddock-api/resources/html/hosted-git-info-2.8.9 ->
> origin/dependabot/npm_and_yarn/haddock-api/resources/html/hosted-git-info-2.8.9
>
> * [new branch]
> dependabot/npm_and_yarn/haddock-api/resources/html/lodash-4.17.21->
> origin/dependabot/npm_and_yarn/haddock-api/resources/html/lodash-4.17.21
>
> * [new branch]
> dn/dn-driver-refactor-and-split  ->
> origin/dn/dn-driver-refactor-and-split
>
>b4e7407b..c7281407  ghc-9.2
>-> origin/ghc-9.2
>
>dabdee14..4f9088e4
> ghc-head ->
> origin/ghc-head
>
> * [new branch]
> wip/T18389-task-zero ->
> origin/wip/T18389-task-zero
>
> + 7d27ea7a...3b6a8774
> wip/T19720   ->
> origin/wip/T19720  (forced update)
>
> + fe35fed3...40ba457f
> wip/adinapoli-align-ps-messages  ->
> origin/wip/adinapoli-align-ps-messages  (forced update)
>
> * [new branch]
> wip/dn-driver-refactor-and-split ->
> origin/wip/dn-driver-refactor-and-split
>
> error: cannot lock ref 'refs/remotes/origin/wip/hsyl20/dynflags':
> 'refs/remotes/origin/wip/hsyl20/dynflags/exception' exists; cannot create
> 'refs/remotes/origin/wip/hsyl20/dynflags'
>
> ! [new branch]
> wip/hsyl20/dynflags  ->
> origin/wip/hsyl20/dynflags  (unable to update local ref)
>
> * [new branch]
> wip/hsyl20/uncpp ->
> origin/wip/hsyl20/uncpp
>
> Unable to fetch in submodule path 'utils/haddock'; trying to directly
> fetch 4f9088e4b04e52ca510b55a78048c9230537e449:
>
> Submodule path 'utils/haddock': checked out
> '4f9088e4b04e52ca510b55a78048c9230537e449'
>
> simonpj@MSRC-3645512:~/code/HEAD-7$
>
> ___
> ghc-devs mailing 
> listghc-devs@haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

[Alan & Kim Zimmerman]

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 add
>
> > instance Semigroup (Bag a) where
> >   (<>) = unionBags
> >
> > instance Monoid (Bag a) where
> >   mempty = emptyBag
>
> to GHC.Data.Bag.
>
> The downside to writing these is that users might be tempted to write e.g.
> mempty instead of emptyBag, while the latter gives more information to
> readers and induces less manual type inference (to a human reader). The
> upside is that it means Bags work well with Monoid-oriented functions, like
> foldMap.
>
> I favor adding them, and slipped them into !5509 (a big commit with lots
> of other stuff). Alfredo rightly wondered whether this decision deserved
> more scrutiny, and so I'm asking the question here.
>
> What do we think?
>
> Thanks,
> Richard
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC Exactprint merge process

[Alan & Kim Zimmerman]

Thanks Richard

This MR is a huge change,  and hard to digest.  But it is also a step
function,  in that we cannot have the old way of using API Annotations for
exact printing and the new way at the same time.

So I have focused on making sure that it can actually do what I believe is
required, which I am satisfied it now does.   Admittedly this needs to be
more clearly defined. I am happy to do that,  and to tweak the
implementation based on feedback.  There are plenty of rough spots, as I
have been working on the big picture at the expense of polished details.

And I do appreciate the willingness to merge now and then clean up, this
will make my life a lot simpler,  I have rebased 50 odd times already.

Regards
  Alan


On Fri, 12 Mar 2021, 22:21 Richard Eisenberg,  wrote:

> After a consult with Simon, I've updated the relevant wiki page at
> https://gitlab.haskell.org/ghc/ghc/-/wikis/api-annotations with a sketch
> of a design description for this new feature, along with lots of questions.
> Both Simon and I agree that it may be more sensible to merge first and ask
> questions later, but we do think the design could be tightened in a few
> places.
>
> There are no notifications etc on wiki page updates, so it might be good
> to also correspond via email when updates take place.
>
> Richard
>
> On Mar 11, 2021, at 6:48 PM, Richard Eisenberg  wrote:
>
> I've started a review, but sent along what I had when dinner was ready.
> Hopefully more later, but don't wait up for me!
>
> Incidentally: this is a monstrous patch, and so there is a strong
> incentive just to get on with it without resolving all these quibbles. I
> won't stand in your way on that front -- it might be better to improve this
> after it lands. However, I also see quite a few TODO:AZ notes. Are you
> intending to fix these before landing? Or do you think it's OK to merge
> first and then return?
>
> High level piece: I'm in support of this direction of movement -- I just
> want to make sure that the new code is understandable 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 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 release, and
> it needs to be reviewed to be able to land.  But the change is huge, as it
> mechanically affects most files that interact with the GHC AST.
>
> So I have split out a precursor !5158 [3] with just the new types that are
> used to represent the annotations, so it can be a focal point for
> discussion.
>
> It is ready for review, please comment if you have time and interest.
>
> Regards
>   Alan
>
> [1] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2418
> [2] https://gitlab.haskell.org/ghc/ghc/-/issues/17638
> [3] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5158
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

GHC Exactprint merge process

[Alan & Kim Zimmerman]

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 release, and
it needs to be reviewed to be able to land.  But the change is huge, as it
mechanically affects most files that interact with the GHC AST.

So I have split out a precursor !5158 [3] with just the new types that are
used to represent the annotations, so it can be a focal point for
discussion.

It is ready for review, please comment if you have time and interest.

Regards
  Alan

[1] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2418
[2] https://gitlab.haskell.org/ghc/ghc/-/issues/17638
[3] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5158
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: MR template text

[Alan & Kim Zimmerman]

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] https://github.com/haskell/haskell-language-server/issues/new


On Tue, 23 Feb 2021 at 21:21, Richard Eisenberg  wrote:

> I'm happy with this direction, though I don't think we should expect that
> even capital letters will actually make people notice the text. One small
> change to suggest, below:
>
> On Feb 23, 2021, at 11:14 AM, Simon Peyton Jones via ghc-devs <
> ghc-devs@haskell.org> wrote:
>
> *Proposed new template*
> PLEASE REPLACE ALL OF THIS TEXT with a description of your merge request,
> including
>
> * A description of what the Merge Request does.  For a single-commit MR, a
> copy of the
>   commit message is often perfect.
>
> * A reference (e.g. #19415) to the ticket that led to this MR, and that
> describes the
>   problem that this MR solves.  Almost all MRs need a ticket, except the
> tiniest
>   changes (e.g. code formatting)
>   - A ticket describes a *problem*
>   - A merge request describes a *solution* to that problem.
>
> While you are encouraged to write a good MR Description, it’s not
> compulsory.
> You could just be putting up the MR to share with a colleague, for example.
>
> But if you want (a) to get code reviews from others, or
> (b) to land the patch in GHC,
> please do follow these guidelines.
>
>
> If you are not ready for wide review, please start the MR name with the
> prefix "WIP:", for "work in progress".
>
>
> For general style guidance see
> https://gitlab.haskell.org/ghc/ghc/wikis/commentary/coding-style
>
>
>
> Richard
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Lexing / Parsing and final token

[Alan & Kim Zimmerman]

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 comment after the '}' and then more blank lines, the
> last token is a comment.
>
> If no curlies, it is a ITsemi for the last location, after the comment.
>
> So my hacky scheme of using ITsemi as the means to track the last gap is
> not viable.
>
> And I don't want to put extra housekeeping on every token to track two
> tokens back, not just one. Back to the drawing board.
>
> Thanks
>   Alan
>
>
> On Tue, 19 Jan 2021 at 21:59, Richard Eisenberg  wrote:
>
>> So, I think there's your answer: the last token might be ITccurly, not
>> ITsemi. It seems that the "insert invisible curlies 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
>> x = 5
>> y = 6
>>
>> Gives a last token of ITsemi.
>>
>> Alan
>>
>> On Tue, 19 Jan 2021 at 21:50, Richard Eisenberg  wrote:
>>
>>> That's bizarre. Does it still happen with explicit braces?
>>>
>>> Just to test, 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 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 from the
>>> last token in the file to the EOF.  I guess technically it is the second
>>> last token.
>>> >
>>> > Empirically (calling getTokenStream), it seems this is always ITsemi.
>>> I am not sure how this comes about, as the `module` parsing rule in
>>> Parser.y ends with body or body2, and those both finish with an actual or
>>> virtual '}'.
>>> >
>>> > Can I rely on the token before ITEof always being ITsemi?
>>> >
>>> > Alan
>>> > ___
>>> > ghc-devs mailing list
>>> > ghc-devs@haskell.org
>>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>>
>>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Lexing / Parsing and final token

[Alan & Kim Zimmerman]

And if there is a comment after the '}' and then more blank lines, the last
token is a comment.

If no curlies, it is a ITsemi for the last location, after the comment.

So my hacky scheme of using ITsemi as the means to track the last gap is
not viable.

And I don't want to put extra housekeeping on every token to track two
tokens back, not just one. Back to the drawing board.

Thanks
  Alan


On Tue, 19 Jan 2021 at 21:59, Richard Eisenberg  wrote:

> So, I think there's your answer: the last token might be ITccurly, not
> ITsemi. It seems that the "insert invisible curlies 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
> x = 5
> y = 6
>
> Gives a last token of ITsemi.
>
> Alan
>
> On Tue, 19 Jan 2021 at 21:50, Richard Eisenberg  wrote:
>
>> That's bizarre. Does it still happen with explicit braces?
>>
>> Just to test, 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 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 from the
>> last token in the file to the EOF.  I guess technically it is the second
>> last token.
>> >
>> > Empirically (calling getTokenStream), it seems this is always ITsemi.
>> I am not sure how this comes about, as the `module` parsing rule in
>> Parser.y ends with body or body2, and those both finish with an actual or
>> virtual '}'.
>> >
>> > Can I rely on the token before ITEof always being ITsemi?
>> >
>> > Alan
>> > ___
>> > ghc-devs mailing list
>> > ghc-devs@haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Lexing / Parsing and final token

[Alan & Kim Zimmerman]

Changing it to remove the final ';' gives a last token of ITccurly.

Changing it to

module Bug where
x = 5
y = 6

Gives a last token of ITsemi.

Alan

On Tue, 19 Jan 2021 at 21:50, Richard Eisenberg  wrote:

> That's bizarre. Does it still happen with explicit braces?
>
> Just to test, 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 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 from the
> last token in the file to the EOF.  I guess technically it is the second
> last token.
> >
> > Empirically (calling getTokenStream), it seems this is always ITsemi.  I
> am not sure how this comes about, as the `module` parsing rule in Parser.y
> ends with body or body2, and those both finish with an actual or virtual
> '}'.
> >
> > Can I rely on the token before ITEof always being ITsemi?
> >
> > Alan
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Lexing / Parsing and final token

[Alan & Kim Zimmerman]

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 from the last
token in the file to the EOF.  I guess technically it is the second last
token.

Empirically (calling getTokenStream), it seems this is always ITsemi.  I am
not sure how this comes about, as the `module` parsing rule in Parser.y
ends with body or body2, and those both finish with an actual or virtual
'}'.

Can I rely on the token before ITEof always being ITsemi?

Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

HsPragTick

[Alan & Kim Zimmerman]

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 (HsPragE _ HsPragTick{} (L pos e0)) = do
e2 <- allocTickBox (ExpBox False) False False (locA pos) $
addTickHsExpr e0
return $ unLoc e2

So if it is used at all, the contents are ignored.

Can it be removed?

Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC 9.0?

[Alan & Kim Zimmerman]

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!
> >
> I'm afraid not. Quick Look will need to wait for 9.2.
>
> Cheers,
>
> - Ben
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: in-tree API Annotations

[Alan & Kim Zimmerman]

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
> 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 points for the annotations, being separate from
> the AST and indexed to it by the SrcSpan.
>
> I am intending to strip out the superfluous ones, in particular all the
> (Located RdrName), replacing them with something like
>
>   data ApiAnnName a = N ApiAnn a
>
> instead. So they would still be wrapped, but the annotations would be only
> ones that can occur for a RdrName, such a backticks, parens, and so on.
>
> Does anything actually need these locations now they are there?  I am
> thinking specifically of the .hie files, as the `toHie` instances seem to
> make use of locations extensively.
>
> Regards
>   Alan
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

in-tree API Annotations

[Alan & Kim Zimmerman]

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 points for the annotations, being separate from the
AST and indexed to it by the SrcSpan.

I am intending to strip out the superfluous ones, in particular all the
(Located RdrName), replacing them with something like

  data ApiAnnName a = N ApiAnn a

instead. So they would still be wrapped, but the annotations would be only
ones that can occur for a RdrName, such a backticks, parens, and so on.

Does anything actually need these locations now they are there?  I am
thinking specifically of the .hie files, as the `toHie` instances seem to
make use of locations extensively.

Regards
  Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Inclusion of the parser refactor in 8.12

[Alan & Kim Zimmerman]

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 patch
> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2377 could be
> included in 8.12. Right now we have a few issues that Ormolu users have
> reported which stem from how Haddocks are parsed by GHC (e.g. that issue
> when a file starts with haddock it must have a module header). I originally
> planned to work on those myself, but today I discovered that Vlad is
> already working on it.
>
> Best,
>
> Mark
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Extension.hs ForallXXX constraints

[Alan & Kim Zimmerman]

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
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposed changes to merge request workflow

[Alan & Kim Zimmerman]

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 ghc-devs, in that the maintainers have
> GHC as their day job. It would explicitly invite email from folks
> struggling to figure out how to contribute. I don't mean to create more
> mail for Ben et al, but having an explicit "seek help here" direction is
> nice. And (at least for me) mailing a list for help feels more comfortable
> than emailing an individual.
>
> Richard
>
> On Nov 8, 2019, at 6:30 PM, Ben Gamari  wrote:
>
> Simon Peyton Jones via ghc-devs  writes:
>
> |  If the maintainers are not willing to either review or find reviewers
> |  for a new contributors patch
> |  then it doesn't seem to me that a project wants or values new
> |  contributors.
>
> Yes, that would be an unfortunate -- and indeed wrong -- impression to
> convey.  Thanks for highlighting it.
>
> You'd like the maintainers to have an *obligation* to cause someone to
> produce a good review on every patch. Here's the worst-case scenario: a
> well-meaning but inexperienced person produces a stream of large,
> ill-thought-out, and mostly wrong patches.  To give a guarantee of high
> quality reviews of those patches amounts to a blank cheque on the time of
> volunteers working mostly in their spare time.
>
> Now, of course, that's an extreme scenario.  But that's why I'm keen to
> avoid making it an unconditional obligation that the few maintainers must
> discharge.
>
> I don’t think there is really a difference of opinion here.  Of course we
> welcome patches; of course everyone will try to help find reviewers if they
> are lacking!
>
> So how about this
> - the author nominates reviewers
> - if he or she finds difficulty in doing so, or the reviewers s/he
>  nominates are unresponsive, then he or she should ask for help
> - maintainers should make efforts to help
>
> In my mind there has always been a (perhaps too implicit) promise that
> maintainers are always present in the background and happy to help in
> finding reviewers if asked (and perhaps even if not, if it seems a
> contributor is lost).
>
> Perhaps we should make this more explicit?
>
> Cheers,
>
> - Ben
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How to navigate around the source tree?

[Alan & Kim Zimmerman]

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
tags\021084:mkHsParPV ./parser/RdrHsSyn.hs 2154
```

This gives the full path, and emacs is happy.
And of course in this example mkHsParPV does in fact have multiple
definitions, it is a class method.

Alan

On Thu, 24 Oct 2019 at 12:48, Andreas Klebinger 
wrote:

> Hello devs,
>
> I also often jump to files. In my case usually using VS Code using Ctr+P
> as well which searches for files by name.
> While I can check which folder a file is in in the case of duplicates it
> is a overhead which this refactor forces onto me.
>
> While there are workarounds, both for my case as for Matts. It's worth
> asking if requiring these workarounds is better
> than just accepting redundant prefixes on module names.
>
> Personally I would prefer unique file names even at the cost of redundancy.
> I rarely add import statements/full module names, but I *very* often jump
> to files.
>
> Cheers
> Andreas
>
> Bryan Richter schrieb am 23.10.2019 um 18:00:
>
> Duplicate record fields is going to make this a bigger problem. Vim does
> support duplicate tags (:tselect and :tjump and related bindings), but
> hopefully haskell-ide-engine will one day provide us with semantic tags and
> solve this problem once and for all!
>
> On Wed, 23 Oct 2019, 17.49 Matthew Pickering, 
> wrote:
>
>> Thanks Omer, Sylvain and Sebastian
>>
>> .
>>
>> I just configured my editor to use fzf and now I can use the `:GFiles`
>> command to perform fuzzy search on files which is probably better than
>> tags. If anyone else is using NixOS, all I had to do was add the
>> `fzf-vim` plugin to the vim configuration.
>>
>> Cheers,
>>
>> Matt
>>
>> On Wed, Oct 23, 2019 at 2:54 PM Ömer Sinan Ağacan 
>> wrote:
>> >
>> > I use a file finder (fzf) for jumping to files. Because module names
>> follow file
>> > paths to jump to e.g. StgToCmmUtils.Utils I usually type
>> `stgcmmutils` and
>> > fzf finds the correct file `compiler/GHC/StgToCmm/Utils.hs`.
>> >
>> > When generating tags I omit module names for this reason, it's easy
>> with a good
>> > file finder to jump to modules already, no need to generate tags for the
>> > modules.
>> >
>> > fast-tags commands I use:
>> >
>> > - When working on the compiler:
>> >
>> >   $ fast-tags --no-module-tags driver ghc compiler
>> >
>> > - When working on the RTS:
>> >
>> >   $ fast-tags --no-module-tags driver ghc compiler
>> >   $ ctags --append -R rts/**/*.c rts/**/*.h includes/**/*.h
>> >
>> > - When working on the libraries:
>> >
>> >   $ fast-tags --no-module-tags driver ghc compiler libraries
>> >
>> > Ömer
>> >
>> > Sebastian Graf , 23 Eki 2019 Çar, 16:49 tarihinde
>> > şunu yazdı:
>> > >
>> > > FWIW, I'm using VSCode's fuzzy file search with Ctrl+P (and vim's
>> equivalent) rather successfully. Just tried it for Hs/Utils.hs by typing
>> 'hsutils.hs'. It didn't turn up as the first result in VSCode, but it in
>> vim.
>> > >
>> > > Am Mi., 23. Okt. 2019 um 14:27 Uhr schrieb Matthew Pickering <
>> matthewtpicker...@gmail.com>:
>> > >>
>> > >> I use `fast-tags` which doesn't look at the hierarchy at all and I'm
>> > >> not sure what the improvement would be as the names of the modules
>> > >> would still clash.
>> > >>
>> > >> If there is some other recommended way to jump to a module then that
>> > >> would also work for me.
>> > >>
>> > >> Matt
>> > >>
>> > >>
>> > >> On Wed, Oct 23, 2019 at 12:08 PM Sylvain Henry 
>> wrote:
>> > >> >
>> > >> > Hi,
>> > >> >
>> > >> > How do you generate your tags file? It seems to be a shortcoming
>> of the
>> > >> > generator to not take into account the location of the definition
>> file.
>> > >> >
>> > >> >  > Perhaps `HsUtils` and `StgUtils` would be appropriate to
>> > >> > disambiguate`Hs/Utils` and `StgToCmm/Utils`.
>> > >> >
>> > >> > We are promoting the module prefixes (`Hs`, `Stg`, `Tc`, etc.) into
>> > >> > proper module layers (e.g. `HsUtils` becomes `GHC.Hs.Utils`) so it
>> would
>> > >> > be redundant to add the prefixes back. :/
>> > >> >
>> > >> > Cheers,
>> > >> > Sylvain
>> > >> >
>> > >> > On 23/10/2019 12:52, Matthew Pickering wrote:
>> > >> > > Hi,
>> > >> > >
>> > >> > > The module rework has broken my workflow.
>> > >> > >
>> > >> > > Now my tags file is useless for jumping for modules as there are
>> > >> > > multiple "Utils" and "Types" modules. Invariable I am jumping to
>> the
>> > >> > > wrong one. What do other people do to avoid this?
>> > >> > >
>> > >> > > Can we either revert these changes or give these modules unique
>> names
>> > >> > > to facilitate that only reliable way of navigating the code base.
>> > >> > > Perhaps `HsUtils` and `StgUtils` would be appropriate to
>> disambiguate
>> > >> > > `Hs/Utils` and `StgToCmm/Utils`.
>> > >> > >
>> > >> > > Cheers,

Re: Urgent: git problem

[Alan & Kim Zimmerman]

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 October 2019 17:22
> *To:* ghc-devs 
> *Subject:* Urgent: git problem
>
>
>
> Aieee!   All my GHC repos are failing with this.  As a result I can’t
> pull.  What should I do?   Thanks!
>
> Simon
>
>
>
> git pull
>
> error: cannot lock ref 'refs/remotes/origin/wip/rae/remove-tc-dep': 
> 'refs/remotes/origin/wip/rae'
> exists; cannot create 'refs/remotes/origin/wip/rae/remove-tc-dep'
>
> From gitlab.haskell.org:ghc/ghc
>
> ! [new branch]wip/rae/remove-tc-dep->
> origin/wip/rae/remove-tc-dep  (unable to update local ref)
>
> error: cannot lock ref 'refs/remotes/origin/wip/rae/split-up-modules':
> 'refs/remotes/origin/wip/rae' exists; cannot create
> 'refs/remotes/origin/wip/rae/split-up-modules'
>
> ! [new branch]wip/rae/split-up-modules ->
> origin/wip/rae/split-up-modules  (unable to update local ref)
>
> simonpj@MSRC-3645512:~/code/HEAD-2$
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 8.6.4 is now available

[Alan & Kim Zimmerman]

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 know.
>
> Cheers,
> Tamar
>
> On Tue, Mar 5, 2019, 21:47 Ben Gamari  wrote:
>
>> Phyx  writes:
>>
>> > Hi Ben,
>> >
>> > Thanks for the release! I was wondering, any reason for the no i386
>> Windows?
>> > Should I just create the package without it or is it coming?
>> >
>> This is one configuration I haven't yet had a chance to CI-ify. I was
>> hoping it would be missed but since you mention it I've gone ahead and
>> put up an attempt at fixing this (!495 [1]). It will likely take a few
>> iterations to get right but I'll try to get it sorted by the end of the
>> week.
>>
>> Cheers,
>>
>> - Ben
>>
>>
>> [1] https://gitlab.haskell.org/ghc/ghc/merge_requests/495
>>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Marge has been stabilised

[Alan & Kim Zimmerman]

> 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 day (if there are ever any for GHC dev), a
lone merge
will languish until someone else puts forward a valid merge too?

Or will marge just merge a non-batched lone merge request?

Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [GHC DevOps Group] Welcome to GitLab!

[Alan & Kim Zimmerman]

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
>discussed. Let me know if you have any trouble.
>
>Also, please do verify the correctness of the email address
>associated with your Trac account in the next few weeks. It will
>be used to map users when we transition Trac tickets to GitLab.
>
>
>
> Hello everyone,
>
> I am happy to announce that CI on GHC's GitLab instance [1] is now
> stable. At this point https://gitlab.haskell.org/ghc/ghc.git is to be
> considered the official upstream repository of GHC.
>
> The rest of this email is meant to serve as a brief introduction and
> status update. It can also be viewed on the GitLab Wiki [2].
>
> [1] https://gitlab.haskell.org/
> [2] https://gitlab.haskell.org/ghc/ghc/wikis/welcome
>
>
> # Getting started
>
> To get started on GitLab you will first want to either create a new account
> [1] or login with your GitHub credentials [2].
>
> Once you have an account you should add an SSH key [3] so that you can push
> to your repositories. If you currently have commit rights to GHC notify me
> (Ben Gamari) of your user name so I can grant you similar rights in GitLab.
>
>
> [1] https://gitlab.haskell.org/users/sign_in
> [2] https://gitlab.haskell.org/users/auth/github
> [3] https://gitlab.haskell.org/profile/keys
>
>
> # Updating your development environment
>
> You can updated existing working directory (assuming the usual upstream
> remote name of `origin`) for the new upstream repository location by
> running the following:
>
> git remote set-url origin https://gitlab.haskell.org/ghc/ghc.git
> git remote set-url --push origin g...@gitlab.haskell.org:ghc/ghc
>
> This is all that should be necessary; a quick `git pull origin master`
> should verify that everything is working as expected.
>
>
> # Continuous integration
>
> Continuous integration is now provided by GitLab's native continuous
> integration infrastructure. We currently test a variety of
> configurations, including many that neither Phabricator nor
> CircleCI/Appveyor previously tested (see [1] for an example run):
>
>  * With the make build system:
> * x86_64/Linux on Fedora 27, Debian 8, and Debian 9
> * i386/Linux on Debian 9
> * aarch64/Linux on Debian 9 (currently broken due to a variety of
>   issues)
> * x86_64/Windows
> * x86_64/Darwin
> * x86_64/Linux on Debian 9 in a few special configurations:
> * unregisterised (still a bit fragile due to #16085)
> * integer-simple
> * building GHC with -fllvm
>  * With Hadrian:
> * x86_64/Linux on Debian 9
> * x86_64/Windows (currently broken due to #15950)
>
> We also run a slightly larger set of jobs on a nightly basis. Note that
> binary distributions are saved from most builds and are available for
> download for a few weeks (we may put in place a longer retention policy
> for some builds in the future).
>
> There are admittedly a few kinks that we are still working out,
> particularly in the case of Windows (specifically the long build times
> seen on Windows). If you suspect you are seeing spurious build failures
> do let us know.
>
> To make the best use of our limited computational resources our CI
> builds occur in three stages:
>
>  * lint: the style and correctness checkers which would previously be
>run by `arc lint` and `git push`
>
>  * build: Debian 9 Linux x86_64 built with make and Hadrian
>
>  * full-build: the remaining configurations
>
> If a build fails at an earlier phase no further phases will be run.
>
>
> [1] https://gitlab.haskell.org/ghc/ghc/pipelines/568
>
>
> # Structuring your merge request
>
> With the transition to GitLab GHC is moving to a model similar to that
> used by GitHub. If you have a Differential on Phabricator we will finish
> review there. However, please post new patches as merge requests on
> GitLab.
>
> Note that Phabricator and GitLab have quite different models for
> handling patches. Under Phabricator a Differential is a single patch
> with no further structure; larger changes can be composed of multiple
> dependent Differentials.
>
> Under GitLab's model a merge request is a git branch consisting of
> one or more patches. Larger changes can be handled in one of two ways:
>
>  a. a set of dependent merge requests, each of which to be squashed when
> merged.
>
>  b. a single branch with each atomic change made in a single, buildable
> commit
>
> Due to the difficulty of maintaining dependent merge requests, I would
> recommend that contributors making larger changes use method (b).
>
>
> # Submitting your merge request for review
>
> Depending upon whether you have push rights to the GHC repository there
> are two ways to submit a merge request:
>
>  * if you have 

Re: [GHC DevOps Group] The future of Phabricator

[Alan & Kim Zimmerman]

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 means that we can address any shortcomings it may have
over time.

Alan

On Sat, 3 Nov 2018 at 12:59, Simon Marlow  wrote:

> On Fri, 2 Nov 2018 at 08:59, Herbert Valerio Riedel 
> wrote:
>
>> On 2018-11-02 at 08:13:37 +, Simon Marlow wrote:
>>
>> > I suppose we can do a squash-merge when committing to keep the history
>> > clean, but then contributors have a choice - either do GitHub-style
>> > where you add commits to a PR to update it and we squash on merge, OR
>> > Phabricator-style where you keep the same set of commits and rebase
>> > the stack to update it.
>> [..]
>>
>> Well, if MRs are to be squashed on merge anyway, I'm definitely not
>> going to waste my time carefully grooming a stack of atomic individually
>> validating commits via git-rebase-interactive...
>>
>
> Sorry I wasn't very clear. We would *only* squash if the author had been
> using the workflow where they add commits to revise the MR. If the author
> wants to use the stacked-diff-like workflow where they keep a groomed set
> of commits in the MR, then we would rebase and fast-forward the MR.
>
> My concern here is that we have two different workflows. People used to
> GitHub would want to use one, and people used to Phabricator would want to
> use the other. We have to check which workflow people are using so that we
> can decide whether to squash on merge or not.
>
> Ben said:
>
> > This shouldn't be a problem. One can easily configure a project such
> that users are *only* allowed to fast-forward/rebase, disallowing the
> creation of merge commits.
>
> but that doesn't fully address the problem, because the series of commits
> that would get rebased onto master would include all the commits added to
> the MR to update it during the review process. Actually what we wanted to
> do in this case was squash, not rebase+fast-forward.
>
> If there was a nice way to guide people into using the Phabricator-style
> workflow, I think that would help a lot.
>
> Cheers
> Simon
>
>
>
>>
>> > If you want to do dependent commits then you have to use Phabricator
>> > style. Choices between workflows make things more complicated for
>> > contributors, and that worries me.
>>
>> ...submitting a stacked set of commits as invidual overlapping MRs
>> (i.e. where the first MR has only the first commit, the 2nd has the
>> first two commits from the stack, and so on) -- if that's what you're
>> referring to as "Phabricator-style" -- sounds like an awkward workflow
>> to me.
>>
>> > Does GitLab keep the history of a PR after it has been updated, like in
>> > Phabricator? So we can see what happened between versions of a PR?
>>
>> I wonder too how this is represented in GitLab... especially when a MR
>> is comprised of multiple commits, and those individual commits evolve,
>> might get reordered, commits added or removed fromt he stack, or when
>> the whole MR gets rebased in the process...
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Parser.y rewrite with parser combinators

[Alan & Kim Zimmerman]

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 modifying happy, and requires minimal changes to the
existing Parser.y.

It would be unfortunate if this possibility was prevented by this rewrite.

Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: TTG hsSyn for Batch and Interactive Parsing

[Alan & Kim Zimmerman]

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*
>
> *else WihoutsApiAnnotations)*
>
>
We could conceptually have

  parser :: DynFlags -> String -> Either (HsSyn (Parsed
WithApiAnnotations)) (HsSyn (Parsed NoApiAnnotations))

The main point is that the next phase can make use of either of the
variants.

And it may be simplest to just always use the annotations, the ParsedSource
is normally discarded after renaming anyway.

Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: TTG hsSyn for Batch and Interactive Parsing

[Alan & Kim Zimmerman]

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 fully incremental, in the sense that
it would process as input the prior parse tree and a list of changes to the
source, and then generate a fresh parse tree, with the changed nodes
marked.  This mode would be tightly coupled to an external too like
haskell-ide-engine, to manage the bookkeeping around this.

My thinking for this is to use the approach presented in the paper
"Efficient and Flexible Incremental Parsing" by Wagner and Graham[1].
The plan is to modify `happy`, so that we can reuse the existing GHC
Parser.y with minor modifications. This is the same approach as used in the
library tree-sitter[2], which is a very active project on github.

WIP is at [3], but it is very early stage.

Regards
  Alan


[1] https://pdfs.semanticscholar.org/4d22/fab95c78b3c23fa9dff88fb82976ed
c213c2.pdf
[2] https://github.com/tree-sitter/tree-sitter
[3] https://github.com/alanz/happy/tree/incremental
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: TTG hsSyn for Batch and Interactive Parsing

[Alan & Kim Zimmerman]

I have updated the Wiki.

On 9 May 2018 at 10:15, Simon Peyton Jones <simo...@microsoft.com> wrote:

> Thanks.
>
>
>
> I am absolutely behind this objective:
>
> I propose to move the API Annotations to where they belong, inside the AST.
>
> Indeed I thought that was always part of the TTG plan.
>
>
>
> *But I don’t understand what this has to do with interactive vs batch
> parsing.  *Why don’t you unconditionally retain API-annotation info?  How
> would GhcPs be used differently to GhcPsI?
>
>
>
> You might want to answer by clarifying 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...@microsoft.com>
> *Cc:* ghc-devs <ghc-devs@haskell.org>
> *Subject:* Re: TTG hsSyn for Batch and Interactive Parsing
>
>
>
> I have started a wiki page at https://ghc.haskell.org/trac/ghc/wiki/
> ImplementingTreesThatGrow/IdeSupport
>
>
>
> On 8 May 2018 at 10:54, Simon Peyton Jones <simo...@microsoft.com> wrote:
>
> At first blush, “running the parser in two modes” and “changing the Pass”
> type don’t match up in my 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 Behalf Of *Alan & Kim
> Zimmerman
> *Sent:* 07 May 2018 16:17
> *To:* ghc-devs <ghc-devs@haskell.org>
> *Subject:* 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 changing the types in HsExtension to introduce
> a 'Process'  type as follows
>
> data Pass = Parsed Process | Renamed | Typechecked
>  deriving (Data)
>
> data Process = Batch | Interactive
>   deriving (Show, Data)
>
> We then rename the pass synonyms so that batch is the default
>
> type GhcPs   = GhcPass ('Parsed 'Batch)
> type GhcPsI  = GhcPass ('Parsed 'Interactive)
>
> I have attached a simple proof of concept file, which emulates parsing and
> renaming.
>
> Is this an appropriate approach to take?
>
> Alan
>
>
>
> [1] Trees That Grow https://ghc.haskell.org/trac/ghc/wiki/
> ImplementingTreesThatGrow
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: TTG hsSyn for Batch and Interactive Parsing

[Alan & Kim Zimmerman]

I have started a wiki page at
https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/IdeSupport

On 8 May 2018 at 10:54, Simon Peyton Jones <simo...@microsoft.com> wrote:

> At first blush, “running the parser in two modes” and “changing the Pass”
> type don’t match up in my 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 Behalf Of *Alan & Kim
> Zimmerman
> *Sent:* 07 May 2018 16:17
> *To:* ghc-devs <ghc-devs@haskell.org>
> *Subject:* 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 changing the types in HsExtension to introduce
> a 'Process'  type as follows
>
> data Pass = Parsed Process | Renamed | Typechecked
>  deriving (Data)
>
> data Process = Batch | Interactive
>   deriving (Show, Data)
>
> We then rename the pass synonyms so that batch is the default
>
> type GhcPs   = GhcPass ('Parsed 'Batch)
> type GhcPsI  = GhcPass ('Parsed 'Interactive)
>
> I have attached a simple proof of concept file, which emulates parsing and
> renaming.
>
> Is this an appropriate approach to take?
>
> Alan
>
>
>
> [1] Trees That Grow https://ghc.haskell.org/trac/ghc/wiki/
> ImplementingTreesThatGrow
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

TTG hsSyn for Batch and Interactive Parsing

[Alan & Kim Zimmerman]

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 changing the types in HsExtension to introduce
a 'Process'  type as follows

data Pass = Parsed Process | Renamed | Typechecked
 deriving (Data)

data Process = Batch | Interactive
  deriving (Show, Data)

We then rename the pass synonyms so that batch is the default

type GhcPs   = GhcPass ('Parsed 'Batch)
type GhcPsI  = GhcPass ('Parsed 'Interactive)

I have attached a simple proof of concept file, which emulates parsing and
renaming.

Is this an appropriate approach to take?

Alan


[1] Trees That Grow https://ghc.haskell.org/trac/ghc/wiki/
ImplementingTreesThatGrow
{-# LANGUAGE DeriveDataTypeable #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE StandaloneDeriving #-}
-- Next two needed for the Show instances
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE UndecidableInstances #-}

import Data.Data hiding ( Fixity )

main :: IO ()
main = putStrLn "hello"


data NoExt = NoExt
  deriving (Data,Eq,Ord,Show)

-- | Used as a data type index for the hsSyn AST
data GhcPass (c :: Pass)
deriving instance Eq (GhcPass c)
deriving instance Typeable c => Data (GhcPass c)

data Pass = Parsed Process | Renamed | Typechecked
 deriving (Data)

data Process = Batch | Interactive
  deriving (Show, Data)

-- Type synonyms as a shorthand for tagging
type GhcPs   = GhcPass ('Parsed 'Batch)
type GhcPsI  = GhcPass ('Parsed 'Interactive)
type GhcRn   = GhcPass 'Renamed
type GhcTc   = GhcPass 'Typechecked
type GhcTcId = GhcTc

-- | Maps the "normal" id type for a given pass
type family IdP p
type instance IdP (GhcPass ('Parsed _)) = RdrName
type instance IdP GhcRn = Name
type instance IdP GhcTc = Id

data RdrName = RdrName String deriving Show
data Name= Name Stringderiving Show
data Id  = Id String  deriving Show

-- -


data AST p = AST (XAST p) [Decl p]

deriving instance (Show (XAST p),Show (XD p), Show (IdP p)) => Show (AST p)

type family   XAST p
type instance XAST GhcPs  = NoExt
type instance XAST GhcPsI = Int
type instance XAST GhcRn  = NoExt
type instance XAST GhcTc  = NoExt

data Decl p = D (XD p) (IdP p)
deriving instance (Show (XD p), Show (IdP p)) => Show (Decl p)

type family   XD p
type instance XD GhcPs  = NoExt
type instance XD GhcPsI = Int
type instance XD GhcRn  = NoExt
type instance XD GhcTc  = NoExt

-- -

parseBatch :: String -> AST GhcPs
parseBatch str = AST NoExt [D NoExt (RdrName str)]

parseInteractive :: String -> AST GhcPsI
parseInteractive str = AST 1 [D 2 (RdrName str)]

rename :: AST (GhcPass ('Parsed p)) -> AST GhcRn
rename (AST _ ds) = AST NoExt ds'
  where
ds' = map rn ds
rn (D _ (RdrName s)) = (D NoExt (Name s))

i s = rename $ parseInteractive s
b s = rename $ parseBatch s
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Eight GHC projects for Google Summer of Code

[Alan & Kim Zimmerman]

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 Hadrian -
> https://summerofcode.withgoogle.com/projects/#4778106259243008
> Alanas Plascinskas - Depecating Exports -
> https://summerofcode.withgoogle.com/projects/#4906802404130816
> Simon Jakobi - HI Haddock -
> https://summerofcode.withgoogle.com/projects/#4975710121230336
> Abhiroop Sarkar - SIMD Improvements -
> https://summerofcode.withgoogle.com/projects/#5641742712307712
> Ningning Xie - Dependently Typed Core Replacement in GHC -
> https://summerofcode.withgoogle.com/projects/#5851493949767680
> Andreas Klebinger - Codegen of Conditional Constructs -
> https://summerofcode.withgoogle.com/projects/#5953351515111424
> Shayan Najd - Native-Metaprogramming Reloaded -
> https://summerofcode.withgoogle.com/projects/#6085694691213312
> Zubin Duggal - Making GHC Tooling friendly -
> https://summerofcode.withgoogle.com/projects/#6509299262554112
>
> I am sure that some names will already be familiar but please look out
> for questions and patches from these eight students over the next few
> months.
>
> Looking forward to seeing everyone on the mailing list and in #ghc!
>
> Cheers,
>
> Matt
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Type family constraints

[Alan & Kim Zimmerman]

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] http://lpaste.net/365181
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Type family constraints

[Alan & Kim Zimmerman]

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?

instance (p ~ GhcPass pass, OutputableBndrId p)
   => Outputable (HsIPBinds p) where


This comes from a problem where setting each type family instance
separately does not get picked up during instance resolution (and can't be,
according to earlier questions by me on this)

i.e.

type instance XIPBinds   (GhcPass 'Parsed) = NoExt
type instance XIPBinds   (GhcPass 'Renamed) = NoExt
type instance XIPBinds   (GhcPass 'Typechecked) = TcEvBinds

it works fine for

type instance XIPBinds   (GhcPass _) = NoExt

Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

HsVectInstIn is dead code?

[Alan & Kim Zimmerman]

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 the
comments?)

Alan

[1] https://github.com/ghc/ghc/search?utf8=%E2%9C%93=HsVectInstIn=
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [GHC] #14490: TTG Snags

[Alan & Kim Zimmerman]

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 |Owner:  (none)
> Type:  bug   |   Status:  new
> Priority:  normal|Milestone:
>Component:  Compiler  |  Version:  8.3
>   Resolution:| Keywords:
> Operating System:  Unknown/Multiple  | Architecture:
>  |  Unknown/Multiple
>  Type of failure:  None/Unknown  |Test Case:
>   Blocked By:| Blocking:
>  Related Tickets:  #14482|  Differential Rev(s):
>Wiki Page:|
>   ImplementingTreesThatGrow  |
> -+--
> ---
>
> Comment (by Shayan-Najd):
>
>  > So making a Data instance per concrete version may be the best way to
>  go. Plan B.
>
>  Regardless of the GHC version we use, the question is whether Plan B
>  really fixes the build-time problem. Can we test it?
>
> --
> Ticket URL: 
> GHC 
> The Glasgow Haskell Compiler
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Trees that Grow and constraints

[Alan & Kim Zimmerman]

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
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Trees that Grow and constraints

[Alan & Kim Zimmerman]

Will do

Alan

On 13 November 2017 at 19:08, Simon Peyton Jones <simo...@microsoft.com>
wrote:

> Alan (adding Shayan and ghc-devs)
>
>
>
> 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.
>
>
>
> 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
>
>
>
> At the moment, in GHC master, we have
>
> data HsOverLit p
>
>   = OverLit {
>
>   ol_ext :: (XOverLit p),
>
>   ol_val :: OverLitVal,
>
>   ol_witness :: HsExpr p} -- Note [Overloaded literal witnesses]
>
>
>
>   | XOverLit
>
>   (XXOverLit p)
>
> deriving instance (DataIdLR p p) => Data (HsOverLit p)
>
>
>
> And in HsExtension.hs we have an ever-growing constraint type defining 
> DataIdLR
>
> I am trying to remove the need for that.
>
> In the Experiment.hs file, I found that using
>
> data Experiment p
>   = Experiment {
>   e_ext :: (XEOverLit p),
>   e_val :: Int }
>   | XExperiment (XXOverLit p)
> deriving instance Data (GhcPass 'Parsed ) => Data (Experiment (GhcPass 
> 'Parsed ))
> deriving instance Data (GhcPass 'Renamed) => Data (Experiment (GhcPass 
> 'Renamed))
> deriving instance Data (GhcPass 'Typechecked) => Data (Experiment (GhcPass 
> 'Typechecked))
>
> will compile using GHC 8.2.1, but not with GHC 8.0.2
>
>
>
> Alan
>
>
>
> On 13 November 2017 at 15:13, Simon Peyton Jones <simo...@microsoft.com>
> wrote:
>
> And it looks like it could work, when bootstrapping from GHC 8.2.1, but
> this is still a long time away.
>
>
>
> I’m sorry, I still don’t know what “it” is that “could work”.  Can you be
> more precise.  I think you must be suggesting some alternative to my code
> below?
>
>
>
> Simon
>
>
>
> *From:* Alan & Kim Zimmerman [mailto:alan.z...@gmail.com]
> *Sent:* 13 November 2017 13:09
>
>
> *To:* Simon Peyton Jones <simo...@microsoft.com>
> *Subject:* Re: Trees that Grow and constraints
>
>
>
> Yes.
>
>
>
> If we can solve this, it means we can get rid of the DataId and ForallXXX
> constraints defined in hsSyn/HsExtension.hs
>
>
>
> And also move the type family definitions to the files where they are used.
>
>
>
> I suspect that typechecking those constraint sets is adding to the GHC
> compilation time, significantly
>
>
>
> And it looks like it could work, when bootstrapping from GHC 8.2.1, but
> this is still a long time away.
>
>
>
> Alan
>
>
>
> On 13 November 2017 at 15:05, Simon Peyton Jones <simo...@microsoft.com>
> wrote:
>
> That’s not a problem you are trying to solve – it’s just some code .
>
>
>
> Let me hazard a guess.  You want a derived instance for
>
>
>
> Data (OverLit (GhcPass p))
>
>
>
> But to do that of course we’ll need  Data (XEOverLit (GhcPass p)).
>
>
>
> We can’t possibly have that at the time of writing the instance
> declaration, because p is universally quantified.  So we are stuck with
>
>
>
> instance (Data (XEOverLit (GhcPass p))) => Data (OverLit
> (GhcPass p)) where…
>
>
>
> and the context gets a constraint for every extension field in OverLit,
> which is painful.
>
>
>
> So we have a solution bit contexts, but it’s painful.
>
>
>
> Is that the problem you are trying to solve?
>
>
>
> Simon
>
>
>
> *From:* Alan & Kim Zimmerman [mailto:alan.z...@gmail.com]
> *Sent:* 13 November 2017 13:01
> *To:* Simon Peyton Jones <simo...@microsoft.com>
>
> *Subject:* Re: Trees that Grow and constraints
>
>
>
> Sorry, I simplified the problem.
>
> The actual one I am trying to solve will be the general case, so e.g.
>
>  type instance XEOverLit (GhcPass 'Parsed ) = RdrName
>  type instance XEOverLit (GhcPass 'Renamed) = Name
>  type instance XEOverLit (GhcPass 'Typechecked) = Id
>
> or more likely, modelling the existing PostTc and PostRn usages.
>
> And I suppose looking into using them in a single definition might work
>
> Alan
>
>
>
>
>
> On 13 November 2017 at 14:55, Simon Peyton Jones <simo...@microsoft.com>
> wrote:
>
> Or do I misunderstand your advice?
>
>
>
> Well, you said
>
> Where specifying the type instance with a wild card keeps GH

Re: Trees that Grow and constraints

[Alan & Kim Zimmerman]

Just to clarify, this example is a simplification, in practice we would be
applying different type for each type instance

e.g.

type instance XEOverLit (GhcPass 'Parsed ) = PlaceHolder
type instance XEOverLit (GhcPass 'Renamed) = PlaceHolder
type instance XEOverLit (GhcPass 'Typechecked) = 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.
>
> 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
>
> ---
> data Experiment p
>   = Experiment {
>   e_ext :: (XEOverLit p),
>   e_val :: Int }
>   | XExperiment (XXOverLit p)
> deriving instance (Data (GhcPass p)) => Data (Experiment (GhcPass p))
>
> type family XEOverLit  x
> type family XXOverLit x
>
> -- The following line works
> -- type instance XEOverLit (GhcPass _) = PlaceHolder
>
> -- The following 3 lines do noe
> type instance XEOverLit (GhcPass 'Parsed ) = PlaceHolder
> type instance XEOverLit (GhcPass 'Renamed) = PlaceHolder
> type instance XEOverLit (GhcPass 'Typechecked) = PlaceHolder
>
> type instance XXOverLit (GhcPass _) = PlaceHolder
> ---
>
> Where specifying the type instance with a wild card keeps GHC happy (the
> XXOverLit case), but specifying for each of the three constructors for pass
> does not (the XEOverLit case)
>
> The exact error message is
>
> --
> Experiment.hs:34:1: error:
> • Could not deduce (Data (XEOverLit (GhcPass p)))
> arising from a use of ‘k’
>   from the context: Data (GhcPass p)
> bound by the instance declaration at Experiment.hs:34:1-69
> • In the first argument of ‘k’, namely ‘(z Experiment `k` a1)’
>   In the expression: ((z Experiment `k` a1) `k` a2)
>   In an equation for ‘gfoldl’:
>   gfoldl k z Experiment a1 a2 = ((z Experiment `k` a1) `k` a2)
>   When typechecking the code for ‘gfoldl’
> in a derived instance for ‘Data (Experiment (GhcPass p))’:
> To see the code I am typechecking, use -ddump-deriv
>|
> 34 | deriving instance (Data (GhcPass p)) => Data (Experiment (GhcPass p))
>| ^
> --
>
> Alan
>
> [1] http://lpaste.net/360017
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Trees that Grow and constraints

[Alan & Kim Zimmerman]

> 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 XEOverLit (GhcPass 'Typechecked) = PlaceHolder

apply.

Or do I misunderstand your advice?

Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Trees that Grow and constraints

[Alan & Kim Zimmerman]

And it seems that

--
data Experiment p
  = Experiment {
  e_ext :: (XEOverLit p),
  e_val :: Int }
  | XExperiment (XXOverLit p)
deriving instance (Data GhcPs) => Data (Experiment GhcPs)
deriving instance (Data GhcRn) => Data (Experiment GhcRn)
deriving 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 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
>
> ---
> data Experiment p
>   = Experiment {
>   e_ext :: (XEOverLit p),
>   e_val :: Int }
>   | XExperiment (XXOverLit p)
> deriving instance (Data (GhcPass p)) => Data (Experiment (GhcPass p))
>
> type family XEOverLit  x
> type family XXOverLit x
>
> -- The following line works
> -- type instance XEOverLit (GhcPass _) = PlaceHolder
>
> -- The following 3 lines do noe
> type instance XEOverLit (GhcPass 'Parsed ) = PlaceHolder
> type instance XEOverLit (GhcPass 'Renamed) = PlaceHolder
> type instance XEOverLit (GhcPass 'Typechecked) = PlaceHolder
>
> type instance XXOverLit (GhcPass _) = PlaceHolder
> ---
>
> Where specifying the type instance with a wild card keeps GHC happy (the
> XXOverLit case), but specifying for each of the three constructors for pass
> does not (the XEOverLit case)
>
> The exact error message is
>
> --
> Experiment.hs:34:1: error:
> • Could not deduce (Data (XEOverLit (GhcPass p)))
> arising from a use of ‘k’
>   from the context: Data (GhcPass p)
> bound by the instance declaration at Experiment.hs:34:1-69
> • In the first argument of ‘k’, namely ‘(z Experiment `k` a1)’
>   In the expression: ((z Experiment `k` a1) `k` a2)
>   In an equation for ‘gfoldl’:
>   gfoldl k z Experiment a1 a2 = ((z Experiment `k` a1) `k` a2)
>   When typechecking the code for ‘gfoldl’
> in a derived instance for ‘Data (Experiment (GhcPass p))’:
> To see the code I am typechecking, use -ddump-deriv
>|
> 34 | deriving instance (Data (GhcPass p)) => Data (Experiment (GhcPass p))
>| ^
> --
>
> Alan
>
> [1] http://lpaste.net/360017
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Trees that Grow and constraints

[Alan & Kim Zimmerman]

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

---
data Experiment p
  = Experiment {
  e_ext :: (XEOverLit p),
  e_val :: Int }
  | XExperiment (XXOverLit p)
deriving instance (Data (GhcPass p)) => Data (Experiment (GhcPass p))

type family XEOverLit  x
type family XXOverLit x

-- The following line works
-- type instance XEOverLit (GhcPass _) = PlaceHolder

-- The following 3 lines do noe
type instance XEOverLit (GhcPass 'Parsed ) = PlaceHolder
type instance XEOverLit (GhcPass 'Renamed) = PlaceHolder
type instance XEOverLit (GhcPass 'Typechecked) = PlaceHolder

type instance XXOverLit (GhcPass _) = PlaceHolder
---

Where specifying the type instance with a wild card keeps GHC happy (the
XXOverLit case), but specifying for each of the three constructors for pass
does not (the XEOverLit case)

The exact error message is

--
Experiment.hs:34:1: error:
• Could not deduce (Data (XEOverLit (GhcPass p)))
arising from a use of ‘k’
  from the context: Data (GhcPass p)
bound by the instance declaration at Experiment.hs:34:1-69
• In the first argument of ‘k’, namely ‘(z Experiment `k` a1)’
  In the expression: ((z Experiment `k` a1) `k` a2)
  In an equation for ‘gfoldl’:
  gfoldl k z Experiment a1 a2 = ((z Experiment `k` a1) `k` a2)
  When typechecking the code for ‘gfoldl’
in a derived instance for ‘Data (Experiment (GhcPass p))’:
To see the code I am typechecking, use -ddump-deriv
   |
34 | deriving instance (Data (GhcPass p)) => Data (Experiment (GhcPass p))
   | ^
--

Alan

[1] http://lpaste.net/360017
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

[Alan & Kim Zimmerman]

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 arises please do open a ticket.
>>
>
> Yep, will do...
>
>
>> Yes, I have opened a differential adding such a flag. See D4164 [1].
>> Please bikeshed to taste.
>>
>
> Thanks for the quick fix!
>
>
>> In general I would really prefer that we *not* consider GHCi's REPL to be
>> a stable programmatic interface.
>
>
> I fully understand that, and that's definitely the way to go.
> Nevertheless, parsing tool/compiler output is still one of the most used
> hacks^H^H^H techniques for lots of Emacs modes (and probably other IDEs).
> Not every project is as open to suggestions and changes as GHC is, so this
> is often the only way out.
>
>
>> That being said, we cannot always preemptively add complexity to the
>> project out of fear that a given change might break a hypothetical
>> mechanical consumer.
>
>
> That's of course not what was proposed. :-)
>
>
>> GHCi is first-and-foremost a REPL for users.
>> When evaluating a change, if we feel it is likely that we will break a
>> mechanical user then we will likely guard the change with a flag.
>> However, if not, we won't.
>>
>
> I think the main problem here was communication. I can't speak for the
> haskell-mode maintainers, but for my part I didn't notice the problems
> because I mainly use LTS Stackage and that is still(!) at 8.0.2 (Why? This
> is definitely part of the whole problem.). I tried the 8.2 series only
> sparingly and only via the command line, so this is perhaps what others
> did, too, so the interaction bug went unnoticed for such a long time.
>
> Cheers,
>Sven
>
> ___
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: forall in constraint

[Alan & Kim Zimmerman]

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   x thing)
   , c (XNewImplicitBndrs x thing)
   )

This gets used, in the same file as

type LSigType   x = ImplicitBndrs x (LType x)

where `thing` is resolved to a specific type.

Because it is all in the same file, there is no problem making a
constraint on anything using LSigType, that mentions LHsType.



But in the approach I am taking[2], the type families are defined in
HsExtension, which is compiled early in the cycle, and imported by
HsTypes, HsBinds, HsDecl etc.

In order to derive a Data instance for anything using `LSigType x`, we
need to be able to specify that a Data instance exists for `LHsType x`.

So we can either do that directly in HsBinds, or try to add it to the
existing
DataId constraint in HsExtension.

The first approach leads to a spread of the constraint throughout the AST,
which gets very messy.

The second approach requires being able to specify a
`forall thing. Data thing` constraint in HsExtension.


I tried an intermediate approach, introducing a constraint in HsDecls[3] to
capture this,
but it eventually runs into needing it in the HsExpr.hs-boot file, which
means I need
LHsType in that file.

Perhaps the simplest way forward is to get rid of the `thing` parameter
completely,
and introduce the three or so ImplicitBinders variants that are used.

I hope this does not just confuse things even more.

Alan

[1]
https://github.com/ghc/ghc/blob/wip/GrowableAST/compiler/hsSyn/AST.hs#L475
[2] https://github.com/ghc/ghc/tree/wip/ttg/2017-10-21
[3]
https://github.com/ghc/ghc/commit/22812296818fe955752fa4762cf72250abd09bf9#diff-7cfa6eef12e44d312aca9ef4af0081b3R1439



On 23 October 2017 at 23:04, Simon Peyton Jones 
wrote:

> I’m lost. Could you give me a bit more context?
>
>
>
> I’m deeply suspicious about that ForallXImplicitBndrs thing with strange
> higher kinded parameters.   Smells all wrong to me.
>
>
>
> Simon
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

forall in constraint

[Alan & Kim Zimmerman]

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 thing)
   )

and I want to extend the DataId constraint

type DataId p =
  ( Data p

  , ForallXImplicitBndrs Data p thing
  )

But the problem is I do not have `thing` at this point, and to get it in
the code will involve some hs-boot nastiness.

Is there any way to require "forall thing. Data thing" inside the DataId
constraint?

Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Wildcards in HsTypes

[Alan & Kim Zimmerman]

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 wildcard during renaming

And only ever used in

data HsType pass
  ...
  | HsWildCardTy (HsWildCardInfo pass)

Why not just do

  | HsWildCardTy  (PostRn pass (Located Name))

?

Am I missing something?

Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

haddock specializeInstHead

[Alan & Kim Zimmerman]

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 -> InstHead GhcRn

But the entire module is polymorphic in the AST parameter, so it has the
following instead

specializeInstHead :: (Ord (IdP name), DataId name, SetName (IdP name),
NamedThing (IdP name))
   => InstHead name -> InstHead name

Question: does it need to be so polymorphic?

I am hitting issues getting the type parameter change worked through, and
it seems a bit pointless to slog on with it if it is unnecessary.

Alan

[1] https://github.com/ghc/ghc/tree/wip/ttg-2017-10-13
[2]
https://github.com/haskell/haddock/blob/a5bdb46185b7c0b3fced9a7fac9a62883d9d57b7/haddock-api/src/Haddock/Interface/Specialize.hs#L87
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Phab: conditional approval

[Alan & Kim Zimmerman]

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 them.

Tested ACK - Reviewed the code changes and have verified the
functionality or bug fix.

ACK - A loose ACK can be confusing. It's best to avoid them unless
it's a documentation/comment only change in which case there is
nothing to test/verify; therefore the tested/untested distinction is
not there.

NACK - Disagree with the code changes/concept. Should be accompanied
by an explanation.



[1] https://github.com/bitcoin/bitcoin/issues/6100

Alan

On 14 September 2017 at 18:37, Richard Eisenberg 
wrote:

> Yes, this works for me.
>
> As for merging, I'm always very grateful when Ben does it -- though I
> agree that it would make more sense for me to do it when I can
> test-then-merge.
>
> Thanks,
> Richard
>
>
> > On Sep 13, 2017, at 10:29 AM, Ben Gamari  wrote:
> >
> > Simon Marlow  writes:
> >
> >> On 19 August 2017 at 03:56, Richard Eisenberg 
> wrote:
> >>
> >>> Hi devs,
> >>>
> >>> When reviewing a diff on Phab, I can "accept" or "request changes".
> >>> Sometimes, though, I want to do both: I suggest very minor (e.g., typo)
> >>> changes, but then when these changes are made, I accept. I'm leery of
> >>> making the suggestions and saying "accept", because then someone
> working
> >>> quickly may merge without noticing the typos. Does Phab have such an
> option?
> >>>
> >>
> >> "Accept with nits" is standard practice, but you're right it can go
> wrong
> >> when someone else is merging accepted diffs.  We could adopt a standard
> >> comment keyword, e.g. "NITS" that indicates you'd like the nits to be
> fixed
> >> before committing, perhaps?
> >>
> > Sounds reasonable to me.
> >
> >
> >> Also, I don't think it's a good idea to merge commits when the author
> is a
> >> committer, they can land themselves.
> >>
> > I would be quite happy to not have to merge such patches; I merely merge
> > them currently since I thought it was generally expected.
> >
> > On the other hand, I generally do integration builds on the batches of
> > patches that I merge which can sometimes catch validation issues.
> > However, I expect this will be less of an issue with the
> > test-before-merge support in the pipeline.
> >
> > Cheers,
> >
> > - Ben
> >
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Operating on HsSyn

[Alan & Kim Zimmerman]

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
>
> (prettyPrint . parser . prettyPrint) = id
>
> for a valid input.
>
> Simplifying, (parser ∷ String → something), and (prettyPrint ∷ something
> → String).
>
> Therefore, (parser . prettyPrint . parser ∷ String → something) and 
> (prettyPrint
> . parser . prettyPrint ∷ something → String).
>
> Therefore, both criteria could only apply for (something ~ String). But
> as pretty printing adds quotation marks, not even that is true.
>
> There are four formulations that might be applicable:
>
>1.
>
>parser . prettyPrint ≍ id
>2.
>
>prettyPrint . parser ≍ id -- ∷ String → String, useless here
>3.
>
>prettyPrint . parser . prettyPrint ≍ prettyPrint
>4.
>
>parser . prettyPrint . parser ≍ parser
>5. Well, you could go beyond to (prettyPrint . parser . prettyPrint .
>parser ≍ prettyPrint . parser) etc…
>
> I don't think 1 (or 2) follow from one of the last two. But 1 does imply
> them. So it is a stronger criterion than both, and therefore probably not
> the one to choose. Assuming the parser is internally consistent, 3 just
> says something about the internal consistency of the pretty printer, while
> 4 says something about the relationship of the pretty printer to the
> parser. Thus 4 looks like the best candidate for a criterion. Possibly with
> 3 as a secondary target.
>
> Cheers,
> MarLinn
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposed: Language.Haskell.TH.Internal

[Alan & Kim Zimmerman]

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 an internal, non-user-facing restructuring of
> the implementation of Template Haskell. It's here (instead of at
> ghc-proposals) because it's not user-facing.
>
> When a user writes a TH quote [| foo bar baz |], GHC must desugar that
> into some Core code that builds a Q Exp. This is currently done by calling
> functions in Language.Haskell.TH.Lib, which is capable of building all the
> TH abstract syntax. However, many end-users of TH *also* import
> Language.Haskell.TH.Lib and use its functions. This means that, as the
> Haskell AST evolves, we can't reasonably evolve this Lib module, as it
> breaks user code. (There is a requisite amount of churn in TH, but we try
> to avoid gratuitous changes in Lib.) This has bitten in the past when we
> have, say, changed the representation of type families to accommodate
> closed type families, and it's biting now as we (ahem, Ryan Scott) are
> trying to merge types and kinds in TH.
>
> I thus propose a new module Language.Haskell.TH.Internal. This will start
> out as a slimmed-down copy of Lib (slimmed-down because Lib already has a
> bunch of now-disused functions) but may evolve independently. Desugaring
> quotes will go via this new Internal module, and we will have no qualms
> about changing its interface, as it's Internal.
>
> What do we think? Ryan has already implemented this idea in D3751.
>
> Pros:
>  - Flexibility
>  - Separation between user-facing interface and internal interface
>
> Cons:
>  - More stuff
>  - We already break the TH API with every release; maybe it's not so bad
> to break more of it.
>
> Thanks,
> Richard
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Removing Hoopl dependency?

[Alan & Kim Zimmerman]

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 wrote:
>
> [...]
>
> >> Stackage only allows one version of each package
> >
> > I didn’t know that, but I can see it makes sense.  That makes a strong
> > case for re-doing it as a new package hoopl2
>
> The limitations of Stackage's design shouldn't drive nor limit
> library design. Cabal has been moving to finally allow us to have
> multiple versions and even multiple configurations/instances of the same
> version of a package registered in the package db at the same time, and
> subjecting ourselves to Stackage's limitations after all the work done
> (and more in that direction is being considered to push the boundaries
> even further) to that effect *now* seems quite backward to me.
>
> If we push the idea to its conclusion, that we shall rather publish a
> new package rather than release a new major version of a package to
> workaround Stackage, you'd see a proliferation of number-suffixed
> packages on Hackage.  Moreover, packages which can easily support
> multiple major versions of a package would have to use conditional logic
> boilerplate in their .cabal files (which again would be incompatible
> with Stackage's inherent limitations, as it allows only *one
> configuration* of a given package version).
>
> We should build upon the facilities we already have in place; and major
> versions are here to encode the epoch/generation of an API; moreover, as
> a big advantage over classic SemVer, we also have this 2-component major
> version which gives us more flexibility for versioning during developing
> two or more epochs of an API in parallel. So hoopl-1.* and hoopl-2.*
> could keep evolving independently, each branch being able to perform
> major version increments in their respective version namespace.
>
> Cheers,
>   HVR
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Trees that Grow / D3609

[Alan & Kim Zimmerman]

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 diff).

Any current work in progress branches will need a one-time search and
replace of all type parameters as follows

RdrName  -> GhcPs
Name  -> GhcRs
Var -> GhcTc
Id -> GhcTcId


Any code that makes use of the GHC API and needs to compile with earlier
versions too can do something like

  #if MIN_VERSION_ghc(8,3,0)
  type ParseI = GhcPs
  type RenameI= GhcRn
  type TypecheckI = GhcTc
  #else
  type ParseI = RdrName
  type RenameI= Name
  type TypecheckI = Var
  #endif

and then replace the RdrName / Name / Var type params with ParseI / RenameI
/ TypecheckI.

A real world example is in ghc-exactprint[3]

Regards
  Alan

[1] https://phabricator.haskell.org/D3609
[2] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow
[3]
https://github.com/alanz/ghc-exactprint/commit/6a6e3cdeb40f9623e9a7fc6f1be90da981cb921b
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Interested to help with error messages

[Alan & Kim Zimmerman]

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,
and then specialise the GHC version to FastString etc.

Alan

On 3 June 2017 at 17:50, Ben Gamari  wrote:

>
> CCing,
>* Alfredo Di Napoli for his on-going work in this area
>* Shivansh Rai for his interest in contributing
>* David Luposchainsky for his recent pretty-printer library
>* Richard Eisenberg due to his participation in #8809
>* Bartosz for his participation in #10735
>* Alan Zimmerman for his interest in Haskell tooling
>
> My apologies for the tome that follows. I have been thinking about this
> problem recently and think an overview of where we stand would be helpful.
>
>
> Siddharth Bhat  writes:
>
> > Hello all,
> >
> > Thanks for all the work that's put into GHC :)
> >
> Thanks for your interest in helping!
>
> > I've tried to get into GHC development before, but I was unsuccessful,
> > mostly because I didn't dedicate enough time to understanding the problem
> > at hand & exploring the codebase.
> >
> > I'd like to give it another shot. This time, I think I have a clear
> vision
> > of what I want to help with: Have haskell's error messages be easier to
> > read and understand.
> >
> > 1. Colors and layout to highlight important parts of the error messages
>
> As I say below, I think #8809 will provide a good foundation for
> improvements here. More on this below.
>
> > 2. Clear formatting & naming of errors, so they're easily googleable,
> > stack-overflow able, etc.
>
> Indeed this is a great goal. Do you have a list of error messages that
> you think are particularly egregious in this respect? Are you advocating
> that we give error classes unique identifiers (e.g. as rustc does IIRC)
> or are you merely suggesting that we improve the wording of the existing
> messages?
>
> > 3. better hints with error messages, and perhaps integrated lints(?).
>
> This sounds like a noble goal, but it's a bit unclear how you get there.
> We currently do try to give hints where possible, but of course we could
> always offer more. It would be helpful to have a set of concrete
> examples to discuss.
>
> > 4. I don't know if this is already possible, but allowing GHC errors to
> be
> > shipped off as JSON or something to interested tooling.
> >
> Indeed, this would be great. Thanks to Matthew Pickering we already
> offer some limited form of this in 8.2 [1], but I think having more
> structured error documents as suggested in #8809 would make this even
> nicer.
>
> [1] https://downloads.haskell.org/~ghc/master/users-guide//
> debugging.html?highlight=json#ghc-flag--ddump-json
>
>
>
> The State of #8809
> ==
>
> > I saw this ticket on trac: https://ghc.haskell.org/trac/ghc/ticket/8809
> > I would like to take this up, but I'd like help / pointers and stuff. I
> > have GHC setup, I know how to use phabricator, but.. where do I start? :)
> >
> This ticket has recently seen quite a bit of activity and I've been
> meaning to write down some thoughts on it. Here it goes:
>
> Currently Alfredo Di Napoli is working [2] on the `pretty` library to
> both improve performance and allow us to drop GHC's fork (see #10735),
> perhaps to use annotated pretty-printer documents. Meanwhile, David
> Luposchainsky, has recently released [3] his `prettyprinter` library
> which may serve as a drop-in replacement to `pretty` and handles all of
> the cases that Alfredo is working on. Moreover, Shivansh Rai has also
> recently expressed interest in helping out with this effort.
>
> All of this is great news: I have been hoping we'd get Idris-style
> errors for quite some time. However, given how many hands we have in
> this area, we should be careful not to step on each toes. Below I'll
> describe the various facets of the task as I see them.
>
> [2] https://github.com/haskell/pretty/pull/43
> [3] https://www.reddit.com/r/haskell/comments/6e62i5/ann_
> prettyprinter_10_ending_the_wadlerleijen_zoo/
>
>
> # Choice of pretty printer
>
> It seems like we first need to resolve the question of whether switching
> from (our fork of) `pretty` to the `prettyprinter` library is
> worthwhile. The argument for moving to `prettyprinter` is its support
> for optimized infinite-band-width layout, which is one of the things
> holding us back from moving back to `pretty`.
>
> However, there are two impediments to switching,
>
>  * `prettyprinter` depends upon the `text` package while GHC does not.
>Making GHC dependent on `text` is an option, but we should be
>careful. Adding a dependency has a non-trivial cost (GHC build times
>rise, GHC API users are stuck using whatever dependency versions GHC
>uses, release engineering is a bit more complicated).
>
> 

Re: HsParTy

[Alan & Kim Zimmerman]

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
> pretty-printer, when we have HsCoreTy.
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: HsParTy

[Alan & Kim Zimmerman]

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
>
> Do you know why HsTypes.ppr_mono_ty contains any uses of ‘maybeParen’?
> Shouldn’t the parens all be put in by HsParTy?
>
> I tripped over this when I mistakenly added what I thought were missing
> maybeParen calls for HsAppTy and HsAppTys, but that was flagged as an error
> by a test in tests/printer.
>
> So why are there /any/ maybeParen calls?
>
> Simon
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Trees that Grow in the hsSyn AST

[Alan & Kim Zimmerman]

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 that

>I am supportive!

>
> Simon

We have set up a Wiki page at [2] describing a prototype implementation of
the first stage of this for the hsSyn AST, which is to change the
polymorphic variable from one of RdrName / Name / Id to an index type. This
is presented as a fabricator diff at [3].

Please take a look and provide feedback.

Regards
  Alan


[1]
http://www.jucs.org/jucs_23_1/trees_that_grow/jucs_23_01_0042_0062_najd.pdf
[2] https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow
[3] https://phabricator.haskell.org/D3609
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Type families and classes

[Alan & Kim Zimmerman]

And to answer my own question, it seems

instance HasSourceText SourceText where
  noSourceText= NoSourceText
  sourceText s= SourceText s
 getSourceText a = a


And then applying the appropriate constraint at the use-site does the job.

So

noSyntaxExpr :: (HasSourceText (XHsString x)) => 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
> 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
>
> type family XHsString x
>
> type instance XHsString GHCX = SourceText
>
> class HasSourceText a where
>   -- Provide setters to mimic existing constructors
>   noSourceText  :: a
>   sourceText:: String -> a
>
>   getSourceText :: a -> SourceText
>
> instance HasSourceText (XHsString GHCX) where
>   noSourceText= NoSourceText
>   sourceText s= SourceText s
>  getSourceText a = a
>
>
> But this gives an error
>
> compiler/hsSyn/HsExtension.hs:80:10: error:
> • Illegal type synonym family application in instance:
> XHsString GHCX
> • In the instance declaration for ‘HasSourceText (XHsString GHCX)’
>
> Is there some way to achieve this, or is it simply impossible?
>
> The full work-in-progress source is here[2]
>
> Regards
>   Alan
>
>
> [1] https://arxiv.org/abs/1610.04799
> [2] https://github.com/alanz/ghc/blob/df1c3b3d42284dd121086e6c571793
> f19e758977/compiler/hsSyn/HsExtension.hs#L73
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Type families and classes

[Alan & Kim Zimmerman]

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

type family XHsString x

type instance XHsString GHCX = SourceText

class HasSourceText a where
  -- Provide setters to mimic existing constructors
  noSourceText  :: a
  sourceText:: String -> a

  getSourceText :: a -> SourceText

instance HasSourceText (XHsString GHCX) where
  noSourceText= NoSourceText
  sourceText s= SourceText s
 getSourceText a = a


But this gives an error

compiler/hsSyn/HsExtension.hs:80:10: error:
• Illegal type synonym family application in instance:
XHsString GHCX
• In the instance declaration for ‘HasSourceText (XHsString GHCX)’

Is there some way to achieve this, or is it simply impossible?

The full work-in-progress source is here[2]

Regards
  Alan


[1] https://arxiv.org/abs/1610.04799
[2]
https://github.com/alanz/ghc/blob/df1c3b3d42284dd121086e6c571793f19e758977/compiler/hsSyn/HsExtension.hs#L73
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC 8.2.1-rc1 source tarball availability

[Alan & Kim Zimmerman]

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 building. The binary distributions will be announced one
>week from today.
>
> Hello GHC packagers,
>
> I am happy to announce the release of the 8.2.1-rc1 source distribution
> to binary packagers. You will find the usual source artifacts at
>
> http://downloads.haskell.org/~ghc/8.2.1-rc1/
>
> As usual, the sooner we can get the binary distributions together the
> better, but I will hold off on announcing the distributions until next
> Sunday to ensure we're all on the same page. It would be appreciated if
> you could reply to this message confirming that you intend to offer a
> binary distribution this release.
>
> Otherwise, let me know if you have any trouble building your
> distribution. I have yet to push the ghc-8.2.1-rc1 tag in case we
> encounter unexpected issues but all of my builds with this tarball
> thusfar have gone swimmingly save a few known issues (namely #13426,
> #13233, and #13509).
>
> Good luck and thanks for all of your work!
>
> Cheers,
>
> - Ben
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Why are there no Show instances for internal types

[Alan & Kim Zimmerman]

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 result in infinite
> output.
>
> Perhaps we can add a new type class which a) faithfully represents
> the Haskell syntax, but b) can deal with cyclic data.  I think that's
> something people would like (extra compilation time not withstanding).
> But it sounds annoying to do since the deriving mechanism is not going
> to help you.
>
> Edward
>
> Excerpts from Tom Sydney Kerckhove's message of 2017-03-18 14:03:48 +0100:
> > Dear GHC Devs,
> >
> > I am trying to use GHC as a library but I'm having a lot of trouble with
> > understanding what everything means.
> > Up to now, I have been able to figure out what to do by reading the
> > sources, but it ocured to me that much of my struggles could have been
> > mitigated if the relevant types had Show instances.
> >
> > I am specifically talking about the types concerning type checking.
> > TypecheckedModule and everything below that.
> > I am aware that most of the types have an Outputable instance, but
> > there are two problems with that:
> >
> > - 'Outputting' a value requires DynFlags. (yes, I know about pprTrace)
> > - These instances are not intended to show the internal structure of a
> >   value, but rather a 'human readable' representation of a value.
> >
> > My questions for you:
> >
> > - Is there a reason that there are no derived 'Show' instances for most
> >   types?
> > - Would you accept a diff that adds these?
> >
> > Thank you for your time.
> >
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Travis again over time

[Alan & Kim Zimmerman]

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:

> Hi,
>
> Am Dienstag, den 07.03.2017, 14:39 +0100 schrieb Joachim Breitner:
> > The build would be marked as passing if it were not for
> > integerConstantFolding which is marked as …
>
> fixed this issue. Travis should pass now again. Let’s keep it this way!
>
> Greetings,
> Joachim
>
> --
> Joachim “nomeata” Breitner
>   m...@joachim-breitner.de • https://www.joachim-breitner.de/
>   XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
>   Debian Developer: nome...@debian.org
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Disable messages with GHC API

[Alan & Kim Zimmerman]

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 looks like
> "parseModule" and so on overwrite the DynFlags with a cached version
> before running the relevant piece of the pipeline.
>
>  857hsc_env <- getSession
>  858let hsc_env_tmp = hsc_env { hsc_dflags = ms_hspp_opts ms }
>  859hpm <- liftIO $ hscParse hsc_env_tmp ms
>
>
> I think this is symptom of the fact that DynFlags is not very well
> structured and a lot of different compiler options are lumped
> together. It makes sense that we need to use the right DynFlags to run
> the module but this shouldn't overwrite things which are irrelevant
> like log_action.
>
> Matt
>
>
> On Fri, Feb 3, 2017 at 3:30 PM, Christopher Done 
> wrote:
> > Adding `handleSourceError` around it makes no difference.
> >
> > Which makes sense, as I don't think warnings count as exceptions,
> > otherwise my code would never have completed in the first place.
> >
> > On 3 February 2017 at 12:50, Matthew Pickering
> >  wrote:
> >> The errors are eventually caught and printed by "handleSourceError"
> >> which is used a few times in your code. You could either modify one of
> >> these to not print out any errors or try something more intelligent
> >> like is in `parUpsweep_one` which does use the `log_action` in order
> >> to print the errors out.
> >>
> >> On Fri, Feb 3, 2017 at 12:21 PM, Christopher Done 
> wrote:
> >>> In Intero, after loading modules, for each one I run the following
> >>> function: https://github.com/commercialhaskell/intero/blob/
> 300ac5a/src/GhciInfo.hs#L75..L85
> >>>
> >>> If there are warnings or any output, they get outputted. As they are
> >>> already outputted by regular :load, I don’t need the same output
> >>> twice.
> >>>
> >>> How do I disable non-severe output for any GhcMonad m => m a? I’m
> >>> using GHC 8.0.1 presently.
> >>>
> >>> I tried the following before calling getModInfo, expecting there to be
> >>> no output anymore:
> >>>
> >>> +  GHC.setSessionDynFlags
> >>> +df {log_action = \ref dflags severity srcSpan style msg ->
> return ()}
> >>>
> >>> And this had no effect. I tried some other things but ran out of
> >>> patience to keep a record of them all.
> >>>
> >>> Ciao!
> >>> ___
> >>> ghc-devs mailing list
> >>> ghc-devs@haskell.org
> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Cannot build GHC using the Newcomers guide

[Alan & Kim Zimmerman]

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 want to keep using your stage0 while working on
> ghc. As you don't want to break it and spend hours wondering why your build
> failed.
>
> Fair enough, if people want to do this. So long as it's not the defacto
> method.
>
> On Thu, 26 Jan 2017, 17:28 Matthew Pickering, 
> wrote:
>
>> I think the intention is that if you are already using stack to manage
>> your GHC installations then it is desirable to use their managed
>> version of GHC rather than have to install another version.
>>
>> It seems to me that the solution that Harendra suggests is the easiest
>> for anyone with this setup.
>>
>> Fwiw, the easiest way I found to setup a clean development environment
>> for GHC was to use the nix ghcHEAD derviation.
>>
>>nix-shell '' -A haskell.compiler.ghcHEAD
>>
>> but of course, this only works if you are using nix!
>>
>> Matt
>>
>> On Thu, Jan 26, 2017 at 5:18 PM, Phyx  wrote:
>> > Can I ask a silly question. I can't seem to find where stack is
>> recommended
>> > for ghc development on the newcomers page, but why is it? I don't want
>> to
>> > start another flame war but I can't imagine any scenario where this is
>> > useful. As far as I understand the whole benefit of stack is the curated
>> > packages.
>> >
>> > Which are moot here since almost everything you need is in the tree
>> aside
>> > from Happy and Alex. Seems to me this is just overcomplicating a very
>> simple
>> > process.
>> >
>> > Not to mention if you have to go through stack - - exec etc all for
>> > interactions with the build artifacts it would get old quickly. Also it
>> > doesn't seem reliable especially if stack is modifying the environment
>> and
>> > or flags passed to the compiler.
>> >
>> > Let me reiterate, I have nothing against stack, I just don't see the
>> > benefits here. Ideally you'd want your environment as simple and
>> vanilla as
>> > possible and *totally* in your control IMHO.
>> >
>> > What am I missing here?
>> >
>> > Thanks,
>> > Tamar
>> >
>> >
>> > On Thu, 26 Jan 2017, 14:21 Harendra Kumar, 
>> wrote:
>> >>
>> >> I use "export PATH=`stack path --bin-path`" to make the stack installed
>> >> ghc available in the PATH before building ghc. And that's all.
>> >>
>> >> Setting the PATH works better because we do not get any extra env
>> >> variables set by stack in the environment and we do not go through the
>> stack
>> >> wrapper, so it may be a little bit faster as well. The GHC_PACKAGE_PATH
>> >> variable set by the stack command is especially troublesome in some
>> cases.
>> >> You can try "stack exec env" to check all vars that stack puts in your
>> >> environment.
>> >>
>> >> -harendra
>> >>
>> >> On 26 January 2017 at 15:52, Marius Ghita  wrote:
>> >>>
>> >>> Following is a list of steps that I ran and their output linked:
>> >>>
>> >>>  - clone repo
>> >>> https://gist.github.com/mhitza/f5d4516b6c8386fe8e064f95b5ad620b
>> >>>  - build.mk configuration
>> >>> https://gist.github.com/mhitza/2d979c64a646bdd3e097f65fd650c675
>> >>>  - boot https://gist.github.com/mhitza/e23df8b9ed2aac5b1b8881c70165bf
>> 3f
>> >>>  - configure
>> >>> https://gist.github.com/mhitza/88c09179be3bb82024192bf6181aef13
>> >>>  - make FAILS
>> >>> https://gist.github.com/mhitza/95738bf49c8c87ce46c9319b4c266a2c
>> >>>
>> >>> I'm using a 'stack-ghc' executable, that's only a shell wrapper to run
>> >>> ghc from stack (since I don't have a globally installed ghc) (source
>> >>> https://gist.github.com/mhitza/38fe96fb440daab28e57a50de47863d5 ),
>> and I
>> >>> also have 'ghc-pkg' wrapped in the same way with
>> >>> a stack-ghc-pkg script (source
>> >>> https://gist.github.com/mhitza/6c2b1978ef802707161041abe1d2699e )
>> >>>
>> >>> --
>> >>> Google+: https://plus.google.com/111881868112036203454
>> >>>
>> >>> ___
>> >>> ghc-devs mailing list
>> >>> ghc-devs@haskell.org
>> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >>>
>> >>
>> >> ___
>> >> ghc-devs mailing list
>> >> ghc-devs@haskell.org
>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >
>> >
>> > ___
>> > ghc-devs mailing list
>> > ghc-devs@haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >
>>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Including remote-iserv upstream?

[Alan & Kim Zimmerman]

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
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Confused about the sub-modules

[Alan & Kim Zimmerman]

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  wrote:

> Once the commit is upstream, I just checkout a newer commit from
> master and then commit it as a submodule update. Maybe it's
> wrong but no one has ever told me otherwise.  Around release
> time the release manager makes sure all the libraries correspond to
> actual releases.
>
> Edward
>
> Excerpts from Erik de Castro Lopo's message of 2016-12-21 17:33:36 +1100:
> > Hi all,
> >
> > I'm a bit confused about how the GHC dev tree handles submodules like
> > libraries/Cabal, libraries/process, libraries/directory and
> > libraries/containers.
> >
> > All of these libraries/submodules seem to have their own github projects
> > where people can submit PRs, but once the commits have been made there,
> > what is the process to get submodules updated in the GHC tree?
> >
> > Any light people can shed on this process would be appreciated.
> >
> > Erik
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Reading source annotations during type checking

[Alan & Kim Zimmerman]

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  wrote:

> Alan, did you see this?
>
> Alejandro Serrano Mena  writes:
>
> > Dear GHC devs,
> > Is there a way to retrieve "source annotations" (as defined by
> > https://downloads.haskell.org/~ghc/latest/docs/html/users_
> guide/extending_ghc.html#source-annotations)
> > during type checking. In particular, I am interested in reading them in
> > TcExpr and TcCanonical.
> >
> > Regards,
> > Alejandro
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Fwd: [Ann] Haskell Ecosystem Proposals

[Alan & Kim Zimmerman]

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 Proposals
To: haskell <haskell-c...@haskell.org>


Earlier this year Simon Peyton Jones wrote about respect [1], and said

"It's worth separating two things

  1. Publicly debating an issue where judgements differ
  2. Using offensive or adversarial language in that debate"

There is now a repository[2]  for us as a community to have the first kind
of discussion about issues that affect the community as a whole.

The intention is that this becomes a neutral place where  discussion can
take place about coordinating the various services offered to the haskell
community.

This is partly to expose the thinking and constraints on a particular
approach, so proponents of other approaches can have a better understanding
of how things can evolve.

The idea is that through an honest understanding of the various parts we
can achieve consensus on how to improve things.

If this all sounds a bit handwavy, the first concrete example of this
approach is a pull request [3] discussing the management of implicit or
speculative version bounds between cabal-install/hackage and
stack/stackage.  This has reached a point where there is a clearer
understanding of the actual problem, and a viable solution must be agreed.

The structure of the repository is shamelessly copied from the one for GHC
proposals, so the actual process description is way off. It should probably
just state that we discuss until consensus is reached if possible, but that
we are always open for further discussion.

It is up to all of us to make this work.

Regards
  Alan

[1] https://mail.haskell.org/pipermail/haskell/2016-September/024995.html
[2] https://github.com/haskell/ecosystem-proposals
[3] https://github.com/haskell/ecosystem-proposals/pull/1
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Measuring performance of GHC

[Alan & Kim Zimmerman]

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 Terepeta 
wrote:

> Hi everyone,
>
> I've been running nofib a few times recently to see the effect of some
> changes
> on compile time (not the runtime of the compiled program). And I've started
> wondering how representative nofib is when it comes to measuring compile
> time
> and compiler allocations? It seems that most of the nofib programs compile
> really quickly...
>
> Is there some collections of modules/libraries/applications that were put
> together with the purpose of benchmarking GHC itself and I just haven't
> seen/found it?
>
> If not, maybe we should create something? IMHO it sounds reasonable to have
> separate benchmarks for:
> - Performance of GHC itself.
> - Performance of the code generated by GHC.
>
> Thanks,
> Michal
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Paren removal in renamer

[Alan & Kim Zimmerman]

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, but they are removed for the renamed
source.

I am modifying the pretty printer to be faithful to the original source, so
when the renamed source is printed it has no parens, causing T12530 to fail.

I have looked all over the source, and cannot see where the HsParTy is
removed.

Can anyone give me a pointer?

See details here [1]

My current work branch is here [2], but I am pretty sure there are no
changes affecting this there.

[1] http://lpaste.net/1624164315596587008
[2] https://github.com/alanz/ghc/tree/wip/T3384

Regards
  Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC pretty printer philosophy

[Alan & Kim Zimmerman]

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 the
generic deriving code to add parens.

Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

GHC pretty printer philosophy

[Alan & Kim Zimmerman]

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 required to
interpret the meaning of the type.

So the question is, should the default ppr faithfully reproduce the source
that was parsed to generate the given AST, or simplify it?

>From a round-tripping perspective I prefer the former, but there are other
use cases where the current behaviour is preferred.

If the original is preferred, it can perhaps be enabled via a flag to the
pretty printer, but before doing that I want to see if it actually matters.

Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: ppr of HsDo

[Alan & Kim Zimmerman]

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 putting in a test suite similar to the one for
> ghc-exactprint to ensure that the pretty printer always generates code that
> can be round tripped back to the original AST.
>
> This means that fears of some uncaught case requiring us do it the
> guaranteed safe way should be allayed.
>
> In the process I am updating the pretty printer.
>
> So the question really is, given the existence of that test suite, what
> style of code should we have in our messages, and in pretty printed code?
>
> Alan
>
>
> On Thu, Nov 10, 2016 at 12:02 PM, Simon Peyton Jones <
> simo...@microsoft.com> wrote:
>
>>
>>
>> It’s not about GHC’s programming style, is it?  It’s about what the
>> pretty-printer does.  If it were me I’d use braces and semicolons
>> everywhere, so that I could guarantee to parse it easily.
>>
>>
>>
>> But that’s not a strong opinion and I would willingly yield to others!
>>
>>
>>
>> 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.
>>
>> And any thoughts on my proposal to do away with the braces/semi
>> completely?  I suspect GHC is the only significant body of code that uses
>> that style still.
>>
>> Alan
>>
>>
>>
>> On Thu, Nov 10, 2016 at 10:24 AM, Simon Peyton Jones <
>> simo...@microsoft.com> wrote:
>>
>> I think it’s because the  “;” is treated as part of the let not part of
>> the do.  After all, how does the implicit layout of the let know that the
>> let-bindings are finished?
>>
>>
>>
>> This should work
>>
>>
>>
>> foo
>>   = do { let { x = 1 };
>>  Just 5 }
>>
>>
>>
>> Now the let bindings are clearly brought to an end.  Or this
>>
>>
>>
>> foo
>>   = do { let x = 1
>>
>>; Just 5 }
>>
>>
>>
>> Now the “’;” is to the left of the x=1 and so brings the let’s implicit
>> layout to an end.
>>
>>
>>
>> But not this!
>>
>>
>>
>> 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 2016 07:01
>> *To:* ghc-devs@haskell.org
>> *Subject:* 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 am not sure if there is a parser bug too.
>>
>> Alan
>>
>>
>>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: ppr of HsDo

[Alan & Kim Zimmerman]

For context, I am putting in a test suite similar to the one for
ghc-exactprint to ensure that the pretty printer always generates code that
can be round tripped back to the original AST.

This means that fears of some uncaught case requiring us do it the
guaranteed safe way should be allayed.

In the process I am updating the pretty printer.

So the question really is, given the existence of that test suite, what
style of code should we have in our messages, and in pretty printed code?

Alan


On Thu, Nov 10, 2016 at 12:02 PM, Simon Peyton Jones <simo...@microsoft.com>
wrote:

>
>
> It’s not about GHC’s programming style, is it?  It’s about what the
> pretty-printer does.  If it were me I’d use braces and semicolons
> everywhere, so that I could guarantee to parse it easily.
>
>
>
> But that’s not a strong opinion and I would willingly yield to others!
>
>
>
> 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.
>
> And any thoughts on my proposal to do away with the braces/semi
> completely?  I suspect GHC is the only significant body of code that uses
> that style still.
>
> Alan
>
>
>
> On Thu, Nov 10, 2016 at 10:24 AM, Simon Peyton Jones <
> simo...@microsoft.com> wrote:
>
> I think it’s because the  “;” is treated as part of the let not part of
> the do.  After all, how does the implicit layout of the let know that the
> let-bindings are finished?
>
>
>
> This should work
>
>
>
> foo
>   = do { let { x = 1 };
>  Just 5 }
>
>
>
> Now the let bindings are clearly brought to an end.  Or this
>
>
>
> foo
>   = do { let x = 1
>
>; Just 5 }
>
>
>
> Now the “’;” is to the left of the x=1 and so brings the let’s implicit
> layout to an end.
>
>
>
> But not this!
>
>
>
> 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 2016 07:01
> *To:* ghc-devs@haskell.org
> *Subject:* 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 am not sure if there is a parser bug too.
>
> Alan
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: ppr of HsDo

[Alan & Kim Zimmerman]

Thanks.

And any thoughts on my proposal to do away with the braces/semi
completely?  I suspect GHC is the only significant body of code that uses
that style still.

Alan


On Thu, Nov 10, 2016 at 10:24 AM, Simon Peyton Jones <simo...@microsoft.com>
wrote:

> I think it’s because the  “;” is treated as part of the let not part of
> the do.  After all, how does the implicit layout of the let know that the
> let-bindings are finished?
>
>
>
> This should work
>
>
>
> foo
>   = do { let { x = 1 };
>  Just 5 }
>
>
>
> Now the let bindings are clearly brought to an end.  Or this
>
>
>
> foo
>   = do { let x = 1
>
>; Just 5 }
>
>
>
> Now the “’;” is to the left of the x=1 and so brings the let’s implicit
> layout to an end.
>
>
>
> But not this!
>
>
>
> 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 2016 07:01
> *To:* ghc-devs@haskell.org
> *Subject:* 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 am not sure if there is a parser bug too.
>
> Alan
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

ppr of HsDo

[Alan & Kim Zimmerman]

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 am not sure if there is a parser bug too.

Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Compilation optimisation performance example - HaRe

[Alan & Kim Zimmerman]

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
user7m3.156s
sys0m4.504s

With -O0, the timing  for the same commands is

real0m36.427s
user 0m41.448s
sys 0m2.544s

So optimisation slows it down from 36 seconds to 7 minutes.

Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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

[Alan & Kim Zimmerman]

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: could you use color? Already, when I saw `b :: a` in the
> commentary there, where `b` is in scope as a type variable, it seemed wrong
> to me.
>
> In any case, I can answer your simpler question: yes, with some work, you
> can get from a tyvar to its provenance. A tyvar's Name will have its
> binding location in it. If you also keep track of binding locations as you
> spot foralls, you should be able to match them up. In theory.
>
> Richard
>
> On Oct 19, 2016, at 7:45 AM, Christopher Done  wrote:
>
> We've encountered a problem in Intero which is that when inspecting types
> of expressions and patterns, sometimes it happens that the type, when
> pretty printing, yields variables of the same name but which have different
> provenance.
>
> Here's a summary of the issue:
>
> https://github.com/commercialhaskell/intero/issues/280#
> issuecomment-254784904
>
> And a strawman proposal of how it could be solved:
>
> https://github.com/commercialhaskell/intero/issues/280#
> issuecomment-254787927
>
> What do you think?
>
> Also, if I were to implement the strawman proposal, is it possible to
> recover from a `tyvar :: Type` its original quantification/its "forall"?
> I've had a look through the API briefly and it looks like a _maybe_.
>
> Ciao!
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How, precisely, can we improve?

[Alan & Kim Zimmerman]

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
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Grand Plan for 8.0.2

[Alan & Kim Zimmerman]

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

[Alan & Kim Zimmerman]

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 already does all those phases.

So, would there be any objection to modifying the ModSummary to possibly
retain those artifacts, configurable via a DynFlag?

I would expect the flag would default to retaining none, but could then
either provide for returning all artifacts, or just for the targets
explicitly listed in the `setTargets` call (i.e. not the full `depanal`
result).

Regards
  Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RdrName and decorations

[Alan & Kim Zimmerman]

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 may
have parens or backquotes around it, and may have a preceding keyword out
of [forall, pattern, type].

I am slowly teasing out the contextual requirements to determine these, but
it seems that they should be captured directly in the AST already.  And not
as API Annotations.

So the question is, does it make sense to do this?  Does it belong in the
OccName or the RdrName if so?


Alan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Note [Api annotations]

[Alan & Kim Zimmerman]

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 ghc-exactprint, being an application
that expressly makes use of all of them.

Alan

On Wed, Jul 20, 2016 at 2:01 PM, Matthew Pickering <
matthewtpicker...@gmail.com> wrote:

> On Wed, Jul 20, 2016 at 12:22 PM, Ben Gamari  wrote:
> > Matthew Pickering  writes:
> >
> >> These comments are meant to indicate which annotations each AST
> >> fragment has. However, they are rarely kept up to date and ultimately
> >> not that useful. If someone wants to
> >> know then it is easier to look at the `Annotate` module in
> >> `ghc-exactprint`where this information also exists programatically.
> >>
> > Hmm, the fact that this module is outside of GHC is a bit unfortunate.
> > If I'm looking at a random GHC commit from a year ago how am I to know
> > which annotations I can expect? I guess the testsuite?
>
> The only reliable way is to look at `Parser.y`.
>
> >
> > Cheers,
> >
> > - Ben
> >
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Proposal process status

[Alan & Kim Zimmerman]

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 reddit is a wrong place, so I'm replicating my comment here:
>
> On Wed, 2016-07-20 at 11:36 +0200, Ben Gamari wrote:
> > Hello everyone,
> >
> > As you hopefully know, a few weeks ago we proposed a new process [1]
> > for
> > collecting, discussing, and deciding upon changes to GHC and its
> > Haskell
> > superset. While we have been happy to see a small contingent of
> > contributors join the discussion, the number is significantly smaller
> > than the set who took part in the earlier Reddit discussions.
> >
> > In light of this, we are left a bit uncertain of how to proceed. So,
> > we would like to ask you to let us know your feelings regarding the
> > proposed process:
> >
> >   * Do you feel the proposed process is an improvement over the
> > status
> > quo?
>
> Yes, definitely. The existing process is too vague, so formalizing it
> is a win in any case.
>
>
> >
> >   * Why? (this needn't be long, just a sentence hitting the major
> > points)
> >
> >   * What would you like to see changed in the proposed process, if
> > anything?
>
>
> The proposed process overlaps with the Language Committee powers. In
> theory the Committee works on language standard, but de facto Haskell
> is GHC/Haskell and GHC/Haskell is Haskell. Adding new extension to GHC
> adds new extension to Haskell. So I'd like the process to enforce
> separation between experimental extensions (not recommended in
> production code) and language improvements. I'd like the process to
> specify how the GHC Committee is going to communicate and share powers
> with the Language Committee.
>
> Thanks,
> Yuras.
>
> >
> > That's all. Again, feel free to reply either on the GitHub pull
> > request
> > [1] or this thread if you would prefer. Your response needn't be
> > long;
> > we just want to get a sense of how much of the community feels that
> > 1)
> > this effort is worth undertaking, and 2) that the proposal before us
> > is
> > in fact an improvement over the current state of affairs.
> >
> > Thanks for your help!
> >
> > Cheers,
> >
> > - Ben
> >
> >
> > [1] https://github.com/ghc-proposals/ghc-proposals/pull/1
> > ___
> > Glasgow-haskell-users mailing list
> > glasgow-haskell-us...@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-user
> > s
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Why upper bound version numbers?

[Alan & Kim Zimmerman]

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 hold, because
it does happen, PVP is a human judgement thing.

Alan


On Thu, Jun 9, 2016 at 10:01 AM, Erik Hesselink  wrote:

> What do you expect will be the distribution of 'soft' and 'hard' upper
> bounds? In my experience, all upper bounds currently are 'soft' upper
> bounds. They might become 'hard' upper bounds for a short while after
> e.g. a GHC release, but in general, if a package maintainer knows that
> a package fails to work with a certain version of a dependency, they
> fix it.
>
> So it seems to me that this is not so much a choice between 'soft' and
> 'hard' upper bounds, but a choice on what to do when you can't resolve
> dependencies in the presence of the current (upper) bounds. Currently,
> as you say, we give pretty bad error messages. The alternative you
> propose (just try) currently often gives the same result in my
> experience: bad error messages, in this case not from the solver, but
> unintelligible compiler errors in an unknown package. So it seems the
> solution might just be one of messaging: make the initial resolver
> error much friendlier, and give a suggestion to use e.g.
> --allow-newer=foo. The opposite might also be interesting to explore:
> if installing a dependency (so not something you're developing or
> explicitly asking for) fails to install and doesn't have an upper
> bound, suggest something like --constaint=foo
> Do you have different experiences regarding the number of 'hard' upper
> bounds that exist?
>
> Regards,
>
> Erik
>
> On 8 June 2016 at 22:01, Michael Sloan  wrote:
> > Right, part of the issue with having dependency solving at the core of
> your
> > workflow is that you never really know who's to blame.  When running into
> > this circumstance, either:
> >
> > 1) Some maintainer made a mistake.
> > 2) Some maintainer did not have perfect knowledge of the future and has
> not
> > yet updated some upper bounds.  Or, upper bounds didn't get retroactively
> > bumped (usual).
> > 3) You're asking cabal to do something that can't be done.
> > 4) There's a bug in the solver.
> >
> > So the only thing to do is to say "something went wrong".  In a way it is
> > similar to type inference, it is difficult to give specific, concrete
> error
> > messages without making some arbitrary choices about which constraints
> have
> > gotten pushed around.
> >
> > I think upper bounds could potentially be made viable by having both hard
> > and soft constraints.  Until then, people are putting 2 meanings into one
> > thing.  By having the distinction, I think cabal-install could provide
> much
> > better errors than it does currently.  This has come up before, I'm not
> sure
> > what came of those discussions.  My thoughts on how this would work:
> >
> > * The dependency solver would prioritize hard constraints, and tell you
> > which soft constraints need to be lifted.  I believe the solver even
> already
> > has this.  Stack's integration with the solver will actually first try to
> > get a plan that doesn't override any snapshot versions, by specifying
> them
> > as hard constraints.  If that doesn't work, it tries again with soft
> > constraints.
> >
> > * "--allow-soft" or something would ignore soft constraints.  Ideally
> this
> > would be selective on a per package / upper vs lower.
> >
> > * It may be worth having the default be "--allow-soft" + be noisy about
> > which constraints got ignored.  Then, you could have a
> "--pedantic-bounds"
> > flag that forces following soft bounds.
> >
> > I could get behind upper bounds if they allowed maintainers to actually
> > communicate their intention, and if we had good automation for their
> > maintenance.  As is, putting upper bounds on everything seems to cause
> more
> > problems than it solves.
> >
> > -Michael
> >
> > On Wed, Jun 8, 2016 at 1:31 AM, Ben Lippmeier 
> wrote:
> >>
> >>
> >> On 8 Jun 2016, at 6:19 pm, Reid Barton  wrote:
> >>
> >>>  Suppose you maintain a library that is used by a lot of first year uni
> >>> students (like gloss). Suppose the next GHC version comes around and
> your
> >>> library hasn’t been updated yet because you’re waiting on some
> dependencies
> >>> to get fixed before you can release your own. Do you want your
> students to
> >>> get a “cannot install on this version” error, or some confusing build
> error
> >>> which they don’t understand?
> >>
> >>
> >> This is a popular but ultimately silly argument. First, cabal dependency
> >> solver error messages are terrible; there's no way a new user would
> figure
> >> out from a bunch of solver output about things like "base-4.7.0.2" and
> >> "Dependency tree 

Re: instances for closed type families

[Alan & Kim Zimmerman]

Ryan

The discussion was in this thread [1], but went off list at some point.

The relevant part of the off-list discussion, quoting Philip Hölzenspies  is

"UndecidableInstances comes from having to constrain the type that the
PostTcType-family projects to, besides the arguments of the AST-types;

instance (Data (PostTcType id), Data id) => Data (HsIPBinds id) where ...

If we could derive that from the definition of PostTcType (and I don't see
why we couldn't from a closed family; not sure about the open ones), we
would only need to constrain "id" and, thus, we could actually just use
"deriving".

Of the diff, btw, I don't get why PendingRnSplice is suddenly
parameterised... Thoughts?

Ph."

and SimonPJ responded

"

Why do we need UndecidableInstances?



I still (currently) think we can use open type families perfectly well.
Why won’t that work?  (Could switch to closed after GHC’s bootstrap caught
up.)



Simon

 "

So basically there is a mention that it may be possible.

Alan





[1] https://mail.haskell.org/pipermail/ghc-devs/2014-July/005808.html

On Wed, May 25, 2016 at 9:09 PM, Ryan Scott <ryan.gl.sc...@gmail.com> wrote:

> > I recall there was some discussion when the PostRn/PostTc stuff went in
> around the closed type family solution being better, and I thought it was
> that the Data instances would be more easy to define.
>
> Do you happen to know where this discussion can be found online? To be
> honest, I'm not sure whether closed vs. open type families is even a
> relevant distinction in this case. Regardless of where NameOrRdrName
> is open or closed, the following code won't compile:
>
> data Foo a = Foo (NameOrRdrName a) deriving Data
>
> And that's simply because GHC hasn't enough information to know
> whether Foo a will always resolve to something that's a Data instance.
> Even if NameOrRdrName is closed, someone could still use types like
> NameOrRdrName Char.
>
> If NameOrRdrName were somehow made to be injective, then it'd be 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.
>
> Ryan S.
>
> On Wed, May 25, 2016 at 2:52 PM, Alan & Kim Zimmerman
> <alan.z...@gmail.com> wrote:
> > Ryan / Simon, thanks.
> >
> > I have been working it in the way the PostRn stuff was done, but then it
> > struck me there may be an easier way.
> >
> > I recall there was some discussion when the PostRn/PostTc stuff went in
> > around the closed type family solution being better, and I thought it was
> > that the Data instances would be more easy to define.
> >
> > And I also seem to recall that the closed type families should be able to
> > get rid of the UndecidableInstances pragma, but I do not recall the
> details.
> >
> > We are now able to use closed type families in GHC source, as it is
> > supported from GHC 7.8 onwards
> >
> > Regards
> >   Alan
> >
> >
> > On Wed, May 25, 2016 at 8:42 PM, Ryan Scott <ryan.gl.sc...@gmail.com>
> wrote:
> >>
> >> Simon is right, you cannot use a type family as an instance head. But
> why
> >> do you need to? Typically, if you're deriving a Data instance that
> involves
> >> type families, the type families would be inside another data type. A
> >> real-world example is HsBindLR [1]:
> >>
> >> data HsBindLR idL idR
> >>   = FunBind {
> >>   ...
> >>   bind_fvs :: PostRn idL NameSet,
> >>   ...
> >> } | ...
> >>
> >> where PostRn is a type family [2]. Now, you can't simply derive Data for
> >> HsBindLR, because GHC has no way of knowing what PostRn will evaluate
> to!
> >> But you can use standalone deriving to get what you want:
> >>
> >> deriving instance (Data (PostRn idL NameSet), ...) => Data (HsBindLR
> >> idL idR)
> >>
> >> And in fact, this is what GHC does [3], using a convenient type synonyms
> >> for the long, sprawling context you need [4].
> >>
> >> So in your example, while you can't directly create a Data instance for
> >> NameOrRdrName itself, you can quite easily create Data instances for
> >> anything that might use NameOrRdrName. Does that work for your use
> cases?
> >>
> >> Ryan S.
> >> -
> >> [1]
> >>
> http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39:/compiler/hsSyn/Hs

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

[Alan & Kim Zimmerman]

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
> -+-
> Reporter:  bollu |Owner:
> Type:  feature request   |   Status:  new
> Priority:  low   |Milestone:
>Component:  Compiler  |  Version:  7.10.2
>   Resolution:| Keywords:
> Operating System:  Unknown/Multiple  | Architecture:
>  |  Unknown/Multiple
>  Type of failure:  None/Unknown  |Test Case:
>   Blocked By:| Blocking:
>  Related Tickets:|  Differential Rev(s):
>Wiki Page:|
> -+-
>
> Comment (by mpickering):
>
>  That is true but by them stages in the compilation pipeline you don't care
>  about what the raw format looks like. When modifying the parser  you need
>  to know the precise structure of the AST rather than some pretty printed
>  version produced by `Outputtable`.
>
> --
> Ticket URL: 
> GHC 
> The Glasgow Haskell Compiler
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: ORF and renamer

[Alan & Kim Zimmerman]

Adam

FYI, using https://github.com/alanz/ghc-dump-tree/tree/debug-name I
can see that I have a bug elsewhere in my code.

The output is http://lpaste.net/8427907315830620160, which includes
the nameUnique for each Name in the RenamedSource.

e.g. http://lpaste.net/8427907315830620160#line267

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 the type checker. I wanted to confirm the unambiguous
> case treatment.
>
> I will try to make a clearer description of what I see/am doing.
>
> Alan
>
>
> On Tue, Feb 23, 2016 at 4:20 PM, Adam Gundry <a...@well-typed.com> wrote:
>> Hi Alan,
>>
>> I certainly made a few changes to the renamer as part of the ORF work,
>> but I wouldn't expect them to cause the behaviour you describe. Name
>> resolution for ambiguous record selectors is deferred to the typechecker
>> when the DuplicateRecordFields extension is enabled, but unambiguous
>> selectors (as in your example) are resolved by the renamer. Moreover, I
>> didn't touch anything to do with uniques. The record selector will be in
>> scope once, with a single Name containing a single Unique.
>>
>> Unfortunately, I can't reproduce the behaviour you describe with:
>>
>> ghc-8.0.0.20160204 Field1.hs -ddump-rn-trace -dppr-debug
>>
>> Can you describe in more detail how to reproduce the problem?
>>
>> All the best,
>>
>> Adam
>>
>>
>> On 23/02/16 13:35, Alan & Kim Zimmerman wrote:
>>> I am working on updating HaRe for GHC 8.0.1, and have hit an issue
>>> with the following file
>>>
>>> ---
>>> module Field1 where
>>>
>>> --Rename field name 'pointx' to 'pointx1'
>>>
>>> data Point = Pt {pointx, pointy :: Float}
>>>
>>> absPoint :: Point -> Float
>>> absPoint p = sqrt (pointx p * pointx p +
>>>   pointy p * pointy p)
>>> --
>>>
>>> It seems that after the renamer, each of the three instances of
>>> `pointx` has a different `nameUnique` value.
>>>
>>> Is this because the final resolution is now done during type checking?
>>>  If so it makes the RenamedSource much harder to work with.
>>>
>>> Alan
>>
>>
>>
>> --
>> Adam Gundry, Haskell Consultant
>> Well-Typed LLP, http://www.well-typed.com/
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs