Re: Build GHC in GHC2021

[Richard Eisenberg]

I think this is an excellent idea! So excellent, that we've already done it. :)

When I try to compile with GHC 9.6.2 (what I have lying around), GHC2021 is in 
effect.

Is there something different you were thinking of?

Thanks,
Richard

> On Dec 7, 2023, at 4:39 AM, Arnaud Spiwack  wrote:
> 
> Dear GHC devs,
> 
> Year 2024 is upon us. GHC2021 was released 2 years ago, in GHC 9.2. I think 
> it's time for the base language for GHC to be GHC2021.
> 
> What do we think?
> 
> PS: I don't actually know where the base language for GHC is specified. I 
> couldn't find it with a cursory search
> PPS: if someone makes an MR, bonus points for clearing up hundreds of lines 
> of now-unnecessary extension on top of files.
> 
> -- 
> Arnaud Spiwack
> Director, Research at https://moduscreate.com  and 
> https://tweag.io .
> ___
> 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-level sized Word literals???

[Richard Eisenberg]

Modulo the backward-compatibility piece around today's type-level numbers, I'm 
in support of this direction. No new type machinery is needed, other than a new 
interpretation for literals, because type families can already infer a kind 
argument from the return kind. This is almost entirely a change to libraries, 
not to GHC itself.

Richard

> On Oct 30, 2023, at 5:32 AM, Vladislav Zavialov via ghc-devs 
>  wrote:
> 
> I agree caution is warranted, but I still want the type level to behave as 
> closely as possible to the term level, where literals are currently 
> overloaded.
> 
> I don't care if it's monomorphic literals everywhere or overloaded literals 
> everywhere, but I oppose a discrepancy.
> 
> Vlad
> 
> On Mon, Oct 30, 2023, 10:05 Simon Peyton Jones  > wrote:
> I'm pretty cautious about attempting to replicate type classes (or a weaker 
> version thereof) at the kind level.  An alternative would be to us 
> *non-overloaded* literals.
> 
> 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: GHC and type-family rewriting?

[Richard Eisenberg]

> On Dec 17, 2022, at 10:17 AM, Benjamin Redelings 
>  wrote:
> 
> But supposing I do get there, I'm curious if there are some papers on 
> term-rewriting that would be helpful to set the context?  The OutsideIn paper 
> mentions Kapur (1997) "Shostak's congruence closure as completion" in support 
> of the flattening idea.

I'm not aware of any, but I think looking for some is a good idea. For better 
or worse, the current approach was freshly invented; looking for prior art 
might have yielded something better.

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

Re: GHC and type-family rewriting?

[Richard Eisenberg]

> On Nov 30, 2022, at 9:42 PM, Benjamin Redelings 
>  wrote:
> 
> (Q1) Did GHC evolve to this point starting from something fairly close to the 
> OutsideIn paper?

Yes.

> 
> (Q2) Is the new approach (i.e. eager type family rewriting) mostly to making 
> rewriting faster?

No. Simpler, not faster (and not slower). Or that was the intent.

> 
> (Q3) Does it sound reasonable to implement the approach from the OutsideIn 
> paper, and than gradually transform it to look more like GHC?
> 

Sure, but I'm not sure what the advantage of doing so would be.

This is all my doing: for years and years, GHC's treatment of type families was 
as described in OutsideIn. But I never could quite figure out why we needed to 
have flattening variables. And so I got rid of them -- this seemed like a 
simplification. I'm not sure it really panned out, though: without flattening 
variables, we need these cycle-breaker variables (which are pretty gross). On 
the flip side, I think the new approach might enable the possibility of 
reducing type families only in "strict" positions (e.g. the argument to another 
type family or perhaps a class during instance lookup). In the end, I don't 
think either the old way or the new way is the Right Answer. Maybe you can come 
up with something better than both!

Richard

> -BenRI
> 
> ___
> 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: Partial type synonyms -- first-class!

[Richard Eisenberg]

> On Aug 5, 2022, at 6:17 AM, ÉRDI Gergő  wrote:
> 
> 1. Defining partial type synonyms
> 

This makes some sense to me. You're introducing a new form of invisible 
(implicit) parameter, adding to the two we already have. Today, we have

A. invisible parameters that are filled in via unification. We write these in 
types as `forall a.`
B. invisible parameters that are filled in via looking for a unique inhabitant 
of a type. We write these in types as `C a =>`

You want a third:

C. invisible parameters that are filled in with a fresh wildcard.

We would need to have some way of writing out the type of such a thing (i.e. 
what kind would `Syn` have?), but I presume this is possible.

> 2. Using partial type synonyms
> 
> 

This bit also makes sense, but I think users will want more functionality. 
Specifically, what if a user does not want a wildcard inserted, because they 
know that the right choice is `Int`? Or maybe they want a *named* wildcard 
inserted. My experience is that once something can be done implicitly, folks 
will soon find good reasons to do it explicitly on occasion.

> 3. Implementation
> 
> 
>  * When typechecking a type application, implicit arguments get
>filled with the result of `tcAnonWildCardOcc`.

What about named wildcards? Even if they're not passed in, perhaps someone wants

type SomeEndo = _t -> _t

where the two types are known to be the same, but we don't know what.

> 
> 1. How do I find the wildcard-originating tyvars robustly? Currently,
> I am using `candidateQTyVarsWithBinders` but that picks up "regular"
> out-of-scope tyvars as well. I believe this causes a regression of
> #17567; furthermore, it means if the user writes `type Syn a = Foo b` it
> is handled the same as if they wrote `type Syn a = Foo _`, but it would
> be better to reject it instead.

Yes, sadly I think that you may have to add a new bit of information to e.g. 
TauTv to do this. Sad, but I can't think of another way.

> 
> 2. What should the `Role` of these implicit type parameters be? For
> now, I've went with `Nominal` for lack of a better answer.

Answered by you.

> 
> 3. When typechecking a type application, I need to insert wildcards
> for these implicit arguments. I am currently using `AnonTCB InvisArg`
> binders to represent these implicit type parameters, which means by
> the time I get to `tcInferTyApps`, they would get passed through
> `instantiate` to `tcInstInvisibleTyBinder`. I currently have a
> horrible kuldge here to check, before calling
> `tcInstInivisibleTyBinder`, that the invisible binder's kind doesn't
> meet the preconditions of it; and if it doesn't, I create a wildcard
> instead. But of course, it would be nicer if I could put something in
> the `TcTyConBinder` that identifies these binders properly.

Yes, I think AnonTCB InvisArg will get you into trouble, because that's what's 
used for class constraints. As I observed earlier, you're creating a new form 
of quantification, and so InvisArg doesn't quite say what you want. Make a new 
constructor.



> On Aug 8, 2022, at 10:08 PM, Gergő Érdi  wrote:
> 
> 2. It turns out I misunderstood the `Role` situation and they are
> actually computed via some weird knot tying from the `TyCon` itself.
> So on one hand, I don't really need to do anything to "come up with"
> roles for these implicit type parameters. On the other hand, I think
> this also means that this breaks the surface syntax for role
> declarations, since the user would be expected to give roles for type
> parameters they never explicitly added to their tysyns...

Type synonyms do not support role annotations, so we can dodge this bullet. 
Just let the weird knot tying thing do its work and stay out of the way. :)

> 
> 3. Similar to #1, I started just pushing all the way through GHC a
> change to `AnonArgFlag` that adds a third `ImplArg` flag. It is
> handled mostly the same way as an `InvisArg`, except `tcInferTyApps`
> can use it to insert wildcard arguments. I don't have a full commit
> for this yet.

I don't love adding a new constructor to AnonArgFlag, because that's used in 
terms. Instead, it would be great to localize this new extension to tycon 
binders somehow.

> 
> Beside comments on this approach, I would also like to hear from Simon
> & Richard if they agree that with this new approach, this could now be
> a real language feature that could get upstreamed once all these
> implementation wrinkles are smoothed out.

I think the route you're taking is a reasonable route to your destination, but 
I'm not yet convinced it's a destination I want GHC to travel to. As I hint 
above, I think the feature would have to be expanded somewhat to cover its 
likely use cases, and yet I worry that it will not be widely enough used to 
make its specification and implementation worthwhile. I'm happy to be convinced 
otherwise, though.

Given your design, however, I think the implementation you describe is 
reasonable. I have not read the code you linked to.

I hope 

Re: Wildcards in type synonyms

[Richard Eisenberg]

Yes, your approach makes sense, and you're right that my during-the-renamer 
approach would struggle a bit. Go with your idea. :)

Richard

> On Jul 25, 2022, at 9:21 AM, Gergő Érdi  wrote:
> 
> So my idea from my last email is to avoid the need for `substHsTy`:
> When `tc_hs_type` encounters a macro occurrence,  I would `tcLHsType`
> the rhs then and there (thereby getting fresh metas for each
> wildcard), use `substTy` to instantiate with the given type arguments.
> Then `tc_hs_type` returns that.
> 
> Note that this is NOT about typechecking the rhs *for the definition*,
> but rather, using `tcLHsType` as the function that creates fresh metas
> for each wildcard.
> 
> On Mon, Jul 25, 2022 at 8:58 PM Richard Eisenberg  wrote:
>> 
>> 
>> 
>>> On Jul 25, 2022, at 6:04 AM, ÉRDI Gergő  wrote:
>>> 
>>> On Mon, 25 Jul 2022, Simon Peyton Jones wrote:
>>> 
>>>> Do we have an existing way of substituting types over type variables, 
>>>> *in
>>>> HsType instead of Core Type*?
>>>> I'm afraid not. Currently HsType is not processed much -- just renamed and 
>>>> typechecked
>>>> into a Type.
>>> 
>>> I wonder if, instead, I could expand the rhs, typecheck it "abstractly" 
>>> (i.e. in the context of the synonym's binders), and THEN do the 
>>> substitution.
>> 
>> Why type-check the RHS at all? Presumably, to give nice error messages. But 
>> it looks like this aspect of the plan is inessential. To be clear, I *do* 
>> think you should type-check the RHS, but I'm also checking my understanding 
>> here. If type-checking the RHS is indeed inessential, then the result of 
>> that type-checking (a desugared `Type`) should be discarded.
>> 
>>> If I typecheck the rhs for every occurrence, I should get fresh metavars 
>>> for each wildcard, which is pretty much what I want. I just
>>> have to make sure I don't zonk before the substitution.
>>> 
>> 
>> I see this substitution as happening before any type-checking, so zonking 
>> shouldn't be an issue. That is, I would expect a
>> 
>> substHsTy :: UniqFM Name (HsType GhcRn) -> HsType GhcRn -> HsType GhcRn
>> 
>> to do the work, entirely before type-checking.
>> 
>> (Presumably, you don't want the macro-like behavior to extend to fixity 
>> resolution. That is, if we have
>> 
>> type macro T a = a + b
>> 
>> and then write `f :: T Int * Double`, we want `f :: (Int + b) * Double`, not 
>> `f :: Int + (b * Double)`. If you indeed want the latter (strange days!), 
>> then you'd need to be careful to do the substitution before fixity 
>> resolution, just after renaming.)
>> 
>> Richard
>> 
>>> Does this make sense?
>>> ___
>>> 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: Wildcards in type synonyms

[Richard Eisenberg]

> On Jul 25, 2022, at 6:04 AM, ÉRDI Gergő  wrote:
> 
> On Mon, 25 Jul 2022, Simon Peyton Jones wrote:
> 
>>  Do we have an existing way of substituting types over type variables, 
>> *in
>>  HsType instead of Core Type*?
>> I'm afraid not. Currently HsType is not processed much -- just renamed and 
>> typechecked
>> into a Type.
> 
> I wonder if, instead, I could expand the rhs, typecheck it "abstractly" (i.e. 
> in the context of the synonym's binders), and THEN do the substitution.

Why type-check the RHS at all? Presumably, to give nice error messages. But it 
looks like this aspect of the plan is inessential. To be clear, I *do* think 
you should type-check the RHS, but I'm also checking my understanding here. If 
type-checking the RHS is indeed inessential, then the result of that 
type-checking (a desugared `Type`) should be discarded.

> If I typecheck the rhs for every occurrence, I should get fresh metavars for 
> each wildcard, which is pretty much what I want. I just
> have to make sure I don't zonk before the substitution.
> 

I see this substitution as happening before any type-checking, so zonking 
shouldn't be an issue. That is, I would expect a 

substHsTy :: UniqFM Name (HsType GhcRn) -> HsType GhcRn -> HsType GhcRn

to do the work, entirely before type-checking.

(Presumably, you don't want the macro-like behavior to extend to fixity 
resolution. That is, if we have

type macro T a = a + b

and then write `f :: T Int * Double`, we want `f :: (Int + b) * Double`, not `f 
:: Int + (b * Double)`. If you indeed want the latter (strange days!), then 
you'd need to be careful to do the substitution before fixity resolution, just 
after renaming.)

Richard

> Does this make sense?
> ___
> 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: Wildcards in type synonyms

[Richard Eisenberg]

> On Jul 22, 2022, at 4:53 AM, Simon Peyton Jones  
> wrote:
> 
> expand them during
> typechecking,

Just to expand on this point (haha): your new type macros (distinct from type 
synonyms) would have to be eagerly expanded during type checking. You say this 
(quoted above), but I wanted to highlight that this is in opposition to the way 
today's type synonyms work, which are expanded only when necessary. (Rationale: 
programmers probably want to retain the very clever synonym name they came up 
with, which is hopefully easier to reason about.)

Interestingly, type macros may solve another problem that has come up recently: 
Gershom proposed (a quick search couldn't find where this was, but it was 
around restoring deep-subsumption behavior) a change to the way polytypes work 
in type synonyms. Specifically, he wondered about, e.g.

type T a = forall b. b -> Either a b

meaning to take the `forall b` and lift it to the top of whatever type T 
appears in. So that

f :: [a] -> T a

would really mean

f :: forall a b. [a] -> b -> Either a b

and not

f :: forall a. [a] -> forall b. b -> Either a b

as it does today. With deep subsumption, you can spot the difference between 
these types only with type applications, but they are incomparable types with 
simple subsumption.

At the time, I didn't understand what the semantics of Gershon's new type 
synonyms were, but in the context of Gergo's type macros, they make sense. To 
wit, we could imagine

type T a = b -> Either a b

Note: b is unbound. This is actually a type *macro*, not a type synonym, and it 
expands to a form that mentions a free variable b. (Presumably, this b would 
not capture a b in scope at the usage site.) This macro behavior delivers what 
Gershom was looking for.

I'm not saying Gergo should necessarily implement this new aspect of type 
macros (that don't mention wildcards), but if this ever does come to a 
proposal, I think these kind of variables are a new motivator for such a 
proposal. I'd probably favor some explicit notation to introduce a macro (e.g. 
`type macro T a = Either _ a`) instead of using a syntactic marker like the 
presence of a _ or an unbound variable, but we can debate that later.

Good luck with the implementation, Gergo!
Richard___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

error codes in GHC

[Richard Eisenberg]

Hi devs,

I just wanted to call your attention to 
https://gitlab.haskell.org/ghc/ghc/-/issues/21684, which will add a little more 
bureaucracy to adding error messages in the future, but all for a good cause. 
Please take a look and offer any feedback!

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

Re: ambiguous record field (but not *that* kind of ambiguous record field)

[Richard Eisenberg]

> On May 16, 2022, at 3:45 PM, Sebastian Graf  wrote:
> 
> MkRec { field = \@a -> ... }

Hm -- perhaps you're right. I may have gotten myself all worked up over 
nothing. I was worried that unification would get confused, not sure that the 
`a`s match up. But I now think I was wrong -- it should be OK.

Thanks,
Richard___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

ambiguous record field (but not *that* kind of ambiguous record field)

[Richard Eisenberg]

Hi all,

On a project I'm working on, I wish to declare something like

data Rec = MkRec { field :: forall a. SomeConstraint a => ... }

where the ... contains no mention of `a`.

Even with https://github.com/ghc-proposals/ghc-proposals/pull/448 
, I think there is no 
way to avoid the ambiguity when setting `field`. Is that correct? If so, what 
shall we do about it? The natural answer is somehow to write ... MkRec { field 
@a = ... } ... but that would break significant new syntactic ground. (Maybe 
it's good new syntactic ground, but it would still be very new.)

Thanks,
Richard___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Could margebot squash?

[Richard Eisenberg]

Both the current workflow and the one Joachim proposes here make sense to me, 
with different pros and cons. But I think now is not the time for this debate: 
what we have currently isn't working well enough to consider design changes. 
That is, CI frequently has spurious failures, and it remains (for me, at least) 
mostly a hope that margebot works when assigned. (There are various conditions 
that stop margebot from working, though without reporting any error messages.) 
My understanding is that we were trying to get sufficient support within GitLab 
so that merge trains didn't rely on margebot. I thus think that CI reliability 
and maintainability should be our focus in this area; reorienting to a new 
design would, I fear, distract our limited energy away from that focus.

Richard

> On Apr 2, 2022, at 7:28 AM, Joachim Breitner  wrote:
> 
> Hi,
> 
> as far as I understand, the expected workflow for MRs is that when they
> are ready, the developer manually squashes the chronological commit
> history of the MR into a logical one with polished commit messages,
> typically consisting of a single commit, but could be multiple ones,
> and then assigns the MR to margebot, which will rebase that sequence of
> commits onto the staging branch and eventually merges that into master.
> 
> One downside of this approach is that it requires destructive changes
> to work-in-progres branches: I might think the MR is ready, squash the
> commit sequence into a single commit, but then more work is ready. Now
> it’s hard to revert individual patches, or collaborate with others,
> because the git history was disrupted.
> 
> Another is that the commit message itself isn’t very easily visible to
> reviewers.
> 
> In other similarly sized projects (e.g. mathlib) I often see a mode
> where the actual commits of the MR are ignored (so they can represent
> the true git history of the branch, including merges and all that grit,
> which is good for collaboration and for reviewers to understand what
> has happened, without requiring developers to spend cosmetics effort on
> them), and upon merging by margebot/bors/mergify/whatever, the MR is
> merged as a single commit with the description taken from the MR
> description (which encourages developers to keep the MR description up
> to date as the MR develops, reviewers can easily see that).
> 
> A downside of this that you’ll always get one commit on master per MR.
> If you like to submit a curated list of logical commits within one MR,
> then this would not work, and you’d have to use multiple MRs.
> 
> 
> Has this been considered?
> 
> (I don’t want to cause unnecessary disruption with a presumptious call
> for action here; take it as a comment to weigh in in if and when this
> part of our infrastructure is about to change anyways, or maybe a
> careful probe if my sentiment may be shared widely.)
> 
> Cheers,
> Joachim
> 
> 
> -- 
> Joachim Breitner
>  m...@joachim-breitner.de
>  http://www.joachim-breitner.de/
> 
> ___
> 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: devel2 build flavour thoughts

[Richard Eisenberg]

Interesting -- thanks for taking the time to do this.
> 
> Full build + test: Near identical
> Testsuite run: Near identical
> Recompile: Near identical - (2) is slower
> Build Cabal: 167s vs 259s
I assume from your statement that (2) is 167s and (1) is 259s?

These results surprise me, in a few ways:
- My understanding is that devel2 does not optimise (-O0) the stage-2 compiler. 
So I'm surprised that the testsuite runs in the same amount of time for both: I 
would expect (2) to be measurably faster.
- And if the testsuite is the same for both, then I would expect "Build Cabal" 
to be the same for both: both measurements are looking at the performance of 
the stage-2 compiler. Yet the difference in time in "Build Cabal" is drastic. 
Why is this not echoed in the testsuite? (Maybe the testsuite overhead dwarfs 
the efficiency of the compiler itself?)
- As we have discovered, devel2 behaves differently in the testsuite than your 
flavour (2). But your text suggests that the only difference is that devel2 is 
completely unoptimised... and yet the testsuite-behavior differences are not (I 
think) about performance. So there's some *other* difference.

My key requirements in a build flavor are:
A. assertions enabled
B. quick recompilation
C. < 3 spurious test case failures when running the testsuite locally

I don't have any particular attachment to devel2, per se, other than that (with 
`make`, at least), it delivers A,B,C. My struggle with Hadrian is that devel2 
no longer delivers C. If a different flavor provides A,B,C with Hadrian, I'm 
happy to give it a go. I'm a little worried about "(2) is slower" above, so my 
money is still with devel2, as delivering A,B,C better. Building packages is 
not one of my requirements.

In any case, this is a good conversation to have, because it may yield an 
understanding that we should jettison or replace devel2. Thanks for starting it!

Richard

> 
> So if you want to build packages use flavour 2 but otherwise it seems
> to make little difference.
> 
> 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: safe maps within GHC?

[Richard Eisenberg]

I've tried once or twice to introduce more static checking in the GHC source 
code. My limited experience with this is that the effort is large, and the 
payoff small. Maybe your experience will be different -- I haven't tried the 
particular technique in that paper -- but I probably wouldn't personally invest 
much energy in this direction.

Richard

> On Mar 22, 2022, at 2:10 PM, Norman Ramsey  wrote:
> 
> A blog post of lexi-lambda's recently put me onto Matt Noonan's
> technique "Ghosts of Departed Proofs" [1], which appeared in the 2018
> Haskell Symposium.  One example that intrigued me was a safe `Map`,
> which uses the type system to guarantee that lookup does not fail.
> Maps are used pretty extensively in Cmm-land; for example, I recently
> have been using them to get information like the dominator set or the
> reverse postorder number of every node in a `CmmGraph`.  In these
> maps, every `Label` that appears in the `CmmGraph` is expected to have
> an entry.  For the moment, I am just using the standard lookup
> function; if an entry should be missing, my code calls `panic`.
> The idea of eliminating these calls and getting compile-time type
> safety is intriguing, but I'm not sure the game is worth the candle.
> 
> What do other GHC devs think?
> 
> 
> Norman
> 
> 
> 
> 
> [1] 
> https://iohk.io/en/research/library/papers/ghosts-of-departed-proofsfunctional-pearls/
> ___
> 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: Well-Typed GHC team update

[Richard Eisenberg]

As a wishing-I-were-more-frequent GHC contributor, I just want to say how much 
I appreciate the work this team is doing. Over the past year or so (maybe a 
little longer?), this team has expanded significantly and has become more 
systematized. The effect is simply wonderful. I no longer worry that GHC 
tickets get lost, and the responsiveness is excellent.

Thank you, all, and thanks both to Well-Typed and its financial backers for 
making all this possible!

Richard

> On Feb 22, 2022, at 12:21 PM, Matthew Pickering  
> wrote:
> 
> Hi all,
> 
> We have recently reorganised the structure of the Well-Typed team
> working on the GHC project.
> 
> In short, I am now responsible for more of the management tasks that
> Ben has traditionally carried out. In particular I have responsibility
> for organising the work between us and keeping track of the tasks that
> need to be completed.
> 
> With that in mind, if you need something doing, please email/ping me
> and not Ben with your request and I will make sure someone deals with
> it. On gitlab you can also notify me directly by using the @hq-shepard
> tag, which provides the level of indirection for when this changes
> again in the future.
> 
> The team working at Well-Typed on GHC currently consists of
> 
> Myself (Matthew Pickering)
> Ben Gamari
> Andreas Klebinger
> Sam Derbyshire
> Zubin Duggal
> 
> 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: the linters are killing me slowly

[Richard Eisenberg]

> On Feb 10, 2022, at 3:25 AM, Sven Tennie  wrote:
> 
> 
> What do you think about the idea of having a Hadrian target ready-for-ci (or 
> something like this) that would run all simple checks?

That could work. But my experience with the current linters is that local 
execution gives different results than the execution in CI. Somehow, the CI 
execution is clever enough to flag only new breakages (or breakages in files 
that have been touched, perhaps), whereas when I've run existing linters 
locally, I get a slew of reports that are unrelated to my work.

I suppose the same problem could come up if the linters are in the testsuite, 
though.

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

Re: the linters are killing me slowly

[Richard Eisenberg]

Thanks for the response, Ben; it was more measured than my email. :) I have had 
a string of days when seemingly basic tasks in Haskell failed, all for 
different reasons. And I suppose I knew that this list would be forgiving of 
any trespasses.

I do think there is a very happy resolution to all of this: put these lint 
checks in the testsuite. I believe that was Matthew's idea in yesterday's call, 
and I think that solves the problem very nicely. Errors get reported 
concurrently with other errors, a contributor can run the checks locally, and 
it seems possible to get the linters runnable even without a built GHC. (For 
example, even if the testsuite requires building GHC, the lint tests can call 
some lint-ghc script. But, of course, contributors can call lint-ghc directly, 
too.)

Would that satisfy our needs here?

Thanks,
Richard

> On Feb 9, 2022, at 9:04 PM, Ben Gamari  wrote:
> 
> Richard Eisenberg mailto:li...@richarde.dev>> writes:
> 
>> Hi devs,
>> 
> Hi Richard,
> 
>> Can we please, please not have the linters stop more useful output
>> during CI? Over the past few months, I've lost several days of
>> productivity due to the current design.
> 
> Mmm, yes, this doesn't sound good. I'm sorry it's been such a hassle.
> 
>> Why several days? Because I typically end up with only 1.5-2 hours for
>> GHC work in a day, and when I have to spend half of that recreating
>> test results (which, sometimes, don't work, especially if I use
>> Hadrian, as recommended), I often decide to prioritize other tasks
>> that I have a more reasonable chance of actually finishing.
>> 
>> It was floated some time ago that "Draft" MRs could skip linters. But
>> I actually have a non-Draft MR now, and it failed the new Notes
>> linter. (Why, actually, is that even a separate pass? I thought there
>> was a test case for that, which I'm thrilled with.)
>> 
> It's a separate pass to help the contributor distinguish 
> 
>> It just feels to me that the current workflow is optimized for those
>> of us who work on GHC close to 100% of the time. This is not the way
>> to get new contributors.
>> 
> Yes, I am sympathetic with this concern. One alternative design that we
> could try is to rather allow linters to fail *except* in Marge jobs.
> This would mean that we would need to be very careful not to pass jobs
> with failing lints to Marge as doing so would spoil the entire Marge
> batch. However, it would also mean that it would make contribution in a
> less-than-full-time setting a bit easier. How does this sound?
> 
> If we had more devops capacity we could mitigate the Marge-spoilage
> problem by teaching Marge not to consider MRs which are failing lints.
> However, at the moment I don't think we have the bandwidth to implement
> this.
> 
> Cheers,
> 
> - Ben

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

the linters are killing me slowly

[Richard Eisenberg]

Hi devs,

Can we please, please not have the linters stop more useful output during CI? 
Over the past few months, I've lost several days of productivity due to the 
current design. Why several days? Because I typically end up with only 1.5-2 
hours for GHC work in a day, and when I have to spend half of that recreating 
test results (which, sometimes, don't work, especially if I use Hadrian, as 
recommended), I often decide to prioritize other tasks that I have a more 
reasonable chance of actually finishing.

It was floated some time ago that "Draft" MRs could skip linters. But I 
actually have a non-Draft MR now, and it failed the new Notes linter. (Why, 
actually, is that even a separate pass? I thought there was a test case for 
that, which I'm thrilled with.)

It just feels to me that the current workflow is optimized for those of us who 
work on GHC close to 100% of the time. This is not the way to get new 
contributors.

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

Re: how to complete a review on gitlab?

[Richard Eisenberg]

I think you just unassign yourself using the widget on the right: Click on the 
reviewers button, and you should see yourself highlighted. Click your own icon, 
and that should remove you from the ticket.

Richard

> On Feb 9, 2022, at 10:35 AM, Norman Ramsey  wrote:
> 
> I've been assigned a few merge requests to review on gitlab.  One I've
> completed and approved.  One I've completed and have decided that
> somebody else needs to approve it; I'm not qualified.  Two I've not
> yet started.
> 
> Is there any way to tell gitlab, "I'm done with these two"?
> 
> 
> Norman
> ___
> 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: Question about ambiguous predicates in pattern bindings

[Richard Eisenberg]

I've been a bit under water of late, so I haven't gotten to respond to this. 
But is this superseded by your later email? If not, I'm happy to take a stab at 
an answer.

Thanks,
Richard

> On Jan 15, 2022, at 2:09 PM, Benjamin Redelings 
>  wrote:
> 
> Hi,
> 
> 1. I'm reading "A Static semantics for Haskell" and trying to code it up.  I 
> came across some odd behavior with pattern bindings, and I was wondering if 
> someone could explain or point me in the right direction.
> 
> Suppose you have the declaration
> 
> (x,y) = ('a',2)
> 
> My current code is yielding:
> 
> x :: Num a => Char
> 
> y :: Num a => a
> 
> However, I notice that ghci gives x the type Char, with no constraint, which 
> is what I would expect.  It also gives y the type 'Num b => b', so I don't 
> think it is defaulting a to Int here.
> 
> The weird results from my code stem from rule BIND-PRED in Figure 15 of 
> https://homepages.inf.ed.ac.uk/wadler/papers/staticsemantics/static-semantics.ps
> 
> E  |-  bind ~~> \dicts : theta -> monobinds in bind : (LIE_{encl}, theta 
> => LVE)
> 
> Here theta = ( Num a ) and LVE = { x :: Char, y :: a }.  So, theta => LVE is
> 
> { x :: Num a => Char, y :: Num a => a }
> 
> The obvious thing to do is avoid changing a type T to Num a => T if T does 
> not contain a.  Also I'm not totally sure if that trick gets to the bottom of 
> the issue.  However, the paper doesn't mention define theta => LVE that way.  
> Is there something else I should read on this?
> 
> 2. If we just chop out predicates which mention variables not in the type ( 
> == ambiguous predicates?) then I'm not totally sure how to create code for 
> this.
> 
> I would imagine that we have something like
> 
> tup dn = ('a', fromInteger dn 2)
> 
> x = case (tup dn) of (x,y) -> x
> 
> y dn case (tup dn) of (x,y) -> y
> 
> In this case its not clear where to get the `dn` argument of `tup` from, in 
> the definition of `x`.  Can we pass in `undefined`?  Should we do something 
> else?
> 
> If anyone can shed light on this, I would be grateful :-)
> 
> -BenRI
> 
> ___
> 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: use Hadrian to see if compiler compiles?

[Richard Eisenberg]

> On Jan 25, 2022, at 2:15 PM, Norman Ramsey  wrote:
> 
> Cool!  Supposing I wanted to run just a little code that uses the GHC API.
> Would there be a way to load the Prelude and similar things into that GHCi,
> so it could know about Bool and IO and such things?


The GHCi that runs is your system's GHCi, so it has access to everything 
installed in your bootstrap GHC. However, I don't see a connection between your 
second sentence and your last sentence: that is, the GHCi will certainly know 
about Bool and IO, but I don't see how that helps with the GHC API. I have no 
idea how you would use the GHC API in this mode. My advice would be to use this 
trick to get quick feedback about compilation, and then once GHC compiles, use 
other more well-worn techniques to build it and test your application.

Richard

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

Re: use Hadrian to see if compiler compiles?

[Richard Eisenberg]

My recommendation: ./hadrian/ghci. The first time you run it, it may spin for a 
little while, but it will eventually deliver you to a GHCi prompt, with all of 
GHC loaded. (You can e.g. `:type splitTyConApp_maybe`, after `import 
GHC.Core.Type`.) At that point, :reload will be your dear friend. That's what I 
do when I'm doing e.g. module reorganization and care much more about "does it 
compile" than "does it work".

Richard

> On Jan 24, 2022, at 5:02 PM, Norman Ramsey  wrote:
> 
> I'm currently doing some refactoring of the GHC sources, which
> involves moving definitions between modules.  As a sanity check
> I want to compile often, so if I've broken anything (or have inadvertently
> created circular imports) I can find out quickly.  I'm currently using
> 
>  ./hadrian/build -j
> 
> but I really don't need to build libraries or a stage 2 compiler.
> I tried looking over `./hadrian/build --help`, but I'm not confident
> that I understand what's there.  My best guess is
> 
>  ./hadrian/build -j stage0:lib:ghc
> 
> Would that accomplish my goal?
> 
> 
> Norman
> 
> 
> ___
> 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: convention around pattern synonyms

[Richard Eisenberg]

> On Dec 30, 2021, at 3:25 PM, Viktor Dukhovni  wrote:
> 
> Perhaps my assumption that TH types directly mirror the internal AST is
> not correct...  A recent user-visible change is in `ConP`

Many TH types are modeled after GHC-internal types, but this is just a matter 
of convenience, not necessity. (The necessity -- if we are to maintain feature 
parity in TH -- is that the same information is representable in both sets of 
types, not that the representations are the same.) So the convention I'm 
proposing here wouldn't affect TH.

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

Re: convention around pattern synonyms

[Richard Eisenberg]

I agree that this kind of backward-compatibility pattern synonym is good and 
shouldn't be prefixed with PS_.

But do you have a concrete example of this leakage of an internal GHC type via 
TH? While I can imagine this happening, I don't know of any examples in 
practice. Note that even enumeration types (like Role) have separate TH 
counterparts.

Richard

> On Dec 29, 2021, at 6:12 PM, Viktor Dukhovni  wrote:
> 
> Some "GHC-internal" types leak to users via TH, and their constructors
> occasionally pick up new fields, causing breakage downstream.  The extra
> field often has a sensible default (Nothing, [], ...) and it should be
> best practice to rename the constructor when adding the new field, while
> replacing the original constructor with a pattern synonym with the "old"
> signature.
> 
>   data Foo = ...
>| NewImprovedMkFoo X Y Z -- was MkFoo Y Z
> 
>   pattern MkFoo :: Foo
>   pattern MkFoo Y Z = NewImprovedMkFoo Nothing Y Z
> 
> When pattern synonyms are used to maintain a backwards-compatible API,
> there should of course be no special signalling to differentiate them
> from "real" constructors.
> 
> The boundary between "GHC-internal" and external may not always be
> obvious, some care is required to reduce leaking breakage via TH.
> 
> -- 
>   Viktor.
> ___
> 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: convention around pattern synonyms

[Richard Eisenberg]

> On Dec 29, 2021, at 1:19 PM, Edward Kmett  wrote:
> 
> If this is just about GHC internals, then by all means carry on.

Yes, I should have clarified: this is just and solely about GHC internals! I 
have no designs on suggesting a wider convention like this. Indeed, both of the 
designs you describe below make great sense to use pattern synonyms for -- and 
without any herald that you are doing so. Within GHC, however, we now have a 
few cases where pattern synonyms are effectively behaving like or-patterns, 
which I find unexpected and confusing without a marker telling me Something 
Unusual is going on.

(Why? Because in both cases, the pattern synonym is really designed to act like 
a constructor. In the first case, if I understand correctly, the pattern 
synonym is just a renaming of an existing constructor, with no extra 
computation. In the second case, if I understand correctly, the pattern synonym 
captures what used to be a constructor. It's plausible that GHC will want to 
adopt either of these patterns at some point in the future, but we do not do 
either one today, and so I would say to address any change to my proposed 
coding convention when this happens.)

Richard

> 
> -Edward
> 
> On Wed, Dec 29, 2021 at 12:19 PM Edward Kmett  <mailto:ekm...@gmail.com>> wrote:
> Please no.
> 
> I use them to pun constructors between multiple types that will be in scope 
> at the same time, (e.g. when I have 8 Var constructors on different types in 
> scope between my core language term language and type language...) and often 
> overload them on classes. I can't write the pragma, and the PS_ destroys any 
> utiity I get from any common name.
> 
> I use them as a migration guide, when I add functionality. PS_ destroys that 
> usecase, but then COMPLETE pragmas are a hacky mess in their current state 
> and often simply can't be applied.
> 
> All the existing pattern constructors in the lens library would fail either 
> bar.
> 
> So I have to say, either of these would probably destroy every use of pattern 
> synonyms I use today.
> 
> -Edward
> 
> On Wed, Dec 29, 2021 at 11:55 AM Richard Eisenberg  <mailto:li...@richarde.dev>> wrote:
> Hi devs,
> 
> Maybe I'm just old fashioned, but I've come to find pattern synonyms really 
> confusing. Because pattern synonyms will tend to appear next to proper data 
> constructors in code (and they look just like data constructors), when I see 
> one, I think it *is* a data constructor. This problem was motivated by a 
> recent MR that introduces a new pattern synonym 
> <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7261/diffs#7dcf5b567a6cd3c9d98cf8d57323fbca1b1536e9_1128_1130>
>  that caught me off-guard.
> 
> So, I'd like to propose the following convention: Every pattern synonym 
> satisfies one of the following two criteria:
> 1. The pattern synonym is a member of a set of synonyms/constructors that 
> expresses a view of a type. There would naturally be a `COMPLETE` pragma 
> including the set. `GHC.Types.Var.Inferred` is an example.
> 2. The pattern synonym begins with the prefix `PS_`.
> 
> In the end, I'd probably prefer just (2). With Inferred, for example, I've 
> been caught in the past trying to figure just what the constructors of 
> ArgFlag were (there seemed to be too many), until I realized what was going 
> on.
> 
> Pattern synonyms are useful abstractions. I like them. But my mental model of 
> a pattern match is that it matches the structure of the scrutinee and 
> performs no computation. Pattern synonyms violate both of these assumptions, 
> and so (as a reader) I like to know when to put these assumptions to the side.
> 
> Future IDE support that could, say, color pattern synonyms differently to 
> regular constructors would obviate the need for this convention.
> 
> What do others think here? `PS_` is ugly. I don't need something quite so 
> loud and ugly, but it's also easy to remember and recognize.
> 
> Thanks!
> Richard
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org <mailto:ghc-devs@haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs 
> <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

convention around pattern synonyms

[Richard Eisenberg]

Hi devs,

Maybe I'm just old fashioned, but I've come to find pattern synonyms really 
confusing. Because pattern synonyms will tend to appear next to proper data 
constructors in code (and they look just like data constructors), when I see 
one, I think it *is* a data constructor. This problem was motivated by a recent 
MR that introduces a new pattern synonym 

 that caught me off-guard.

So, I'd like to propose the following convention: Every pattern synonym 
satisfies one of the following two criteria:
1. The pattern synonym is a member of a set of synonyms/constructors that 
expresses a view of a type. There would naturally be a `COMPLETE` pragma 
including the set. `GHC.Types.Var.Inferred` is an example.
2. The pattern synonym begins with the prefix `PS_`.

In the end, I'd probably prefer just (2). With Inferred, for example, I've been 
caught in the past trying to figure just what the constructors of ArgFlag were 
(there seemed to be too many), until I realized what was going on.

Pattern synonyms are useful abstractions. I like them. But my mental model of a 
pattern match is that it matches the structure of the scrutinee and performs no 
computation. Pattern synonyms violate both of these assumptions, and so (as a 
reader) I like to know when to put these assumptions to the side.

Future IDE support that could, say, color pattern synonyms differently to 
regular constructors would obviate the need for this convention.

What do others think here? `PS_` is ugly. I don't need something quite so loud 
and ugly, but it's also easy to remember and recognize.

Thanks!
Richard___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Output language of typechecking pass?

[Richard Eisenberg]

Yes, GitLab supports such a permalink. The problem is that we frequently revise 
Notes as we understand problems better / improve the implementation. So a 
reader might link to a Note from the wiki only to study an old implementation 
that has been superseded.

Richard

> On Dec 28, 2021, at 3:52 PM, Alan & Kim Zimmerman  wrote:
> 
> 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  <mailto:li...@richarde.dev>> 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 
>> mailto: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 
>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fwikis%2Fcommentary%2Fcompiler%2Fhsc-main=04%7C01%7Csimonpj%40microsoft.com%7Cab59b17d2f394945ad1e08d9a2b96c81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637719740212483767%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=WZL1VADZPUlaOACd58K1XZO5MzPOKrfLFMSuBD%2FGW44%3D=0>
>>> 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 <mailto:simo...@microsoft.com> will cease to work.  
>>> Use simon.peytonjo...@gmail.com <mailto:simon.peytonjo...@gmail.com> 
>>> instead.  (For now, it just forwards to sim

Re: Output language of typechecking pass?

[Richard Eisenberg]

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 
>  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 
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fwikis%2Fcommentary%2Fcompiler%2Fhsc-main=04%7C01%7Csimonpj%40microsoft.com%7Cab59b17d2f394945ad1e08d9a2b96c81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637719740212483767%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=WZL1VADZPUlaOACd58K1XZO5MzPOKrfLFMSuBD%2FGW44%3D=0>
>> 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 <mailto:simo...@microsoft.com> will cease to work.  
>> Use simon.peytonjo...@gmail.com <mailto:simon.peytonjo...@gmail.com> 
>> instead.  (For now, it just forwards to simo...@microsoft.com 
>> <mailto:simo...@microsoft.com>.)
>>  
>> From: ghc-devs  
>> <mailto:ghc-devs-boun...@haskell.org> On Behalf Of Benjamin Redelings
>> Sent: 08 November 2021 13:12
>> To: Richard Eisenberg  <mailto:li...@richarde.dev>
>> Cc: ghc-devs@haskell.org <mailto: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 
>

Re: CI: Choice of base commit for perf comparisons

[Richard Eisenberg]

It seems to be that this thought is in the air right now. This was done just a 
few days ago: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7184

https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7231 also looks relevant.

Richard

> On Dec 22, 2021, at 7:19 AM, Joachim Breitner  
> wrote:
> 
> Hi,
> 
> the new (or “new”?) handling of perf numbers, where CI just magically
> records and compares them, without us having to manually edit the
> `all.T` files, is a big improvement, thanks!
> 
> However, I found the choice of the base commit to compare against
> unhelpful. Assume master is at commit M, and I start a feature branch
> and MR with commit A. CI runs, and tells me about a performance
> regressions, and CI is red. I now fix the issue and push commit B to
> the branch. CI runs, but it picks A to compare against, and now it is
> red because of an seemingly unexpected performance improvement!
> 
> I would have expected that all CI runs for this MR to compare the
> performance against the base branch on master, and to look for perf
> change notices in all commit messages in between.
> 
> I see these advantages:
> 
> * The reported perf changes correspond to the changes shown on the MR 
>   page
> * Green CI = the MR is ready (after squashing)
> * CI will have numbers for the base commit more reliably
>   (else, if I push commit C quickly after B, then the job for B might
>   be cancelled and Ci will report changes of C against A instead of B,
>   which is unexpected).
> 
> I have used this logic of reporting perf changes (or any other
> “differential CI”) against the base branch in the Motoko project and it
> was quite natural.
> 
> Would it be desirable and possible for us here, too?
> 
> 
> (A possible rebuttal might be: we don’t push new commits to feature
> branches, but always squash and rebase, as that’s what we have to do
> before merging anyways. If that’s the case then ok, although I
> generally lean to having chronological commits on feature branches and
> a nice squashed commit on master.)
> 
> Cheers,
> Joachim
> 
> 
> -- 
> Joachim Breitner
>  m...@joachim-breitner.de
>  http://www.joachim-breitner.de/
> 
> ___
> 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: [PSA] Patches to Haddock regarding GHC development move to GitLab!

[Richard Eisenberg]

Hi Hécate,

Thanks for this announcement.

Can you also update the documentation in 
https://gitlab.haskell.org/ghc/ghc/-/wikis/repositories to reflect this change? 
That wiki page remains my go-to source for this kind of information.

That page also says that 
https://gitlab.haskell.org/ghc/ghc/-/blob/master/packages is the authoritative 
place to look for submodule information. Does that need updating, too?

Thanks! :)
Richard

> On Dec 17, 2021, at 11:47 AM, Hécate  wrote:
> 
> Hi everyone, just a PSA from the Haddock team and GHC release managers to 
> warn everyone that, effective immediately, patches to Haddock needed for GHC 
> merge requests are not to be directed to GitHub anymore.
> 
> Those patches are to be sent to the GitLab mirror: 
> https://gitlab.haskell.org/ghc/haddock.
> 
> I will try and warn folks who currently have PRs opened on GitHub targeting 
> ghc-head, but please know that they'll be closed in the next few days.
> 
> Have a great end of the week,
> Hécate, for the Haddock Team.
> 
> -- 
> Hécate ✨
> : @TechnoEmpress
> IRC: Hecate
> WWW: https://glitchbra.in
> RUN: BSD
> 
> ___
> 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: Concrete#, SpecialPred, and CtEvidence invariants

[Richard Eisenberg]

Good point.

The Note is wrong.

But I don't like an invariant on a data structure about zonkedness: the 
zonkedness of a type can change whenever we fill in a unification variable, 
possibly very far away. (On the other hand, it does make sense for functions to 
talk about zonkedness in preconditions and postconditions, because function 
calls happen at a certain instant of time.)

Instead, I think the invariant is good as it is except for CSpecialPreds. Which 
are special. :)

And, you're right that a CoVar should never have a type of Concrete# blah. Find 
that code and kill it.

Does this help?

Richard

> On Dec 8, 2021, at 2:40 PM, Alexis King  wrote:
> 
> Hi all,
> 
> After a recent off-list conversation, I’ve been exploring using the new 
> SpecialPred mechanism to implement a custom constraint, but I’ve run into 
> some questions regarding evidence for CSpecialCan constraints. Specifically, 
> I’m uncertain about how to use them while satisfying Note [CtEvidence 
> invariants] in GHC.Tc.Types.Constraint.
> 
> Specifically, the Note in question states that ctev_pred must always be kept 
> in sync with the type of the evidence. For example, if ctev_dest for a wanted 
> constraint is a coercion hole, ctev_pred must be `varType (coHoleCoVar 
> hole)`. However, this seems rather odd in the case of Concrete# constraints, 
> since the evidence for a `Concrete# (ty :: ki)` constraint is a coercion of 
> type `ty ~# alpha`.
> 
> In canNonDecomposableConcretePrim in GHC.Tc.Solver.Canonical, setCtEvPredType 
> is used to update the type of a CSpecialCan constraint, and setCtEvPredType 
> automatically maintains the CtEvidence invariant mentioned above. But this 
> results in setCoHoleType being used to modify the type of the CoVar from `ty 
> ~# alpha` to `Concrete# (ty :: ki)`, which does not make much sense, since 
> that is definitely not the type of the CoVar. As far as I can tell, the only 
> reason that doesn’t cause Core Lint errors is that the modified CoVar is 
> never actually used, only the original one is.
> 
> This suggests to me that the invariant is not actually the right one. The 
> Note suggests that the reason the invariant exists is that the type must be 
> kept fully-zonked… which in turn suggests that perhaps fully-zonkedness is 
> the invariant that’s actually desired. In that case, ctev_pred would not 
> necessarily always be a cache for the type of the evidence, since in the case 
> of Concrete#, the evidence has a different type (though for other types of 
> constraints the old invariant would still coincidentally hold). Rather, it 
> would be the responsibility of canNonDecomposableConcretePrim to merely 
> ensure the evidence’s type is appropriately zonked.
> 
> Does this all sound right to people? If so, I will update the Note with the 
> modified invariant and update the code to match.
> 
> Alexis

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

GitLab likes Chrome more than Firefox

[Richard Eisenberg]

Hi all,

On a tip from Ben, I'm using Chrome to review a large patch (!7033 for the 
curious). It is qualitatively better than Firefox, my usual tool. I will be 
routinely using Chrome to review large patches from now on. You may want to, 
too.

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

Re: DWARF support

[Richard Eisenberg]

> On Nov 18, 2021, at 10:29 AM, Ben Gamari  wrote:
> 
> At this point, for backtrace support I would rather put my money is on a
> native Haskell stack unwinder (such as Sven Tennie's work [3,4]). Not only
> is it more portable but it is also more robust (whereas with DWARF any
> single object lacking debug information would break unwinding), and is
> significantly less costly since we know much more about the structure of
> our stack than a DWARF unwinder would.

Interesting -- this is helpful to know. I had heard about DWARF support for 
some years and thought that it would deliver stack traces. Now I will look for 
other sources. All good -- I understand how this is hard! -- and nice to know 
about.

Thanks for the writeup, Ben.

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

Re: DWARF support

[Richard Eisenberg]

Thanks for this!

> On Nov 17, 2021, at 7:27 AM, Moritz Angermann  
> wrote:
> 
> For Linux and most BSDs, we have settled on the Executable and Linking Format 
> (ELF) as the container format for
> your machine code.  And you might see where the inspiration for DWARF might 
> come from.

This suggests to me that DWARF is the canonical format for debugging 
information on Linux and most BSDs. Is that statement correct? If so, how is 
that different to "platform-native"? Actually, the precise wording doesn't 
matter: I think I'm just requesting for a more direct relationship between 
"DWARF" and "compatibility with all the debugging and profiling tools you use 
for other languages".

> 
> For macOS, we have mach object (mach-o) as the container format. Its 
> distinctly different to ELF, and also the
> reason why Linux/BSD and macOS are sometimes substantially different, wrt to 
> executable packaging and linking.

OK. So there is no macOS support here. That's fine -- I'm just trying to 
understand the status quo.

> 
> For windows we have Portable Executable (PE) as the container format.

This implies that the DWARF work is (unsurprisingly) completely inapplicable 
for Windows.

> Depending on how familiar you are with development on macOS, you might know 
> the notion of dSYM folders,
> where macOS usually separate the application binary into the binary, and then 
> stores the (d)ebug (SYM)bols in
> a separate folder. Those are iirc DWARF objects in the end.

This suggests to me that the DWARF work is applicable to the macOS use case, 
but much more work still needs to be done. OK.

Looking for more information, I checked the manual. And I found this: 
https://downloads.haskell.org/ghc/latest/docs/html/users_guide/debug-info.html  
It's really helpful! And it suggests that I actually *can* do this on macOS. 
Perhaps that video will really happen after all.

Forgive the noise -- I should have checked the manual first. :)

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

DWARF support

[Richard Eisenberg]

Hi devs,

I was intrigued by Bodigrim's comment about HasCallStack in base 
(https://github.com/haskell/core-libraries-committee/issues/5#issuecomment-970942580)
 that there are other alternatives, such as DWARF. Over the years, I had tuned 
out every time I saw the word DWARF: it was (and is!) an unknown acronym and 
seems like a low-level detail. But Bodigrim's comment made me want to re-think 
this stance.

I found Ben's series of blog posts on DWARF, starting with 
https://www.haskell.org/ghc/blog/20200403-dwarf-1.html. These are very helpful! 
In particular, they taught me that DWARF = platform-native debugging metadata. 
Is that translation accurate? If so, perhaps we should use both names: if I see 
that GHC x.y.z has DWARF support, I quickly scroll to the next bullet. If I see 
that GHC x.y.z has support for platform-native debugging metadata and is now 
compatible with e.g. gdb, I'm interested.

Going further, I have a key question for my use case: is this support available 
on Mac? The first post in the series describes support for "Linux and several 
BSDs" and the last post says that "Windows PDB support" is future work. (Is 
"PDB" platform-native debugging metadata for Windows? I don't know.) But I 
don't see any mention of Mac. What's the status here?

It would be very cool if this conversation ends with me making a video on how a 
few simple GHC flags can allow us to, say, get a stack trace on a pattern-match 
failure in a Haskell program.

Thanks!
Richard

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

Re: Case split uncovered patterns in warnings or not?

[Richard Eisenberg]

Maybe the answer should depend on whether the scrutinee has already been 
forced. The new output ("We now say", below) offers up patterns that will 
change the strictness behavior of the code. The old output did not.

Reading the link below, I see that, previously, there was an inconsistency with 
-XEmptyCase, which *did* unroll one level of constructor. But maybe that made 
sense because -XEmptyCase is strict (unlike normal case).

I'm just saying this because I think listing the constructors in the 
-XEmptyCase case is a good practice, but otherwise I think they're 
clutterful... and strictness is a perhaps more principled way of making this 
distinction.

Richard

> On Nov 9, 2021, at 8:17 AM, Sebastian Graf  wrote:
> 
> Hi Devs,
> 
> In https://gitlab.haskell.org/ghc/ghc/-/issues/20642 
>  we saw that GHC >= 8.10 
> outputs pattern match warnings a little differently than it used to. Example 
> from there:
> 
> {-# OPTIONS_GHC -Wincomplete-uni-patterns #-}
> 
> foo :: [a] -> [a]
> foo [] = []
> foo xs = ys
>   where
>   (_, ys@(_:_)) = splitAt 0 xs
> 
> main :: IO ()
> main = putStrLn $ foo $ "Hello, coverage checker!"
> Instead of saying
> 
> ListPair.hs:7:3: warning: [-Wincomplete-uni-patterns]
> Pattern match(es) are non-exhaustive
> In a pattern binding: Patterns not matched: (_, [])
> 
> We now say
> 
> ListPair.hs:7:3: warning: [-Wincomplete-uni-patterns]
> Pattern match(es) are non-exhaustive
> In a pattern binding:
> Patterns of type ‘([a], [a])’ not matched:
> ([], [])
> ((_:_), [])
> 
> E.g., newer versions do (one) case split on pattern variables that haven't 
> even been scrutinised by the pattern match. That amounts to quantitatively 
> more pattern suggestions and for each variable a list of constructors that 
> could be matched on.
> The motivation for the change is outlined in 
> https://gitlab.haskell.org/ghc/ghc/-/issues/20642#note_390110 
> , but I could 
> easily be swayed not to do the case split. Which arguably is less surprising, 
> as Andreas Abel points out.
> 
> Considering the other examples from my post, which would you prefer?
> 
> Cheers,
> Sebastian
> ___
> 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: Exact Print Annotations : Anchor in a SrcSpan

[Richard Eisenberg]

I don't remember the details precisely, but I do know that the BufSpan was 
added to allow for reliable comparisons of SrcSpans in the presence of #line 
pragams. I've included Vlad, who is the resident expert on this aspect of 
locations.

My instinct is to lean against repurposing the existing slot just because it 
happens to fit, unless there is a semantic argument for why the Maybe BufSpan 
and the Anchor represent the same underlying concept.

Richard

> On Oct 28, 2021, at 5:18 PM, Alan & Kim Zimmerman  wrote:
> 
> 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

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

Re: Resources on how to implement (Haskell 98) kind checking?

[Richard Eisenberg]

> On Oct 27, 2021, at 9:36 AM, Benjamin Redelings 
>  wrote:
>> 
>> This won't work.
>> 
>> class C a where
>>   meth :: a b -> b Int
>> 
>> You have to know the kind of local b to learn the kind of class-variable a. 
>> So you have to do it all at once.
> I was doing it all at once -- but I wasn't sure how to export the information 
> about 'b' from the procedure.  (After you record the kinds of the typecons 
> like C, I believe the different typecons in the recursive group become 
> separable.)
> 
> I presume (in retrospect) that GHC modifies the declaration to record the 
> kind of b, and then re-walks the declaration to substitute kind variables 
> later?
> 
That would be smart, but it's not what GHC does. Instead, GHC first says (a :: 
kappa), for a fresh unification variable kappa. Then, GHC determines (b :: Type 
-> Type) and thus unifies kappa := (Type -> Type) -> Type. GHC then *throws 
away* the information about b. (See the `_ <- ...` at 
https://gitlab.haskell.org/ghc/ghc/-/blob/638f65482ca5265c268aa97abfcc14cdc27e46ba/compiler/GHC/Tc/Gen/HsType.hs#L388)
 Having now determined conclusively what the kind of `a` is, GHC will later 
re-check the kind of the type of meth, recording it for good.
> But if that is a difficulty on the right road, I will just go for it.  
> 
If zonking is a difficulty, there's probably something wrong somewhere. 
Lengthy, yes, but not difficult. If you're using Data.Data, I imagine you could 
implement zonking with just the right use of Data.Generics.Schemes.everywhere.

> Oh, I forgot to add, would it make sense to put some of the information I 
> discovered about implementing kind checking into the wiki somewhere?
> 
This is an excellent idea, but I'll counterpropose that you write this in a 
Note. Indeed, Note [Kind checking for type and class decls] in GHC.Tc.TyCl is 
probably meant to be the Note you're looking for, but it's too short. Feel free 
to flesh it out with all of these details. Then, make sure that the functions 
that implement the details refer to the Note (and vice versa). This will help 
it to stay up-to-date -- much more so than putting it in the wiki.
> It might also help to reference the relevant papers (mostly the PolyKinds 
> paper), and maybe also to mention papers like the THIH paper that don't 
> actually implement kind checking.
> 
Yes, refer to papers. But please do use their proper names (years and 
conference names are also helpful). It actually took some inference for me to 
figure out what the "PolyKinds paper" was in your emails. (The paper that 
proposes the extension that became PolyKinds is "Giving Haskell a Promotion", 
TLDI'12, and the paper that describes its extension to work more generally is 
"System FC with Explicit Kind Equality", ICFP'13. I thought you were referring 
to one of these -- not to "Kind Inference for Datatypes".)

Thanks!
Richard


> -BenRI
> 
> On 10/15/21 1:37 PM, Richard Eisenberg wrote:
>> 
>> 
>>> On Oct 14, 2021, at 11:59 AM, Benjamin Redelings 
>>> mailto:benjamin.redeli...@gmail.com>> wrote:
>>> 
>>> I asked about this on Haskell-Cafe, and was recommended to ask here 
>>> instead.  Any help is much appreciated!
>>> 
>> 
>> I saw your post over there, but haven't had time to respond but this 
>> retelling of the story makes it easier to respond, so I'll do so here.
>> 
>>> * The PolyKinds paper was the most helpful thing I've found, but it doesn't 
>>> cover type classes.  I'm also not sure that all implementers can follow 
>>> algorithm descriptions that are laid out as inference rules, but maybe that 
>>> could be fixed with a few hints about how to run the rules in reverse.  
>>> Also, in practice I think an implementer would want to follow GHC in 
>>> specifying the initial kind of a data type as k1 -> k2 -> ... kn -> *. 
>>> 
>> 
>> What is unique about type classes? It seems like you're worried about 
>> locally quantified type variables in method types, but (as far as kind 
>> inference is concerned) those are very much like existential variables in 
>> data constructors. So perhaps take the bit about existential variables from 
>> the PolyKinds part of that paper and combine it with the Haskell98 part.
>> 
>> It's true that many implementors may find the notation in that paper to be a 
>> barrier, but you just have to read the rules clockwise, starting from the 
>> bottom left and ending on the bottom right. :)
>>> 
>>> 2. The following question (which I have maybe kind of answered now, but 
>>> could use more advice on) is an example of what I am hoping such 
>>&

Re: Output language of typechecking pass?

[Richard Eisenberg]

> On Oct 27, 2021, at 9:54 AM, Benjamin Redelings 
>  wrote:
> 
> Hi,
> 
> I have been looking for info on what actually comes out of the 
> type-checking pass in GHC.  This is mostly because it seems like the "Type 
> classes in Haskell" paper implements both type checking and translation to 
> dictionary-passing in one pass, whereas it seems like GHC separates this into 
> (i) type checking and (ii) desugaring.

This is correct: GHC takes two different passes to do this work. The big reason 
is around error messages: we want to have the code that the user wrote when 
reporting error messages. Since errors arise during type-checking, we thus want 
the output of the type checker to look like what the user wrote.

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

> 
> 2. Does the output of type checking contain type lambdas?

Yes. See below.

> 
> 3. Does the type checking pass determine where to add dictionary arguments?

Yes. See below.

> 
> 4. Are there any other resources I should be looking at?

Yes. You want to enable -fprint-typechecker-elaboration (and possible 
-fprint-explicit-coercions). With the former, you get to see all this stuff 
you're looking for. It's normally suppressed so that the output resembles the 
user's code.

I hope this helps!
Richard
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Resources on how to implement (Haskell 98) kind checking?

[Richard Eisenberg]

> On Oct 14, 2021, at 11:59 AM, Benjamin Redelings 
>  wrote:
> 
> I asked about this on Haskell-Cafe, and was recommended to ask here instead.  
> Any help is much appreciated!
> 

I saw your post over there, but haven't had time to respond but this 
retelling of the story makes it easier to respond, so I'll do so here.

> * The PolyKinds paper was the most helpful thing I've found, but it doesn't 
> cover type classes.  I'm also not sure that all implementers can follow 
> algorithm descriptions that are laid out as inference rules, but maybe that 
> could be fixed with a few hints about how to run the rules in reverse.  Also, 
> in practice I think an implementer would want to follow GHC in specifying the 
> initial kind of a data type as k1 -> k2 -> ... kn -> *. 
> 

What is unique about type classes? It seems like you're worried about locally 
quantified type variables in method types, but (as far as kind inference is 
concerned) those are very much like existential variables in data constructors. 
So perhaps take the bit about existential variables from the PolyKinds part of 
that paper and combine it with the Haskell98 part.

It's true that many implementors may find the notation in that paper to be a 
barrier, but you just have to read the rules clockwise, starting from the 
bottom left and ending on the bottom right. :)
> 
> 2. The following question (which I have maybe kind of answered now, but could 
> use more advice on) is an example of what I am hoping such documentation 
> would explain: 
> 
> 
>> Q: How do you handle type variables that are present in class methods, but 
>> are not type class parameters? If there are multiple types/classes in a 
>> single recursive group, the kind of such type variables might not be fully 
>> resolved until a later type-or-class is processed.  Is there a recommended 
>> approach? 
>> 
>> I can see two ways to proceed: 
>> 
>> i) First determine the kinds of all the data types, classes, and type 
>> synonyms.  Then perform a second pass over each type or class to determine 
>> the kinds of type variables (in class methods) that are not type class 
>> parameters. 

This won't work.

class C a where
  meth :: a b -> b Int

You have to know the kind of local b to learn the kind of class-variable a. So 
you have to do it all at once.

>> 
>> ii) Alternatively, record the kind of each type variable as it is 
>> encountered -- even though such kinds may contain unification kind 
>> variables.  After visiting all types-or-classes in the recursive group, 
>> replace any kind variables with their definition, or with a * if there is no 
>> definition. 
>> 
>> I've currently implement approach i), which requires doing kind inference on 
>> class methods twice. 
>> 
> Further investigation revealed that GHC takes yet another approach (I think): 
> 
> iii) Represent kinds with modifiable variables.  Substitution can be 
> implemented by modifying kind variables in-place.  This is (I think) called 
> "zonking" in the GHC sources. 

I don't really see the difference between (ii) and (iii). Maybe (ii) records 
the kinds in a table somewhere, while (iii) records them "in" the kind 
variables themselves, but that's not so different, I think.

> 
> This solves a small mystery for me, since I previously thought that zonking 
> was just replacing remaining kind variables with '*'.  And indeed this seems 
> to be an example of zonking, but not what zonking is (I think). 

We can imagine that, instead of mutation, we build a substitution mapping 
unification variables to types (or kinds). This would be stored just as a 
simple mapping or dictionary structure. No mutation. As we learn about a 
unification variable, we just add to the mapping. If we did this, zonking would 
be the act of applying the substitution, replacing known unification variables 
with their values. It just so happens that GHC builds a mapping by using 
mutable cells in memory, but that's just an implementation detail: zonking is 
still just applying the substitution.

Zonking does not replace anything with *. Well, functions that have "zonk" in 
their name may do this. But it is not really logically part of the zonking 
operation. If you like, you can pretend that, after zonking a program, we take 
a separate pass replacing any yet-unfilled kind-level unification variables 
with *. Sometimes, this is called "zapping" in GHC, I believe.

> 
> Zonking looks painful to implement, but approach (i) might require multiple 
> passes over types to update the kind of type variables, which might be 
> worse...

Zonking is a bit laborious to implement, but not painful. Laborious, because it 
requires a full pass over the AST. Not painful, because all it's trying to do 
is replace type/kind variables with substitutions: each individual piece of the 
puzzle is quite simple.

I hope this is helpful!
Richard___
ghc-devs mailing list
ghc-devs@haskell.org

GitLab summary note on review

[Richard Eisenberg]

Hi devs,

I've frequently wanted to attach a summary note to a review, unattached to any 
line of code. I thought this was impossible, but I see how to do it now.

After making your review, with perhaps many line comments, go back to the 
Overview pane. Then, you can write a comment at the bottom, and, critically, 
add it to the review. Then, when you submit the review, the summary comment 
goes with it.

Happy reviewing,
Richard
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: help validating a modified compiler?

[Richard Eisenberg]

Speaking for myself: I have not validated locally for quite a while. I just 
rely on CI. You can mark an MR as a "Draft" to avoid triggering a review.

Instead of validating locally, I tend to just run the testsuite on the built 
GHC. This can be done with hadrian/build test -j. (You might want --flavour= and --freeze1 --freeze2 there, too, to 
prevent recompilation.) Then I leave it to CI to do the full job.

Richard

> On Oct 11, 2021, at 3:23 PM, Norman Ramsey  wrote:
> 
> I've made a minor change to GHC, and before submitting a PR, I'd like to
> validate the change.  But I don't really know how to interpret the output
> of the `validate` script.  Mine runs for about 40 minutes and then ends
> in an error:
> 
>  # We are installing wrappers to programs by searching corresponding
>  # wrappers. If wrapper is not found, we are attaching the common wrapper
>  # to it. This implementation is a bit hacky and depends on consistency
>  # of program names. For hadrian build this will work as programs have a
>  # consistent naming procedure.
>  if [ -L wrappers/ghc ]; then echo "ghc is a symlink"; fi
>  ghc is a symlink
>  cp: target 'dir/bin/ghc' is not a directory
>  make: *** [Makefile:197: install_wrappers] Error 1
> 
>  
>  Executed in   39.60 minsfish   external
> usr time  146.65 mins0.00 millis  146.65 mins
> sys time9.55 mins1.60 millis9.55 mins
> 
> I'm in the process of trying `validate` on a fresh checkout, but at 40
> minutes per shot, I feel like I might be on the wrong track.  Should I
> just create a merge request and rely on CI for the validation?
> Or do something else?
> 
> 
> Norman
> 
> ___
> 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 can't arguments be levity polymorphic for inline functions?

[Richard Eisenberg]

> On Oct 8, 2021, at 10:51 AM, Ben Gamari  wrote:
> In my mind the fundamental problem with this approach is that it means
> that a program's acceptance by the compiler hinges upon pragmas.

I think being able to ignore pragmas is a worthy goal, but one we're rather far 
short of, at the moment: overlapping pragmas (as Chris has pointed out), 
language pragmas (!), options pragmas setting -Werror, plugin pragmas, maybe 
others.

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

Re: Why can't arguments be levity polymorphic for inline functions?

[Richard Eisenberg]

One significant problem is that {-# INLINE #-} functions are not actually 
always inlined! Specifically, if an inline-function is not passed all of its 
arguments, it will not be inlined. This poses a problem for levity-polymorphic 
functions, and GHC already does some special handling of the few 
levity-polymorphic primitives, in case they are ever used without all of their 
arguments.

As for boxing levity-polymorphic arguments: that's plausible, but then I think 
you've defeated the programmer's intended aim.

The solution to me is some kind of so-called template polymorphism 
. This might 
work, but it would take a fair amount of design work first.

Richard

> On Oct 7, 2021, at 7:36 PM, Clinton Mead  wrote:
> 
> Hi All
> 
> Not sure if this belongs in ghc-users or ghc-devs, but it seemed devy enough 
> to put it here. 
> 
> Section 6.4.12.1 
> 
>  of the GHC user manual points out, if we allowed levity polymorphic 
> arguments, then we would have no way to compile these functions, because the 
> code required for different levites is different. 
> 
> However, if such a function is {-# INLINE #-} or {-# INLINABLE #-} there's no 
> need to compile it as it's full definition is in the interface file. Callers 
> can just compile it themselves with the levity they require. Indeed callers 
> of inline functions already compile their own versions even without levity 
> polymorphism (for example, presumably inlining function calls that are known 
> at compile time).
> 
> The only sticking point to this that I could find was that GHC will only 
> inline the function if it is fully applied 
> ,
>  which suggests that the possibility of partial application means we can't 
> inline and hence need a compiled version of the code. But this seems like a 
> silly restriction, as we have the full RHS of the definition in the interface 
> file. The caller can easily create and compile it's own partially applied 
> version. It should be able to do this regardless of levity. 
> 
> It seems to me we're okay as long as the following three things aren't true 
> simultaneously:
> 
> 1. Blah has levity polymorphic arguments
> 2. Blah is exported
> 3. Blah is not inline
> 
> If a function "Blah" is not exported, we shouldn't care about levity 
> polymorphic arguments, because we have it's RHS on hand in the current module 
> and compile it as appropriate. And if it's inline, we're exposing it's full 
> RHS to other callers so we're still fine also. Only when these three 
> conditions combine should we give an error, say like:
> 
> "Blah has levity polymorphic arguments, is exported, and is not inline. 
> Please either remove levity polymorphic arguments, not export it or add an  
> {-# INLINE #-} or {-# INLINABLE #-} pragma.
> 
> I presume however there are some added complications that I don't understand, 
> and I'm very interested in what they are as I presume they'll be quite 
> interesting. 
> 
> Thanks,
> Clinton
> 
> ___
> 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 indecisive whether matching on GADT constructors in arrow notation is allowed

[Richard Eisenberg]

I think the real difference is whether new type variables are brought into 
scope. It seems that GHC can't deal with a proc-pattern-match that introduces 
type variables, but it *can* deal with introduced constraints. I have no idea 
*why* this is the case, but it seems a plausible (if accidental) resting place 
for the implementation.

Richard

> On Oct 3, 2021, at 12:19 PM, Alexis King  wrote:
> 
> Hi,
> 
> I’ve been working on bringing my reimplementation of arrow notation back up 
> to date, and I’ve run into some confusion about the extent to which arrow 
> notation is “supposed” to support matching on GADT constructors. Note [Arrows 
> and patterns] in GHC.Tc.Gen.Pat suggests they aren’t supposed to be supported 
> at all, which is what I would essentially expect. But issues #17423 
>  and #18950 
>  provide examples of using 
> GADT constructors in arrow notation, and there seems to be some expectation 
> that in fact they ought to be supported, and some recently-added test cases 
> verify that’s the case.
> 
> But this is quite odd, because it means the arrows test suite now includes 
> test cases that verify both that this is supported and that it isn’t… and all 
> of them pass! Here’s my understanding of the status quo:
> 
> Matching on constructors that bind bona fide existential variables is not 
> allowed, and this is verified by the arrowfail004 test case, which involves 
> the following program:
> 
> data T = forall a. T a
> 
> panic :: (Arrow arrow) => arrow T T
> panic = proc (T x) -> do returnA -< T x
> This program is rejected with the following error message:
> 
> arrowfail004.hs:12:15:
> Proc patterns cannot use existential or GADT data constructors
> In the pattern: T x
> Despite the previous point, matching on constructors that bind evidence is 
> allowed. This is enshrined in test cases T15175, T17423, and T18950, which 
> match on constructors like these:
> 
> data DecoType a where
>   DecoBool :: Maybe (String, String) -> Maybe (Int, Int) -> DecoType Bool
> data Point a where
>   Point :: RealFloat a => a -> Point a
> This seems rather contradictory to me. I don’t think there’s much of a 
> meaningful distinction between these types of matches, as they create 
> precisely the same set of challenges from the Core point of view… right? And 
> even if I’m wrong, the error message in arrowfail004 seems rather misleading, 
> since I would definitely call DecoBool and Point above “GADT data 
> constructors”.
> 
> So what’s the intended story here? Is matching on GADT constructors in arrow 
> notation supposed to be allowed or not? (I suspect this is really just yet 
> another case of “nobody really knows what’s ‘supposed’ to happen with arrow 
> notation,” but I figured I might as well ask out of hopefulness that someone 
> has some idea.)
> 
> Thanks,
> Alexis
> 
> ___
> 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 development with VSCode

[Richard Eisenberg]

Hi devs,

I have migrated to use VSCode instead of emacs. There are the usual switchover 
pains, but I'm mostly pleased. One particular point of pleasure was that I had 
to do nothing, at all, to get VSCode working within the GHC code base. (Well, I 
had to switch to Hadrian, but perhaps that's for the best.)

My problem: VSCode over GHC pins my processor at 100% if I edit anything. Any 
advice for fixing this?

A little more detail: When VSCode starts up, it spends a while "processing" and 
"indexing" (no idea what these mean). OK. I can pay that one-time cost. But as 
I start editing, etc., it needs to process and index a lot more. Somewhat 
continuously. This slows my computer down generally, and -- more annoyingly -- 
slows down my builds (run in a separate terminal).

I understand why VSCode wants to do this: it's checking my code for errors, 
etc. But is there a way to say "not now, please"? More specifically: I'd like 
to stop VSCode from detecting errors in my code while I'm actively editing. 
It's just too slow. On the other hand, it would be brilliant if VSCode could 
continue to allow me to, say, jump to definitions and gather references, using 
its latest knowledge of the code. As I edit, I understand this "latest 
knowledge" may become stale, if I'm stopping VSCode from reprocessing and 
reindexing. So, it would be nice to be able to tell VSCode to refresh, when I 
want that.

Any pointers here? 
https://gitlab.haskell.org/ghc/ghc/-/wikis/Visual-Studio-Code 
 would be a good 
place to put them!

Thanks,
Richard___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: More type safety in Core?

[Richard Eisenberg]

> On Sep 14, 2021, at 5:43 PM, Callan McGill  wrote:
> 
> Following on from Richard mentioning this paper and video there was an 
> extremely nice version of this done recently by Sam Derbyshire using type 
> checker plugins that is well worth a look to see what is involved: 
> https://github.com/sheaf/ghc-tcplugin-api/tree/main/examples/SystemF 
> <https://github.com/sheaf/ghc-tcplugin-api/tree/main/examples/SystemF>

I just want to amplify that Callan above in promoting Sam's work -- an 
unfortunate oversight on my part. Very cool how it works with the new plugins 
architecture!

Richard

> 
> Best,
> Callan
> 
> On Tue, 14 Sept 2021 at 15:44, Richard Eisenberg  <mailto:li...@richarde.dev>> wrote:
> Hi Ari,
> 
> This is a fine idea in theory, but (at present) a poor one in practice, for 
> at least the following reasons:
> 
> * GHC's internal language is based on System F, allowing polymorphism. 
> Modeling polymorphism in the way you describe is hard, even for a language 
> that supports full dependent types -- so much so that successfully doing it 
> (in Agda) is the subject of a recent peer-reviewed publication: 
> https://iohk.io/en/research/library/papers/system-f-in-agdafor-fun-and-profit/
>  
> <https://iohk.io/en/research/library/papers/system-f-in-agdafor-fun-and-profit/>
>There is some work on encoding System F in this way in Haskell, but it's 
> rough: 
> https://www.cis.upenn.edu/~plclub/blog/2020-06-26-Strongly-typed-System-F/ 
> <https://www.cis.upenn.edu/~plclub/blog/2020-06-26-Strongly-typed-System-F/>  
>  Note that GHC Core is significantly more complex than either of these more 
> modest languages.
> 
> * Core is manipulated a *lot*. Having intrinsic typing means, essentially, 
> that every optimization would have to be proved sound, in the compiler. This 
> is another thing that would be wonderful in theory, but we're just very far 
> away from being able to achieve this in practice.
> 
> * I don't think we'd save very much at all: any information used to make 
> runtime decisions must be present at runtime, and types are erased. So if we 
> did this, we'd still need to carry (likely via class constraints) lots of 
> information around to runtime. The difference would be that it would be 
> passed implicitly instead of explicitly, but doing this won't speed GHC up.
> 
> * I actually tried something like this while on holiday a few years ago: I 
> wanted to label Coercions with their role. This is a tempting subset of the 
> challenge you describe, because roles are very first-order (there are only 3 
> of them!) and yet hard to get right. My work ran into no dead ends, exactly, 
> but it quickly required lots and lots of fancy support structures. (For 
> example, we would need a finite map where both keys and values are indexed by 
> some role. And we'd need existentials. Lots of them.) If I had more time, I 
> might have finished this, but there are bigger fish to fry.
> 
> So: I'd be very happy with being able to do this as a long-term goal, but I'd 
> say we are years away from it -- and the best way toward it is simply adding 
> support for dependent types.
> 
> Richard
> 
>> On Sep 14, 2021, at 8:38 AM, Ari Fordsham > <mailto:arifords...@gmail.com>> wrote:
>> 
>> I don't know if this is the right forum for this, I apologise if I'm 
>> intruding...
>> 
>> Are there any plans to use the type system to enforce safety in Core, via 
>> e.g. GADTs? This would replace much of core-lint with static checking.
>> 
>> Conal Eliottt has done something similar in a blog post 
>> (http://conal.net/blog/posts/overloading-lambda#:~:text=Haskell%20source%20language.-,I,-originally%20intended%20to
>>  
>> <http://conal.net/blog/posts/overloading-lambda#:~:text=Haskell%20source%20language.-,I,-originally%20intended%20to>)
>>  and it seems relatively straightforward.
>> 
>> This would be especially beneficial to those working at the cutting edge of 
>> GHC features, statically ensuring their Core manipulations are correct. I 
>> would be surprised if existing compiler bugs wouldn't be found while 
>> implementing this.
>> 
>> What would the performance impact be? would using GADTs incur extra 
>> overhead? I'd assume you'd save something by lugging around less type 
>> information in Core.
>> 
>> Ari Fordsham
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org <mailto:ghc-devs@haskell.org>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs 
>> <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
> 
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org <mailto:ghc-devs@haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs 
> <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: More type safety in Core?

[Richard Eisenberg]

Hi Ari,

This is a fine idea in theory, but (at present) a poor one in practice, for at 
least the following reasons:

* GHC's internal language is based on System F, allowing polymorphism. Modeling 
polymorphism in the way you describe is hard, even for a language that supports 
full dependent types -- so much so that successfully doing it (in Agda) is the 
subject of a recent peer-reviewed publication: 
https://iohk.io/en/research/library/papers/system-f-in-agdafor-fun-and-profit/  
 There is some work on encoding System F in this way in Haskell, but it's 
rough: 
https://www.cis.upenn.edu/~plclub/blog/2020-06-26-Strongly-typed-System-F/   
Note that GHC Core is significantly more complex than either of these more 
modest languages.

* Core is manipulated a *lot*. Having intrinsic typing means, essentially, that 
every optimization would have to be proved sound, in the compiler. This is 
another thing that would be wonderful in theory, but we're just very far away 
from being able to achieve this in practice.

* I don't think we'd save very much at all: any information used to make 
runtime decisions must be present at runtime, and types are erased. So if we 
did this, we'd still need to carry (likely via class constraints) lots of 
information around to runtime. The difference would be that it would be passed 
implicitly instead of explicitly, but doing this won't speed GHC up.

* I actually tried something like this while on holiday a few years ago: I 
wanted to label Coercions with their role. This is a tempting subset of the 
challenge you describe, because roles are very first-order (there are only 3 of 
them!) and yet hard to get right. My work ran into no dead ends, exactly, but 
it quickly required lots and lots of fancy support structures. (For example, we 
would need a finite map where both keys and values are indexed by some role. 
And we'd need existentials. Lots of them.) If I had more time, I might have 
finished this, but there are bigger fish to fry.

So: I'd be very happy with being able to do this as a long-term goal, but I'd 
say we are years away from it -- and the best way toward it is simply adding 
support for dependent types.

Richard

> On Sep 14, 2021, at 8:38 AM, Ari Fordsham  wrote:
> 
> I don't know if this is the right forum for this, I apologise if I'm 
> intruding...
> 
> Are there any plans to use the type system to enforce safety in Core, via 
> e.g. GADTs? This would replace much of core-lint with static checking.
> 
> Conal Eliottt has done something similar in a blog post 
> (http://conal.net/blog/posts/overloading-lambda#:~:text=Haskell%20source%20language.-,I,-originally%20intended%20to
>  
> )
>  and it seems relatively straightforward.
> 
> This would be especially beneficial to those working at the cutting edge of 
> GHC features, statically ensuring their Core manipulations are correct. I 
> would be surprised if existing compiler bugs wouldn't be found while 
> implementing this.
> 
> What would the performance impact be? would using GADTs incur extra overhead? 
> I'd assume you'd save something by lugging around less type information in 
> Core.
> 
> Ari Fordsham
> ___
> 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: new label: diagnostic quality

[Richard Eisenberg]

Great idea! See 
https://github.com/haskellfoundation/tech-proposals/issues/12#issuecomment-916310039,
 which will eventually work its way into a more proper proposal.

Thanks,
Richard

> On Sep 7, 2021, at 9:04 PM, Chris Smith  wrote:
> 
> Oops, I meant to include this URL: 
> https://github.com/google/codeworld/issues?q=label%3Aerror-message+%22code.world%2Fhaskell%22
>  
> <https://github.com/google/codeworld/issues?q=label%3Aerror-message+%22code.world%2Fhaskell%22>
>  is the full list (including closed issues) of cases where someone has 
> reported a misleading error message at code.world/haskell
> 
> On Tue, Sep 7, 2021 at 9:03 PM Chris Smith  <mailto:cdsm...@gmail.com>> wrote:
> Hi Richard,
> 
> One thing that I've done with CodeWorld for years now was to integrate 
> reporting poor error messages into the core workflow by adding a report 
> button on the compiler output directly in the tool.  This integration files 
> github issues with a special tag for error messages.  Because CodeWorld is 
> targeted at younger users and already rewrites error messages, most of the 
> reports I get from CodeWorld itself are not directly applicable to GHC.  
> Here's a list of cases where someone clicked that button at 
> code.world/haskell, but I usually close them with no action unless there's 
> something egregious because I want code.world/haskell to be an authentic GHC 
> experience.  In any case, I strongly suggest looking into similar tooling for 
> more standard Haskell environments with editors like VSCode or Emacs.  I 
> don't know if this could be done in HLS, or would need to be separately 
> implemented for each editor.  I'll happily offer to implement a CodeWorld 
> endpoint for filing GitLab error message reports similar to this which such 
> integrations could post to.  The lower you can make the friction to report a 
> misleading message, the more likely you'll get authentic reports from users 
> rather than idle issue-theorizing.
> 
> These will probably need some kind of a triage process to turn them into 
> actionable issues, and perhaps in my experience to just close 75% of them 
> where it's unclear what was meant or the user just wanted to gripe.  (That 
> may have something to do with the fact that my users have often 
> procrastinated on their homework, though...)  But that triage process is 
> something that you could easily ask for help on.  I would be willing to comb 
> through reports now and then, for example, and look for opportunities to do 
> better.
> 
> On Tue, Sep 7, 2021 at 2:51 PM Richard Eisenberg  <mailto:li...@richarde.dev>> wrote:
> Hi devs,
> 
> I've just created a new label in GitLab, called "diagnostic quality". 
> (Diagnostics = errors ∪ warnings.) I intend for this label to be used when 
> the report is about the quality of an error message or warning. That is, the 
> existing message is not wrong, per se, but it's somehow not as helpful as it 
> can be to users. I think it's helpful to separate out such issues from those 
> describing error messages that are just wrong.
> 
> In particular, if you spot a ticket arising from 
> https://github.com/haskell/error-messages 
> <https://github.com/haskell/error-messages>, you may want to give it the 
> "diagnostic quality" label.
> 
> If you disagree with the choice to make this label, please push back!
> 
> Thanks,
> Richard
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org <mailto:ghc-devs@haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs 
> <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: New implementation for `ImpredicativeTypes`

[Richard Eisenberg]

> On Sep 6, 2021, at 11:21 AM, John Ericson  
> wrote:
> 
> On 9/2/21 11:04 PM, Richard Eisenberg wrote:
> 
>> On Sep 2, 2021, at 2:56 PM, john.ericson > <mailto:john.ericson@obsidian.systems>> wrote:
>>> 
>>> Does the most basic e.g.
>>> 
>>> newtype Some f where
>>>   MkSome :: forall a. f a -> Some f
>>> 
>>> Have one of those problematic equalities?
>> 
>> No. That's not a GADT -- the constructor doesn't restrict anything about `f`.
> Morally, sure, but GHC doesn't know about this.
> 

Sure it does -- GHC doesn't include an equality constraint as one of the fields 
of MkSome. This isn't about extensions -- it's about the way the data 
constructor is interpreted.
>> 
>> I think you're after newtype existentials. I think these should indeed be 
>> possible, because what you propose appears to be the same as
>> 
>> newtype Some f = MkSome (exists a. f a)
>> 
>> We can probably support the syntax you wrote, too, but I don't want to 
>> commit to that right now.
> The syntax I wrote is already basically valid?
> 
> data Some f = forall a. Some (f a)
> data Some f where MkSome :: forall a f. f a -> Some f
> Is accepted
> 
> newtype Some f = forall a. Some (f a)
> newtype Some f where MkSome :: forall a f. f a -> Some f
> Is not with "A newtype constructor cannot have existential type variables"
> 
> I propose we teach GHC how these "GADTs" in fact merely have existential 
> variables, and not the FC constraints that require the extra evaluation for 
> soundness. Than we can get the operational/runtime benefits of what you 
> propose for cheap. Don't get me wrong -- the other aspects in the paper this 
> doesn't address are still quite valuable, but I think this is a useful 
> stepping stone / removal of artificial restrictions we should do first.
> 
> This sort of thing is brought up in #1965, where it is alleged this is in 
> fact more difficult than it sounds. All more reason it is a good stepping 
> stone, I say!
> 

This is more difficult than it sounds. :) Newtypes are implemented via 
coercions in Core, and coercions are inherently bidirectional. The appearance 
of an existential in this way requires one-way conversions, which are currently 
not supported. So, to get what you want, we'd have to modify the core language 
as in the existentials paper, along with some extra work to automatically add 
`pack` and `open` -- rather similar to the type inference described in the 
existentials paper. The bottom line for me is that this seems just as hard as 
implementing the whole thing, so I see no value in having the stepping stone. 
If we always wrote out the newtype constructor, then maybe we could use its 
appearance to guide the `pack` and `open`, but we don't: sometimes, we just use 
`coerce`. So I really don't think this is any easier than implementing the 
paper as written. Once that's done, we can come back and add this new feature 
relatively easily (I think).

Richard

> John
> 

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

new label: diagnostic quality

[Richard Eisenberg]

Hi devs,

I've just created a new label in GitLab, called "diagnostic quality". 
(Diagnostics = errors ∪ warnings.) I intend for this label to be used when the 
report is about the quality of an error message or warning. That is, the 
existing message is not wrong, per se, but it's somehow not as helpful as it 
can be to users. I think it's helpful to separate out such issues from those 
describing error messages that are just wrong.

In particular, if you spot a ticket arising from 
https://github.com/haskell/error-messages, you may want to give it the 
"diagnostic quality" label.

If you disagree with the choice to make this label, please push back!

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

Re: New implementation for `ImpredicativeTypes`

[Richard Eisenberg]

> On Sep 2, 2021, at 2:56 PM, john.ericson  
> wrote:
> 
> Does the most basic e.g.
> 
> newtype Some f where
>   MkSome :: forall a. f a -> Some f
> 
> Have one of those problematic equalities?

No. That's not a GADT -- the constructor doesn't restrict anything about `f`.

I think you're after newtype existentials. I think these should indeed be 
possible, because what you propose appears to be the same as

newtype Some f = MkSome (exists a. f a)

We can probably support the syntax you wrote, too, but I don't want to commit 
to that right now.

Richard

> 
> 
>  On Thu, 02 Sep 2021 14:33:40 -0400 li...@richarde.dev wrote 
> 
> 
> 
> On Sep 2, 2021, at 2:10 PM, Alex Rozenshteyn  > wrote:
> 
> Oh, I see. That's because this would need to introduce `pack ... as ...` and 
> `open ...` into the core term language, right?
> 
> Exactly, yes.
> 
> 
> My sense is that it shouldn't negatively affect runtime performance of 
> programs without existentials even if implemented naively; does that seem 
> accurate? Not that implementing it, even naively, is a small task. 
> 
> I would agree with this, too.
> 
> On Sep 2, 2021, at 2:21 PM, john.ericson  > wrote:
> 
> This reminds me...can we do newtype GADTs in certain situations as a stepping 
> stone? I would think that would be purely easier — more nominal, no nice 
> projections but only `case` and skolems which cannot escape.
> 
> Newtype GADTs we're long deemed impossible IIRC, but surely the paper 
> demonstrates that at least some cases should work?
> 
> I don't quite see how this relates to existentials. Note that the paper does 
> not address e.g. packing equalities in existentials, which would be needed 
> for interacting with GADTs.
> 
> Glad folks are enjoying the paper! :)
> 
> Richard
> 
> 
> 
>  On Thu, 02 Sep 2021 14:10:34 -0400 rpglove...@gmail.com 
>  wrote 
> 
> Oh, I see. That's because this would need to introduce `pack ... as ...` and 
> `open ...` into the core term language, right?
> 
> My sense is that it shouldn't negatively affect runtime performance of 
> programs without existentials even if implemented naively; does that seem 
> accurate? Not that implementing it, even naively, is a small task. 
> 
> On Thu, Sep 2, 2021 at 1:44 PM Simon Peyton Jones  > wrote:
> Of course not. The same was true for QuickLook, though, wasn't it?
> 
> No, not at all.   QuickLook required zero changes to GHC’s intermediate 
> language – it impacted only the type inference system.   Adding existentials 
> will entail a substantial change to the intermediate language, affecting 
> every optimisation pass.
> 
>  
> 
> Simon
> 
>  
> 
> From: Alex Rozenshteyn mailto:rpglove...@gmail.com>> 
> Sent: 02 September 2021 18:13
> To: Simon Peyton Jones mailto:simo...@microsoft.com>>
> Cc: GHC developers mailto:ghc-devs@haskell.org>>
> Subject: Re: New implementation for `ImpredicativeTypes`
> 
>  
> 
> So it’s not just a question of saying “just add that paper to GHC and voila 
> job done”. 
> 
>  
> 
> Of course not. The same was true for QuickLook, though, wasn't it?
> 
>  
> 
> On Thu, Sep 2, 2021 at 12:42 PM Simon Peyton Jones  > wrote:
> 
> If I understand correctly, the recent ICFP paper "An Existential Crisis 
> Resolved 
> "
>  finally enables this; is that right?
> 
> It describes one way to include existentials in GHC’s intermediate language, 
> which is a real contribution. But it is not a small change.  So it’s not just 
> a question of saying “just add that paper to GHC and voila job done”.
> 
>  
> 
> Simon
> 
>  
> 
> From: Alex Rozenshteyn mailto:rpglove...@gmail.com>> 
> Sent: 02 September 2021 17:10
> To: Simon Peyton Jones mailto:simo...@microsoft.com>>
> Cc: GHC developers mailto:ghc-devs@haskell.org>>
> Subject: Re: New implementation for `ImpredicativeTypes`
> 
>  
> 
> If I understand correctly, the recent ICFP paper "An Existential Crisis 
> Resolved 
> "
>  finally enables this; is that right?
> 
>  
> 
> On Mon, Sep 9, 2019 at 12:00 PM Simon Peyton Jones  > wrote:
> 
> Suppose 

Re: New implementation for `ImpredicativeTypes`

[Richard Eisenberg]

> On Sep 2, 2021, at 2:10 PM, Alex Rozenshteyn  wrote:
> 
> Oh, I see. That's because this would need to introduce `pack ... as ...` and 
> `open ...` into the core term language, right?

Exactly, yes.

> 
> My sense is that it shouldn't negatively affect runtime performance of 
> programs without existentials even if implemented naively; does that seem 
> accurate? Not that implementing it, even naively, is a small task. 

I would agree with this, too.

> On Sep 2, 2021, at 2:21 PM, john.ericson  
> wrote:
> 
> This reminds me...can we do newtype GADTs in certain situations as a stepping 
> stone? I would think that would be purely easier — more nominal, no nice 
> projections but only `case` and skolems which cannot escape.
> 
> Newtype GADTs we're long deemed impossible IIRC, but surely the paper 
> demonstrates that at least some cases should work?

I don't quite see how this relates to existentials. Note that the paper does 
not address e.g. packing equalities in existentials, which would be needed for 
interacting with GADTs.

Glad folks are enjoying the paper! :)

Richard

> 
> 
>  On Thu, 02 Sep 2021 14:10:34 -0400 rpglove...@gmail.com wrote 
> 
> Oh, I see. That's because this would need to introduce `pack ... as ...` and 
> `open ...` into the core term language, right?
> 
> My sense is that it shouldn't negatively affect runtime performance of 
> programs without existentials even if implemented naively; does that seem 
> accurate? Not that implementing it, even naively, is a small task. 
> 
> On Thu, Sep 2, 2021 at 1:44 PM Simon Peyton Jones  > wrote:
> Of course not. The same was true for QuickLook, though, wasn't it?
> 
> No, not at all.   QuickLook required zero changes to GHC’s intermediate 
> language – it impacted only the type inference system.   Adding existentials 
> will entail a substantial change to the intermediate language, affecting 
> every optimisation pass.
> 
>  
> 
> Simon
> 
>  
> 
> From: Alex Rozenshteyn mailto:rpglove...@gmail.com>> 
> Sent: 02 September 2021 18:13
> To: Simon Peyton Jones mailto:simo...@microsoft.com>>
> Cc: GHC developers mailto:ghc-devs@haskell.org>>
> Subject: Re: New implementation for `ImpredicativeTypes`
> 
>  
> 
> So it’s not just a question of saying “just add that paper to GHC and voila 
> job done”. 
> 
>  
> 
> Of course not. The same was true for QuickLook, though, wasn't it?
> 
>  
> 
> On Thu, Sep 2, 2021 at 12:42 PM Simon Peyton Jones  > wrote:
> 
> If I understand correctly, the recent ICFP paper "An Existential Crisis 
> Resolved 
> "
>  finally enables this; is that right?
> 
> It describes one way to include existentials in GHC’s intermediate language, 
> which is a real contribution. But it is not a small change.  So it’s not just 
> a question of saying “just add that paper to GHC and voila job done”.
> 
>  
> 
> Simon
> 
>  
> 
> From: Alex Rozenshteyn mailto:rpglove...@gmail.com>> 
> Sent: 02 September 2021 17:10
> To: Simon Peyton Jones mailto:simo...@microsoft.com>>
> Cc: GHC developers mailto:ghc-devs@haskell.org>>
> Subject: Re: New implementation for `ImpredicativeTypes`
> 
>  
> 
> If I understand correctly, the recent ICFP paper "An Existential Crisis 
> Resolved 
> "
>  finally enables this; is that right?
> 
>  
> 
> On Mon, Sep 9, 2019 at 12:00 PM Simon Peyton Jones  > wrote:
> 
> Suppose Haskell did have existentials;
> 
>  
> 
> Yes, I think that’s an interesting thing to work on!  I’m not sure what the 
> implications would be.  At very least we’d need to extend System FC (GHC’s 
> intermediate language) with existential types and the corresponding pack and 
> unpack syntactic forms.
> 
>  
> 
> I don’t know of any work studying that question specifically, but others may 
> have pointers.
> 
>  
> 
> simon
> 
>  
> 
> From: Alex Rozenshteyn mailto:rpglove...@gmail.com>> 
> Sent: 06 September 2019 15:21
> To: Simon Peyton Jones mailto:simo...@microsoft.com>>
> Cc: Alejandro Serrano Mena mailto:trup...@gmail.com>>; 
> GHC developers mailto:ghc-devs@haskell.org>>
> Subject: Re: New implementation for `ImpredicativeTypes`
> 
>  
> 
> Hi Simon,
> 
>  
> 
> 

GHC plugin authors?

[Richard Eisenberg]

Hi all,

I have seen a few posts from Sam Derbyshire here asking for feedback about 
plugin API design, and the responses have been minimal. This poses a design 
challenge, because the GHC folk who design the interface are sometimes distinct 
from the people who use the interface. We're trying to be good, seeking 
feedback from real, live clients. Is there a better way to do so than this 
mailing list? Example: we could create a Category on discourse.haskell.org, if 
that would reach the audience better. Or we could make a repo with issue 
trackers somewhere simply to track plugin design. What would work?

(I recognize that I'm asking in a perhaps-ineffective channel for advice, but I 
really don't have a better idea right now. Maybe some of you plugin authors are 
here and will point us in a better direction.)

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

Re: How to set idScope properly when converting LhsExpr GhcPs to CoreExpr?

[Richard Eisenberg]

I took a look at this today. I found

> Note [GlobalId/LocalId]
> ~~~
> A GlobalId is
>   * always a constant (top-level)
>   * imported, or data constructor, or primop, or record selector
>   * has a Unique that is globally unique across the whole
> GHC invocation (a single invocation may compile multiple modules)
>   * never treated as a candidate by the free-variable finder;
> it's a constant!
> 
> A LocalId is
>   * bound within an expression (lambda, case, local let(rec))
>   * or defined at top level in the module being compiled
>   * always treated as a candidate by the free-variable finder
> 
> After CoreTidy, top-level LocalIds are turned into GlobalIds

This suggests that the output you're seeing -- with "lid" in QQQ and "gid" in 
PPP -- is correct. What has drawn your attention to this problem? Is there 
something else that's misbehaving?

Thanks,
Richard

> On Aug 25, 2021, at 4:16 PM, Yiyun Liu  wrote:
> 
> Hi all,
> 
> We have a function in Liquidhaskell's code base for converting
> refinement expressions into GHC's core expressions using the GHC API.
> Its implementation is based on tcRnExpr
> except
> we keep the typechecked expression and desugar it before returning.
> 
> However, our function fails to set the idScope information properly when
> LiquidHaskell is invoked as a plugin (installed as a
> typeCheckResultAction). This repo
> contains a minimal
> example that demonstrates the issue. In the CoreExpr returned by
> elabRnExpr
> ,
> every symbol from the current module that's being compiled is labeled as
> local. The README.md file shows how the exported symbol testPlus is
> marked as local in QQQ.hs, the module where it's defined.
> 
> Is there a function we should call to set the idScope information properly?
> 
> Thanks,
> 
> -Yiyun
> 
> ___
> 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: Can NamedFieldPuns be added to `GHC.LanguageExtensions.Types.Extension`?

[Richard Eisenberg]

I think we just go ahead and rename the constructor. We don't have back-compat 
guarantees at this level. Simplicity is a virtue, too!

Thanks,
Richard

> On Jul 6, 2021, at 5:59 AM, Alfredo Di Napoli  
> wrote:
> 
> 
> Hello Simon,
> 
> Yes, renaming and perhaps keeping `RecordPuns` as a pattern synonym to not 
> break backward-compat, if that's feasible to define as we are in 
> `ghc-boot-th` here. Not sure if `PatternSynonyms` and `COMPLETE` would be 
> available there.
> 
> I am not sure how many libs that depend on the ghc API would break (I haven't 
> grepped on Hackage yet), but that might tip the benefits/troubles ratio 
> towards keeping the status quo.
> 
> This is not a "problem" I have to solve today, and it might not be considered 
> a problem by others (just an inconsistency I guess): as a colleague of mine 
> pointed out, GHC is not necessarily "lying" here. It's still the same 
> underlying extension, it just happens that there are two names that refer to 
> it.
> 
> Perhaps I could think about adding to `GhcHint` some kind of mapping which 
> would give to IDEs or third-party libs the correct extension name given an 
> input `LangExt.Extension`, the problem then becomes making sure that we keep 
> this mapping in sync with the information contained in `GHC.Driver.Session`.
> 
> I will let it simmer.
> 
> Thanks!
> 
> A.
> 
> On Tue, 6 Jul 2021 at 11:19, Simon Peyton Jones  > wrote:
> 1. What prevents us from adding `NamedFieldPuns` as a proper constructor for 
> the `Extension` type and in principle remove `RecordPuns`? Backward 
> compatibility I assume?
> 
> You mean, essentially, rename `LangExt.RecordPuns` to `NamedFieldPuns`.
> 
>  
> 
> I’d be fine with that.  There might be back-compat issues, but only with 
> other plugins, and probably with vanishingly few of them.  Grep in Hackage!
> 
>  
> 
> Simon
> 
>  
> 
> From: ghc-devs  > On Behalf Of Alfredo Di Napoli
> Sent: 06 July 2021 10:14
> To: Simon Peyton Jones via ghc-devs  >
> Subject: Can NamedFieldPuns be added to 
> `GHC.LanguageExtensions.Types.Extension`?
> 
>  
> 
> Dear all,
> 
>  
> 
> As some of you might know, for the past few months I have been working on 
> changing GHC's diagnostic messages from plain SDocs to richer Haskell types.
> 
>  
> 
> As part of this work, I have added a mechanism to embed hints into 
> diagnostics, defined in `GHC.Types.Hint` in `HEAD`. One of the main workhorse 
> of this `GhcHint` type is the `SuggestExtension LangExt.Extension` 
> constructor, which embeds the extension to enable to use a particular 
> feature. The `LangExt.Extension` type comes from 
> `GHC.LanguageExtensions.Types`, and up until now there has always been a 1:1 
> mapping between the language pragma for the extension and the type itself.
> 
>  
> 
> Today I was working on turning this error into a proper Haskell type:
> 
>  
> 
> badPun :: Located RdrName -> TcRnMessage
> 
> badPun fld = TcRnUnknownMessage $ mkPlainError noHints $
> 
>   vcat [text "Illegal use of punning for field" <+> quotes (ppr fld),
> 
> text "Use NamedFieldPuns to permit this"]
> 
>  
> 
> I was ready to yield a `SuggestExtension LangExt.NamedFieldPuns` when I 
> discovered that there is no `NamedFieldPuns` constructor. Rather, there is a 
> `RecordPuns` , which refer to a deprecated flag, and we simply map 
> `NamedFieldPuns` back to it in `GHC.Driver.Session`:
> 
>  
> 
> ...
> 
>   depFlagSpec' "RecordPuns"   LangExt.RecordPuns
> 
> (deprecatedForExtension "NamedFieldPuns"),
> 
> ...
> 
>   flagSpec "NamedFieldPuns"   LangExt.RecordPuns,
> 
> ...
> 
>  
> 
> This is problematic for the `GhcHint` type, because now if I was to yield 
> `SuggestExtension LangExt.RecordPuns` to the user, I could still pretty-print 
> the suggestion to turn `RecordPuns` into `NamedFieldPuns`, but this means 
> that IDEs or third-party library would have access to the 
> 
> "raw" Haskell datatype, and at that point they will be stuck with a 
> suggestion to enable a deprecated extension! (or best case scenario they will 
> have to transform the suggestion into something more sensible, which 
> partially defeats the point of this refactoring work I have been doing).
> 
>  
> 
> I am not sure this behaviour is unique for just `NamedFieldPuns`, but my 
> question is:
> 
>  
> 
> 1. What prevents us from adding `NamedFieldPuns` as a proper constructor for 
> the `Extension` type and in principle remove `RecordPuns`? Backward 
> compatibility I assume?
> 
>  
> 
>  
> 
> Many thanks,
> 
>  
> 
> Alfredo
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> ___
> 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

Re: Breaking changes to the base library

[Richard Eisenberg]

> On Jun 20, 2021, at 10:57 AM, Edward Kmett  wrote:
> 
> We definitely need to do more to communicate that this is changing and how 
> users should adjust their code to suit.

Yes, I agree! Who is responsible for actually doing this communication, though? 
I don't think it should just be tucked into the release notes. This will be a 
major source of breakage in the next release.

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

Re: Trying to speedup GHC compile times...Help!

[Richard Eisenberg]

One piece I'm curious about, reading this thread: why do we have so many 
IntMaps and operations on them? Name lookup is a fundamental operation a 
compiler must do, and that would use an IntMap: good. But maybe there are other 
IntMaps used that are less necessary. A key example: whenever we do 
substitution, we track an InScopeSet, which is really just an IntMap. This 
InScopeSet remembers the name of all variables in scope, useful when we need to 
create a new variable name (this is done by uniqAway). Yet perhaps the tracking 
of these in-scope variables is very expensive and comprises much of the IntMap 
time. Might it be better just to always work in a monad capable of giving fresh 
names? We actually don't even need a monad, if that's too annoying. Instead, we 
could just pass around an infinite list of fresh uniques. This would still be 
clutterful, but if it grants us a big speed improvement, the clutter might be 
worth it.

The high-level piece here is that there may be good things that come from 
understanding where these IntMaps arise.

Richard

> On Jul 2, 2021, at 4:08 AM, Simon Peyton Jones via ghc-devs 
>  wrote:
> 
> Jeff
>  
> Great stuff!  Welcome.
>  
> I strongly urge you to keep a constantly-update status wiki page, which lists 
> the ideas you are working on, and points to relevant resources and tickets.  
> An email thread like this is a good way to gather ideas, but NOT a good way 
> to organise and track them.
>  
> Looking carefully at profiles is a good plan.  That’s the hard data!
>  
> I think that some careful investigation of IntMap (at least the bits that GHC 
> uses heavily) would be a good idea.  Clearly we spend a lot of time in these 
> maps, so speedups here will yield a lot of benefit.  Look at the heavy 
> hitters from the profile, stare at the Core code and see if it’s s good as it 
> can be.
>  
> For example, Sebastian discovered a strange infelicity in IntMap.lookup, 
> which I’ve documented in a new ticket
> https://gitlab.haskell.org/ghc/ghc/-/issues/20069 
> <https://gitlab.haskell.org/ghc/ghc/-/issues/20069>
>  
> I think it’d also be worth measuring how unbalanced our IntMap trees get.  See
>https://gitlab.haskell.org/ghc/ghc/-/issues/19820 
> <https://gitlab.haskell.org/ghc/ghc/-/issues/19820>
> The speculation there is that we are getting very unbalanced trees.  So 
> measure it!  If it’s true, we could improve matters by using a different 
> IntMap; or maybe by scrambling the key a bit --- see the ticket.
>  
> Simon
>  
> From: ghc-devs  On Behalf Of Young, Jeff
> Sent: 02 July 2021 02:36
> To: ghc-devs@haskell.org
> Subject: Trying to speedup GHC compile times...Help!
>  
> Hi ghc devs,
> 
>  
> 
> I'm a long-time Haskeller but am just getting into GHC development. I started 
> a 12 week internship at Tweag I/O under Richard Eisenberg this week with the 
> singular goal to speedup GHC compile times. I'm specifically looking to 
> contribute to ghc issues 18541 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F18541=04%7C01%7Csimonpj%40microsoft.com%7C8a3369ac28654df6f08008d93cf9e28b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637607867394069068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=Zh5dzhUSjwsZdmr8B3G5T49CssX%2Bv8IGcHILRp8Ekjc%3D=0>and
>  18535 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F18535=04%7C01%7Csimonpj%40microsoft.com%7C8a3369ac28654df6f08008d93cf9e28b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637607867394079062%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=2I%2BQXmd%2Bn1nGz%2Bcr0qvhq9BLkKCucJkedPNxu7RpKSw%3D=0>.
>  So I thought I would reach out to the community to get some direction on 
> issues/features/problems to tackle in the pursuit of faster compilation 
> times. This is a full time internship and so I think there is a real 
> opportunity to nail down a deliverable for the community, but I want to get 
> some guidance from the experts (you fine people!) before going down a rabbit 
> hole.
> 
>  
> 
> To be specific I'm looking for lingering items such as:
> 
>   1. It would be great if we had  but no one has time.
> 
>   2. Primop foo is half complete but is the right type for 
> .
> 
>   3. Swap  to an array-like type non-incrementally, that is, 
> establish a patch that rips out the previous type and replaces it with the 
> array-like across the entire compiler, rather than module-by-module.
> 
>  
> 
> Point 2 is a specific reference to MR 3571 
> <https://nam06.safe

Re: Anyone ever wondered what our favourite merge bot is up to?

[Richard Eisenberg]

This sounds fantastic!

But when I visit that page, I see the attached, which does not appear to have 
much information. Am I doing something wrong?

Thanks,
Richard



> On Jun 9, 2021, at 6:29 AM, Matthew Pickering  
> wrote:
> 
> Hi all,
> 
> I added a new dashboard on grafana which exposes some of the systemd
> logs from marge-bot.
> 
> https://grafana.gitlab.haskell.org/d/iiCppweMz/marge-bot?orgId=2=5m
> 
> You can use the logs to see why marge doesn't want to merge your MR or
> whether she is dead.
> 
> 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: value of documenting error messages?

[Richard Eisenberg]

> On Jun 2, 2021, at 2:48 PM, Tom Ellis 
>  wrote:
> 
> On Wed, Jun 02, 2021 at 06:13:17PM +0000, Richard Eisenberg wrote:
>> I'm in favor of short, undescriptive, quite-possibly numeric error
>> codes.
> 
> These responses are so completely opposite to what I expected that I
> can't help thinking I've made a fundamental error in my understanding
> of what we're trying to achieve!  Since no one has suggested any
> support for the idea of descriptive error codes I'm pressing on mostly
> in the hope that someone will be able to see from where my
> misunderstanding arises and set me straight.

I see no place where our understandings have diverged, just our opinions. But I 
may be missing something, too, of course! (For the record, I don't see your 
suggestion as unreasonable; I just think it's inferior to terse non-descriptive 
identifiers.)

> 
> Before I continue, I'd like to suggest that this is very much a
> user-facing issue and I would be strongly in favour of actually asking
> users about what they prefer (and allowing them to discuss for a
> while) rather than taking a straw poll amongst GHC developers.
> 
> To that end, would it be inappropriate of me to link this discussion
> to Haskell Reddit and/or Haskell Discourse?

Not this discussion, but I think a discussion there is a good idea. This thread 
started as a question about documenting constructors in the GHC source code, 
and it has (rightly!) moved to be about documenting error messages more 
generally. I (myopically) had not connected these two, and I'm glad for the 
direction this has taken. But I think the user-facing discussion should have a 
different starting point than this thread.

I don't think I currently have the bandwidth for that discussion, but if no one 
else starts it, I will before too much longer.

> 
> I don't understand at all why it's valuable to sequentialize.  Is the
> relative ordering of error codes meaningful in some way?

No. Sequentialization is good because it allows for the production of a new, 
unique member of the class, with a minimum of storage requirements (that is, 
you just store the greatest such member, and you know the next one up is 
unique).

> 
> I don't see why deprecating an error code and reintroducing it is a
> problem any more than doing the same to a function or GHC extension.

It is definitely worse than a function, because functions are associated with a 
particular version. If GHC 9 and GHC 13 have a function of the same name but 
different meanings, I don't see how that causes trouble.

Extensions and error codes, on the other hand, are more troublesome, because 
they get documented and discussed widely online, and web pages live forever. 
And it is currently sometimes problematic when extensions change meaning over 
time, leading to conversations I've seen about adding version numbers to 
extensions. I don't think we've had an extension disappear and then reappear, 
because removing an extension is very, very hard. Error messages, on the hand, 
will be much more fluid.

> 
> 
>> Easy to make compositional. We can choose to have all GHC error
>> codes begin with G (for GHC). Then Cabal could use C, Haddock could
>> use H, and Stack could use S. This makes it easy for users to tell
>> (once they've learned the scheme) where an error has come from.
> 
> Surely the same holds for descriptive error codes.  One could have
> G_conflicting_trait_implementations, H_malformatted_section_header,
> ...

Yes, I thought you might say that. But now these are mixed, with an opaque 
component and a more descriptive one. Better would be 
ghc_conflicting_trait_implementations, but that's even longer!

> 
>> Short.
> 
> Again I must be misunderstanding.  Why is brevity valuable?  Aren't we
> expecting users to read these things and look them up?  Copy/paste is
> free.

Short things are easier to format? Yes, I agree that brevity is harder to 
motivate here. Yet I also think that, say, pasting the entire error message 
text would be wrong, too. So why do we want abbreviations at all? I think: it's 
to be sure we're looking up what we intend to look up, something served nicely 
by guaranteed uniqueness.

> 
>> No chance for misspellings during transcription. When I'm copying a
>> terse identifier, I know I have to get every glyph correct. If I
>> remember that the error code is "bad_generalizing", I might not know
>> how "generalizing" is spelled. I might also forget whether it's
>> "generalizing" or "generalization". And I could very easily see
>> myself making either both of these mistakes as I'm switching from
>> one window to another, in under a second.
> 
> Surely it's just as easy to mistype E159 as E195 as it is to misspell
> "generalise".  As above, 

Re: value of documenting error messages?

[Richard Eisenberg]

I'm in favor of short, undescriptive, quite-possibly numeric error codes.

Advantages:
* Easy to sequentialize. We might have, for example, a 
"conflicting_trait_implementations" from this year, move on from that design, 
and then accidentally reintroduce it in a decade, to confusion. Along similar 
lines, it is easy to write in a comment somewhere what the next error code 
should be, without having to search the codebase for a use.
* Easy to make compositional. We can choose to have all GHC error codes begin 
with G (for GHC). Then Cabal could use C, Haddock could use H, and Stack could 
use S. This makes it easy for users to tell (once they've learned the scheme) 
where an error has come from.
* Short.
* No chance for misspellings during transcription. When I'm copying a terse 
identifier, I know I have to get every glyph correct. If I remember that the 
error code is "bad_generalizing", I might not know how "generalizing" is 
spelled. I might also forget whether it's "generalizing" or "generalization". 
And I could very easily see myself making either both of these mistakes as I'm 
switching from one window to another, in under a second.

Disadvantages:
* The code does not impart semantic meaning. But I argue this is not so bad, as 
even a more descriptive code does not impart a precise enough semantic meaning 
to be helpful.

> On Jun 2, 2021, at 1:49 PM, Tom Ellis 
>  wrote:
> 
> If we really think that non-descriptive codes are the clearest way to
> communicate between machines and humans then I wonder if we should
> rename `mapAccumL` to `F392` and `TypeFamilies` to `X56`.

I think this is a false equivalence. The error codes are meant to be looked up 
when you see them on your screen, not remembered and then produced at will.

---

Surfacing up a few levels: it sounds like a good next step is not to get all 
these constructors finely documented, but instead to come up with a way to 
connect these constructors to user-facing documentation. This might be done by 
slurping out Markdown from the GHC source code, or perhaps something better. It 
would be a shame to invest a lot of effort in documenting the constructors in a 
way that serves only GHC developers, not end users, when we can perhaps do both 
at the same time.

Thanks,
Richard___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

value of documenting error messages?

[Richard Eisenberg]

Hi devs,

Take a quick look at 
https://gitlab.haskell.org/ghc/ghc/-/blob/6db8a0f76ec45d47060e28bb303e9eef60bdb16b/compiler/GHC/Driver/Errors/Types.hs#L107
 

  You will see a datatype there with constructors describing error messages 
that GHC might produce. These constructors have comments describing the error, 
sometimes giving an example, and sometimes listing test cases. More datatypes 
like this one and more constructors in these datatypes are on the way.

Question: Is there sufficient value in carefully documenting each constructor?

In my ideal world, each constructor would have a high-level description, a 
detailed description of each field, an example of a program that generates the 
error, and one or more test cases that test the output. Along the way, we might 
discover that no such test case exists, and then we would add. However, 
generating this documentation is hard. I was thinking of whipping up an army of 
volunteers (Hécate has advised me how to do this) to do the work, but that army 
will need to be fed (with instructions, supervision, and reviews) and will want 
to know that their work is important. Is this effort worthwhile? Do we see 
ourselves maintaining this documentation? Or is the effort better spent 
elsewhere, perhaps tagging each constructor with an ID and then making wiki 
pages? Not sure what's best -- would love ideas!

Credit to Alfredo di Napoli, who's done the heavy lifting of getting us this 
far.

Relevant tickets: 
Original: https://gitlab.haskell.org/ghc/ghc/-/issues/18516
Tasks left: https://gitlab.haskell.org/ghc/ghc/-/issues/19905

Thanks,
Richard___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GitLab downtime

[Richard Eisenberg]

GitLab appears to be back up. However, access via ssh tells me

@@@
@   WARNING: POSSIBLE DNS SPOOFING DETECTED!  @
@@@
The ED25519 host key for gitlab.haskell.org has changed,
and the key for the corresponding IP address 147.75.105.243
is unknown. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
@@@
@WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

This kind of error seems in keeping with the upgrade you've done, but I want 
explicit reassurance that I should proceed in the face of this error.

Thanks!
Richard

> On May 31, 2021, at 4:23 PM, Ben Gamari  wrote:
> 
> Ben Gamari mailto:b...@well-typed.com>> writes:
> 
>> Ben Gamari  writes:
>> 
>>> Hi all,
>>> 
>>> Today I'm going to be working on migrating our GitLab instance to a new
>>> machine. Starting in likely an hour there will be a few hours of
>>> downtime while the migration proceeds. I will send an email when the
>>> downtime begins and concludes.
>>> 
>> Hi all,
>> 
>> A brief update: The GitLab downtime has not yet started as the migration
>> preparation has taken a bit longer than expected. As it is getting late,
>> I will be postponing the downtime until tomorrow evening.
>> 
>> Sorry for the inconvenience!
> 
> Hi all,
> 
> As noted yesterday I will be continue the GitLab migration starting in
> around 45 minutes. Do expect a bit of outage starting at that time.
> 
> 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: Productivity Tip from mpickering

[Richard Eisenberg]

Could you add this insight to the wiki somewhere, so we can find it later? 
https://gitlab.haskell.org/ghc/ghc/-/wikis/building/hadrian 
 seems like the 
right place.

Thanks!
Richard

> On May 26, 2021, at 7:47 AM, Matthew Pickering  
> wrote:
> 
> Hi,
> 
> I am now using a new flavour combination which is proving *very* nice
> as a compromise between fast recompiles and passing tests.
> 
> My normal build command is now:
> 
> ./hadrian/build --flavour=default+no_profiled_libs+omit_pragmas --freeze1 -j
> 
> This has the effect of
> 
> * base libraries are compiled with optimisation
> * Profiling libraries are not built
> * Stage 1 compiler is compiled with -O + -fomit-interface-pragmas, so
> recompilation behaviour is much better.
> 
> The end result is a nearly clean testsuite run (I think there are two
> failures) but much faster iterations when modifying `compiler/*`.
> 
> 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: Coding style: Using StandaloneKindSignatures in GHC

[Richard Eisenberg]

I agree with Chris here.

Let me expand upon my counter-proposal:

* A datatype declaration gets a standalone kind signature whenever at least one 
of its type arguments has a kind other than Type.
* A class declaration gets a standalone kind signature whenever at least one of 
its type arguments has a kind other than Type.(*)
* A closed type family always gets a standalone kind signature.
* A type synonym gets a standalone kind signature whenever either at least one 
of its arguments has a kind other than Type or its result has a kind other than 
Type.

(*) The class rule has an exception: if a class has a superclass constraint 
using Monad, Functor, Applicative, Foldable, or Traversable (or some other 
class whose name textually includes one of those names, such as MonadIO), we 
understand that the constrained variable must have kind Type -> Type. If that 
type variable is the only one without kind Type -> Type, then the standalone 
kind signature is optional.

In cases other than those covered above, the standalone kind signature is 
optional, at the discretion of the programmer.

This suggests that Dict gets a signature, Eq does not, Fix does, and Either 
does not.

Richard

> On May 21, 2021, at 12:37 PM, Chris Smith  wrote:
> 
> On Fri, May 21, 2021 at 2:11 AM Baldur Blöndal  > wrote:
> > encouraging the use of a standalone signature for type declarations where 
> > at least one parameter of the datatype does not have kind Type.
> 
> So Dict, Eq both get a sig but Fix and Either do not?
> 
>   type Dict :: Constraint -> Type
>   type Eq   :: Type -> Constraint
>   type Fix  :: (Type -> Type) -> Type
> 
>  That's not how I understand Richard's criteria.  Dict and Fix have non-Type 
> parameters (Dict has a Constraint parameter, and Fix has a (Type -> Type) 
> parameter.  On the other hand, Eq and Either have only Types as parameters.  
> This seems to match my intuition about when a kind signature might be 
> helpful, as well as yours as far as I can tell from what you wrote.
> 
> That's not to say I am advocating any kind of rule.  As I'm not really 
> involved in GHC development, I refrain from having any opinion.  I just think 
> you may have misread Richard's suggestion.

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

Re: Coding style: Using StandaloneKindSignatures in GHC

[Richard Eisenberg]

Perhaps surprisingly, I'm against this proposal as part of the GHC style guide, 
for one reason: the vast majority of types within GHC have kind Type. 
Annotating all of these with a standalone kind signature just adds noise -- we 
can see they have kind Type just by seeing they have no parameter.

On the other hand, I'm in support of encouraging the use of a standalone kind 
signature for type declarations where at least one parameter of the datatype 
does not have kind Type. In fact, I'd be in support of mandating (such as we 
can) such a standalone kind signature in our style guide. The cases where at 
least one parameter of a datatype does not have kind Type are the places we 
need the extra information.

As for the naming conflict, that's fairly easy: we already have a GhcPrelude, 
and we can add, e.g. type T = Type to it.

Richard

> On May 18, 2021, at 2:28 PM, Oleg Grenrus  wrote:
> 
> First you have to solve the not so nice name clash of GHC...Type [1] and
> Data.Kind.Type [2]
> 
> The former is all over the GHC code base, the latter is needed for
> (most) kind signatures, as * is not an option.
> 
> - Oleg
> 
> [1]:
> https://downloads.haskell.org/ghc/latest/docs/html/libraries/ghc-9.0.1/GHC-Tc-Utils-TcType.html#t:Type
> [2]:
> https://hackage.haskell.org/package/base-4.15.0.0/docs/Data-Kind.html#t:Type
> 
> On 18.5.2021 21.18, Hécate wrote:
>> After reading this proposal, I agree that StandaloneKindSignatures
>> ought to be encouraged in the codebases, and I vote that we mention
>> them in the coding style¹.
>> 
>> Cheers,
>> Hécate
>> 
>> ———
>> ¹ https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/coding-style
>> 
>> Cheers,
>> Hécate.
>> 
>> Le 18/05/2021 à 19:58, Baldur Blöndal a écrit :
>>> Discussion to permit use of StandaloneKindSignatures in the GHC coding
>>> style guide. I believe it increases the clarity of the code,
>>> especially as we move to fancier kinds.
>>> 
>>> It is the only way we have for giving full signatures to type
>>> synonyms, type classes, type families and others. An example:
>>> 
>>>  type Cat :: Type -> Type
>>>  type Cat ob = ob -> ob -> Type
>>> 
>>>  type  Category :: forall ob. Cat ob -> Constraint
>>>  class Category cat where
>>>id :: cat a a ..
>>> 
>>>  type Proxy :: forall k. k -> Type
>>>  data Proxy a = Proxy
>>> 
>>>  type Some :: forall k. (k -> Type) -> Type
>>>  data Some f where
>>>Some :: f ex -> Some f
>>> 
>>>  -- | The regular function type
>>>  type (->) :: forall {rep1 :: RuntimeRep} {rep2 :: RuntimeRep}.
>>> TYPE1 rep1 -> TYPE rep2 -> Type
>>>  type (->) = FUN 'Many
>>> 
>>> This is in line with function definitions that are always given a
>>> top-level, standalone type signature (1) and not like we currently
>>> define type families/synonyms (2) by annotating each argument or not
>>> at all. Using -XStandaloneKindSignatures (3) matches (1)
>>> 
>>>  -- (1)
>>>  curry :: ((a, b) -> c) -> (a -> b -> c)
>>>  curry f  x y = f (x, y)
>>> 
>>>  -- (2)
>>>  type Curry (f :: (a, b) -> c) (x :: a) (y :: b) =  f '(x, y) :: c
>>> 
>>>  -- (3)
>>>  type Curry :: ((a, b) -> c) -> (a -> b -> c)
>>>  type Curry f x y = f '(x, y)
>>> 
>>> It covers an edgecase that `KindSignatures` don't. The only way for
>>> deriving to reference datatype arguments is if they are quantified by
>>> the declaration head -- `newtype Bin a ..`. StandaloneKindSignatures
>>> allows us to still provide a full signature. We could write `newtype
>>> Bin a :: Type -> Type` without it but not `newtype Bin :: Type -> Type
>>> -> Type`
>>> 
>>>  typeBin :: Type -> Type -> Type
>>>  newtype Bin a b = Bin (a -> a -> b)
>>>deriving (Functor, Applicative)
>>>via (->) a `Compose` (->) a
>>> 
>>> Let me know what you think
>>> ___
>>> 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

an issue tracker for better error messages

[Richard Eisenberg]

Hi devs,

I've just posted 
https://discourse.haskell.org/t/proposal-an-issue-tracker-for-better-error-messages/2498
 
,
 a description of an idea to create an issue tracker dedicated only to error 
messages. My hope is that the tracker is used to boil issues users have with 
error messages down to a concrete suggestion for a wording change -- and that 
only when we have that concrete suggestion will a ticket be made on the GHC 
tracker.

What do we think here of this idea? If you have a thought about the overall 
idea, I invite you to comment on Discourse; if you have a thought about GHC's 
response to this, this list seems like the best venue.

Thanks,
Richard___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: structured error messages

[Richard Eisenberg]

> On May 3, 2021, at 3:11 PM, Chris Smith  wrote:
> 
> Thanks, Richard.  This is awesome!

Glad you're excited. I am, too!

> 
> For my use case, the more exciting possibility would be to interact with 
> error messages from JavaScript.  For this reason, I'd definitely love to see 
> a well-known structured file format (JSON, YAML, XML, or whatever) that can 
> be read without linking against GHC.  I also like the idea of producing both 
> the structured data and the raw string, since as you mention, one shouldn't 
> need to handle every single possible GHC diagnostic just to add some special 
> handling for a few of them.
> 
> Ultimately, if reading error messages did require linking with GHC, it 
> wouldn't be the end of the world.  I would just write my own translation 
> layer to JSON.  So consider this a weak preference.

It would be straightforward to, say, define instances of ToJSON and FromJSON 
for all of our error types. We could then serialize to JSON. The problem would 
be that these error types are likely to wibble and wobble between releases. 
(For now, I would say even between minor releases.) So if you don't link 
against GHC, you would have to stay on your toes to keep your parser 
up-to-date. Maybe this feature will settle down into a rhythm, and we can start 
to promise more stability, but I think it would be a mistake to promise that 
too soon. Linking against GHC protects you from making a mistake in this 
regard. On the other hand, the JSON output would be perfectly well formed 
independently of GHC, so there would be no hard requirement to do this linking.

So that's one vote for JSON (where the JSON also includes the rendered string). 
Do I hear any others? (Note that these different modes of interaction are all 
pretty easy to build -- the hard part is the infrastructure supporting them -- 
so we can likely do more than one.)

Thanks,
Richard

> 
> On Mon, May 3, 2021 at 3:00 PM Richard Eisenberg  <mailto:r...@richarde.dev>> wrote:
> Hi all,
> 
> Alfredo and I are hard at work redesigning GHC's error-message system. It is 
> time for more input, though, from clients of the system -- those writing IDEs 
> and other tooling on top of GHC.
> 
> The key question: How would you like your errors served?
> 
> Right now, errors are served well-done: fully cooked into structureless 
> strings that can be easily given to users. The problem with this is that IDEs 
> cannot easily intervene between GHC and the users, as all the nutrition (that 
> is, detailed information) has been cooked away.
> 
> The new design allows for *structured errors*, where error messages are 
> represented by elements of some error type. Different messages have different 
> constructors of this type, and these constructors can carry auxiliary 
> information. GHC will store these errors raw and cook them (that is, turn 
> them into readable strings) only right before printing them. If the raw 
> messages were somehow passed to IDEs, then IDEs could handle them 
> non-uniformly. (For example, if a module name and a file name are different, 
> the IDE could just present a dialog to the user asking whether the user would 
> like to change one automatically.) 
> 
> There are a few open questions:
> 
> * In what vessel shall the raw messages be served? In other words, how do 
> IDEs expect to interact with this new system?
>   - One route would be to pass e.g. -fjson-errors, which means that GHC 
> presents the raw messages in a JSON format, for IDEs to parse. That's OK, but 
> it still means that IDEs would have to have their own raw error message types 
> to parse into.
>   - Another route would be for the IDE to link against GHC itself, and then 
> invoke the compiler via a function call that returns the raw messages 
> directly.
>   - Another route is some kind of middle ground, where the IDE passes e.g. 
> -fbinary-errors= instructing GHC to write out a binary encoding of 
> its messages to some file (or pipe, I suppose). These could then be 
> deserialized back into GHC's own error types, but running in a separate 
> process (linked against GHC, once again).
>   - I'm sure you can come up with other interaction strategies.
> 
> * What will an IDE do with these messages? It might have special handling for 
> some, but GHC has a lot of different messages, and I imagine IDEs will want 
> many just to be printed to the user. If an IDE has only the raw message, then 
> the IDE is forced to do all the cooking -- no good. So there must be a way to 
> take a raw message and render it into a user-readable string.
>   - Maybe the above methods produce both the raw error and the rendered one? 
> Then the IDE can choose which it prefers to use.
>   - GHC could easily export its pretty-printing functions that take in t

structured error messages

[Richard Eisenberg]

Hi all,

Alfredo and I are hard at work redesigning GHC's error-message system. It is 
time for more input, though, from clients of the system -- those writing IDEs 
and other tooling on top of GHC.

The key question: How would you like your errors served?

Right now, errors are served well-done: fully cooked into structureless strings 
that can be easily given to users. The problem with this is that IDEs cannot 
easily intervene between GHC and the users, as all the nutrition (that is, 
detailed information) has been cooked away.

The new design allows for *structured errors*, where error messages are 
represented by elements of some error type. Different messages have different 
constructors of this type, and these constructors can carry auxiliary 
information. GHC will store these errors raw and cook them (that is, turn them 
into readable strings) only right before printing them. If the raw messages 
were somehow passed to IDEs, then IDEs could handle them non-uniformly. (For 
example, if a module name and a file name are different, the IDE could just 
present a dialog to the user asking whether the user would like to change one 
automatically.) 

There are a few open questions:

* In what vessel shall the raw messages be served? In other words, how do IDEs 
expect to interact with this new system?
  - One route would be to pass e.g. -fjson-errors, which means that GHC 
presents the raw messages in a JSON format, for IDEs to parse. That's OK, but 
it still means that IDEs would have to have their own raw error message types 
to parse into.
  - Another route would be for the IDE to link against GHC itself, and then 
invoke the compiler via a function call that returns the raw messages directly.
  - Another route is some kind of middle ground, where the IDE passes e.g. 
-fbinary-errors= instructing GHC to write out a binary encoding of 
its messages to some file (or pipe, I suppose). These could then be 
deserialized back into GHC's own error types, but running in a separate process 
(linked against GHC, once again).
  - I'm sure you can come up with other interaction strategies.

* What will an IDE do with these messages? It might have special handling for 
some, but GHC has a lot of different messages, and I imagine IDEs will want 
many just to be printed to the user. If an IDE has only the raw message, then 
the IDE is forced to do all the cooking -- no good. So there must be a way to 
take a raw message and render it into a user-readable string.
  - Maybe the above methods produce both the raw error and the rendered one? 
Then the IDE can choose which it prefers to use.
  - GHC could easily export its pretty-printing functions that take in the raw 
messages and produce rendered ones. But that (again) requires linking against 
GHC.

Note that we are not (here, yet) discussing errors served at points between raw 
and well-done, though I would like to do so. Such an error would be rendered 
into a format where textual bits are interleaved with more structured bits, 
which would enable e.g. clicking on expressions within error messages to get 
their types. That (important feature) comes separately.

So: what do consumers want here?

Preview: You can take a look at some raw error messages from the driver in 
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5533 
.

Thanks!
Richard___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

linting GHC

[Richard Eisenberg]

Hi devs,

I see in CI that we're now linting the GHC source code. In order to avoid CI 
failure, I would like to lint locally, and I somehow know (though I forget 
where I learned it) that hadrian/build lint:compiler is the way to do this. 
After building hlint, I am able to do this. But the output is surprising; here 
is the tail:

# hlint (for lint:compiler)
compiler/GHC/Tc/Utils/Unify.hs:2:1-36: Warning: Unused LANGUAGE pragma
Found:
  {-# LANGUAGE MultiWayIf #-}
Perhaps you should remove it.

compiler/stage1/build/GHC/Parser.hs:6:1-29: Warning: Unused LANGUAGE pragma
Found:
  {-# LANGUAGE ViewPatterns #-}
Perhaps you should remove it.

compiler/stage1/build/GHC/Parser.hs:8:1-27: Warning: Unused LANGUAGE pragma
Found:
  {-# LANGUAGE LambdaCase #-}
Perhaps you should remove it.

compiler/stage1/build/GHC/Parser.hs:38:1-54: Warning: Use fewer imports
Found:
  import Control.Monad ( unless, liftM, when, (<=<) )
  import Control.Monad ( ap )
  
Perhaps:
  import Control.Monad ( unless, liftM, when, (<=<), ap )
  

compiler/stage1/build/GHC/Parser.hs:43:1-18: Warning: Use fewer imports
Found:
  import GHC.Prelude
  import GHC.Prelude
  
Perhaps:
  import GHC.Prelude
  

compiler/stage1/build/GHC/Cmm/Parser.hs:17:1-24: Warning: Use fewer imports
Found:
  import GHC.StgToCmm.Prof
  import GHC.StgToCmm.Prof
  
Perhaps:
  import GHC.StgToCmm.Prof
  

compiler/stage1/build/GHC/Cmm/Parser.hs:71:1-20: Warning: Use fewer imports
Found:
  import Control.Monad
  import Control.Monad ( ap )
  
Perhaps:
  import Control.Monad
  

compiler/stage2/build/GHC/Parser.hs:6:1-29: Warning: Unused LANGUAGE pragma
Found:
  {-# LANGUAGE ViewPatterns #-}
Perhaps you should remove it.

compiler/stage2/build/GHC/Parser.hs:8:1-27: Warning: Unused LANGUAGE pragma
Found:
  {-# LANGUAGE LambdaCase #-}
Perhaps you should remove it.

compiler/stage2/build/GHC/Parser.hs:38:1-54: Warning: Use fewer imports
Found:
  import Control.Monad ( unless, liftM, when, (<=<) )
  import Control.Monad ( ap )
  
Perhaps:
  import Control.Monad ( unless, liftM, when, (<=<), ap )
  

compiler/stage2/build/GHC/Parser.hs:43:1-18: Warning: Use fewer imports
Found:
  import GHC.Prelude
  import GHC.Prelude
  
Perhaps:
  import GHC.Prelude
  

compiler/stage2/build/GHC/Cmm/Parser.hs:17:1-24: Warning: Use fewer imports
Found:
  import GHC.StgToCmm.Prof
  import GHC.StgToCmm.Prof
  
Perhaps:
  import GHC.StgToCmm.Prof
  

compiler/stage2/build/GHC/Cmm/Parser.hs:71:1-20: Warning: Use fewer imports
Found:
  import Control.Monad
  import Control.Monad ( ap )
  
Perhaps:
  import Control.Monad
  

13 hints
Error when running Shake build system:
  at want, called at src/Main.hs:104:30 in main:Main
* Depends on: lint:compiler
  at cmd_, called at src/Rules/Lint.hs:70:3 in main:Rules.Lint
* Raised the exception:
Development.Shake.cmd, system command failed
Command line: hlint -j --cpp-define x86_64_HOST_ARCH --cpp-include=includes 
--cpp-include=_build/stage1/lib --cpp-include=compiler 
--cpp-include=_build/stage1/lib/ghcplatform.h 
--cpp-include=_build/stage1/compiler/build -h compiler/.hlint.yaml compiler
Exit code: 1
Stderr:

There are several curiosities here:

* I introduced one of these errors, in GHC.Tc.Utils.Unify; the other errors are 
in files I have not modified. Will these affect CI?
* Hadrian crashes at the end. Is that expected? It says "system command failed" 
with a bunch of gobbledegook. Is this an error within Hadrian? Or is this just 
Hadrian's way of saying that it encountered an error when linting? If it's the 
latter, the current message is hard to read.
* As you may be able to see, I use a dark-background terminal window. The 
colors output by the hlint process are nigh impossible to read when describing 
redundant LANGUAGE pragmas. Are these colors configurable?

Thanks!
Richard___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: simple Haskell help needed on #19746

[Richard Eisenberg]

> On Apr 27, 2021, at 3:32 PM, Sebastian Graf  wrote:
> 
> Hi Richard,
> 
> Maybe I lack a bit of context, but I don't see why you wouldn't choose (3).
> Extending the lexer/parser will yield a declarative specification of what 
> exactly constitutes a GHC_OPTIONS pragma (albeit in a language that isn't 
> Haskell) and should be more efficient than `reads`, even if you fix it to 
> scale linearly. Plus, it seems that's what we do for other pragmas such as 
> RULE already.

(3) is tempting indeed. There are two problems:

A. The code that parses strings isn't actually declarative. See 
https://gitlab.haskell.org/ghc/ghc/-/blob/d2399a46a01a6e46c831c19e797e656a0b8ca16d/compiler/GHC/Parser/Lexer.x#L1965.
 In particular note the comment: "This stuff is horrible. I hates it." 
Evidently written by Simon M in 2003 with the introduction of alex.

B. We need this code outside the lexer, to deal with e.g. :set in GHCi.

> On Apr 27, 2021, at 4:28 PM, Iavor Diatchki  wrote:
> 
> ... gather ...

Aha! That was the magic incantation I needed but did not have. Many thanks, 
Iavor.

The curious can see 
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5509/diffs?commit_id=a560fcbbc7d4e37c4909385c55839f793b570e68#c1078a9741c11d1e15d4c678b107092790295bb3_308_317
 for the final result.

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

simple Haskell help needed on #19746

[Richard Eisenberg]

Hi devs,

tl;dr: Is there any (efficient) way to get the String consumed by a `reads`?

I'm stuck in thinking about a fix for #19746. Happily, the problem is simple 
enough that I could assign it in the first few weeks of a Haskell course... and 
yet I can't find a good solution! So I pose it here for inspiration.

The high-level problem: Assign correct source spans to options within a 
OPTIONS_GHC pragma.

Current approach: The payload of an OPTIONS_GHC pragma gets turned into a 
String and then processed by GHC.Utils.Misc.toArgs :: String -> Either String 
[String]. The result of toArgs is either an error string (the Left result) or a 
list of lexed options (the Right result).

A little-known fact is that Haskell strings can be put in a OPTIONS_GHC pragma. 
So I can write both {-# OPTIONS_GHC -funbox-strict-fields #-} and {-# 
OPTIONS_GHC "-funbox-strict-fieds" #-}. Even stranger, I can write {-# 
OPTIONS_GHC ["-funbox-strict-fields"] #-}, where GHC will understand a list of 
strings. While I don't really understand the motivation for this last feature 
(I posted #19750 about this), the middle option, with the quotes, seems like it 
might be useful.

Desired approach: change toArgs to have this type: RealSrcLoc -> String -> 
Either String [Located String], where the input RealSrcLoc is the location of 
the first character of the input String. Then, as toArgs processes the input, 
it advances the RealSrcLoc (with advanceSrcLoc), allowing us to create correct 
SrcSpans for each String.

Annoying fact: Not all characters advance the source location by one character. 
Tabs and newlines don't. Perhaps some other characters don't, too.

Central stumbling block: toArgs uses `reads` to parse strings. This makes great 
sense, because `reads` already knows how to convert Haskell String syntax into 
a proper String. The problem is that we have no idea what characters were 
consumed by `reads`. And, short of looking at the length of the remainder 
string in `reads` and comparing it to the length of the input string, there 
seems to be no way to recreate this lost information. Note that comparing 
lengths is slow, because we're dealing with Strings here. Once we know what was 
consumed by `reads`, then we can just repeatedly call advancedSrcLoc, and away 
we go.

Ideas to get unblocked:
1. Just do the slow (quadratic in the number of options) thing, looking at the 
lengths of strings often.
2. Reimplement reading of strings to return both the result and the characters 
consumed
3. Incorporate the parsing of OPTIONS_GHC right into the lexer

It boggles me that there isn't a better solution here. Do you see one?

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

instance {Semigroup, Monoid} (Bag a) ?

[Richard Eisenberg]

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

Re: Why TcLclEnv and DsGblEnv need to store the same IORef for errors?

[Richard Eisenberg]

> On Mar 30, 2021, at 4:57 AM, Alfredo Di Napoli  
> wrote:
> 
> I'll explore the idea of adding a second IORef.

Renaming/type-checking is already mutually recursive. (The renamer must call 
the type-checker in order to rename -- that is, evaluate -- untyped splices. I 
actually can't recall why the type-checker needs to call the renamer.) So we 
will have a TcRnError. Now we see that the desugarer ends up mixed in, too. We 
could proceed how Alfredo suggests, by adding a second IORef. Or we could just 
make TcRnDsError (maybe renaming that).

What's the disadvantage? Clients will have to potentially know about all the 
different error forms with either approach (that is, using my combined type or 
using multiple IORefs). The big advantage to separating is maybe module 
dependencies? But my guess is that the dependencies won't be an issue here, due 
to the fact that these components are already leaning on each other. Maybe the 
advantage is just in having smaller types? Maybe.

I don't have a great sense as to what to do here, but I would want a clear 
reason that e.g. the TcRn monad would have two IORefs, while other monads will 
work with GhcMessage (instead of a whole bunch of IORefs).

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

Re: Type inference of singular matches on GADTs

[Richard Eisenberg]

As usual, I want to separate out the specification of a feature from the 
implementation. So let's just focus on specification for now -- with the caveat 
that there might be no possible implementation of these ideas.

The key innovation I see lurking here is the idea of an *exhaustive* function, 
where we know that any pattern-match on an argument is always exhaustive. I 
will write such a thing with @->, in both the type and in the arrow that 
appears after the lambda. The @-> type is a subtype of -> (and perhaps does not 
need to be written differently from ->).

EX1: \x @-> case x of HNil -> blah

This is easy: we can infer HList '[] @-> blah's type, because the pattern match 
is declared to be exhaustive, and no other type grants that property.

EX2: \x @-> (x, case x of HNit -> blah)

Same as EX1.

EX3: \x @-> case x of { HNil1 -> blah; HNil2 -> blah }

Same as EX1. There is still a unique type for which the patten-match is 
exhaustive.

EX4: Reject. There are multiple valid types, and we don't know which one to 
pick. This is like classic untouchable-variables territory.

EX5: This is hard. A declarative spec would probably choose HL2 [a] -> ... as 
you suggest, but there may be no implementation of such an idea.

EX6: Reject. No type leads to exhaustive matches.

I'm not saying this is a good idea for GHC or that it's implementable. But the 
idea of having type inference account for exhaustivity in this way does not 
seem, a priori, unspecified.

Richard



> On Mar 29, 2021, at 5:00 AM, Simon Peyton Jones  wrote:
> 
> I haven't thought about how to implement such a thing. At the least, it would 
> probably require some annotation saying that we expect `\HNil -> ()` to be 
> exhaustive (as GHC won't, in general, make that assumption). Even with that, 
> could we get type inference to behave? Possibly.
>  
> As I wrote in another post on this thread, it’s a bit tricky. 
>  
> What would you expect of (EX1)
>  
>\x -> case x of HNil -> blah
>  
> Here the lambda and the case are separated
>  
> Now (EX2)
>  
> \x -> (x, case x of HNil -> blah)
>  
> Here the lambda and the case are separated more, and x is used twice.
> What if there are more data constructors that share a common return type? 
> (EX3)
>  
> data HL2 a where
> HNil1 :: HL2 []
> HNil2 :: HL2 []
> HCons :: …blah…
>  
> \x -> case x of { HNil1 -> blah; HNil 2 -> blah  }
>  
> Here HNil1 and HNil2 both return HL2 [].   Is that “singular”?   
>  
> What if one was a bit more general than the other?   Do we seek the least 
> common generalisation of the alternatives given? (EX4)
>  
> data HL3 a where
> HNil1 :: HL2 [Int]
> HNil2 :: HL2 [a]
> HCons :: …blah…
>  
> \x -> case x of { HNil1 -> blah; HNil 2 -> blah  }
>  
> What if the cases were incompatible?  (EX5)
>  
> data HL4 a where
> HNil1 :: HL2 [Int]
> HNil2 :: HL2 [Bool]
> HCons :: …blah…
>  
> \x -> case x of { HNil1 -> blah; HNil 2 -> blah  }
>  
> Would you expect that to somehow generalise to `HL4 [a] -> blah`?
> 
> What if x matched multiple times, perhaps on different constructors (EX6)
> 
> \x -> (case s of HNil1 -> blah1;  case x of HNil2 -> blah)
>  
>  
> The water gets deep quickly here.  I don’t (yet) see an obviously-satisfying 
> design point that isn’t massively ad-hoc.
>  
> Simon
>  
>  
> From: ghc-devs  On Behalf Of Richard Eisenberg
> Sent: 29 March 2021 03:18
> To: Alexis King 
> Cc: ghc-devs@haskell.org
> Subject: Re: Type inference of singular matches on GADTs
>  
>  
> 
> 
> On Mar 26, 2021, at 8:41 PM, Alexis King  <mailto:lexi.lam...@gmail.com>> wrote:
>  
> If there’s a single principal type that makes my function well-typed and 
> exhaustive, I’d really like GHC to pick it.
>  
> I think this is the key part of Alexis's plea: that the type checker take 
> into account exhaustivity in choosing how to proceed.
>  
> Another way to think about this:
>  
> f1 :: HList '[] -> ()
> f1 HNil = ()
>  
> f2 :: HList as -> ()
> f2 HNil = ()
>  
> Both f1 and f2 are well typed definitions. In any usage site where both are 
> well-typed, they will behave the same. Yet f1 is exhaustive while f2 is not. 
> This isn't really about an open-world assumption or the possibility of extra 
> cases -- it has to do with what the runtime behaviors of the two functions 
> are. f1 never fails, while f2 must check a constructor tag and perhaps throw 
> an exception.
>  
> If we just see \HNil -> (), Alexis seems to be suggesting we prefer the f1 
> interpretation over the f2 interpretation. Why? Because f1 is exhaustive, and 
> when we can choose an exhaustive interpreta

Re: Type inference of singular matches on GADTs

[Richard Eisenberg]

> On Mar 26, 2021, at 8:41 PM, Alexis King  wrote:
> 
> If there’s a single principal type that makes my function well-typed and 
> exhaustive, I’d really like GHC to pick it.

I think this is the key part of Alexis's plea: that the type checker take into 
account exhaustivity in choosing how to proceed.

Another way to think about this:

> f1 :: HList '[] -> ()
> f1 HNil = ()
> 
> f2 :: HList as -> ()
> f2 HNil = ()

Both f1 and f2 are well typed definitions. In any usage site where both are 
well-typed, they will behave the same. Yet f1 is exhaustive while f2 is not. 
This isn't really about an open-world assumption or the possibility of extra 
cases -- it has to do with what the runtime behaviors of the two functions are. 
f1 never fails, while f2 must check a constructor tag and perhaps throw an 
exception.

If we just see \HNil -> (), Alexis seems to be suggesting we prefer the f1 
interpretation over the f2 interpretation. Why? Because f1 is exhaustive, and 
when we can choose an exhaustive interpretation, that's probably a good idea to 
pursue.

I haven't thought about how to implement such a thing. At the least, it would 
probably require some annotation saying that we expect `\HNil -> ()` to be 
exhaustive (as GHC won't, in general, make that assumption). Even with that, 
could we get type inference to behave? Possibly.

But first: does this match your understanding?

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

Re: HLint in the GHC CI, an eight-months retrospective

[Richard Eisenberg]

Thanks for this update! Glad to know this effort is going well.

One quick question: suppose I am editing something in `base`. My understanding 
is that my edit will be linted. How can I run hlint locally so that I can 
easily respond to trouble before CI takes a crack? And where would I learn this 
information (that is, how to run hlint locally)?

Thanks!
Richard

> On Mar 25, 2021, at 11:19 AM, Hécate  wrote:
> 
> Hello fellow devs,
> 
> this email is an activity report on the integration of the HLint[0] tool in 
> the Continuous Integration (CI) pipelines.
> 
> On Jul. 5, 2020 I opened a discussion ticket[1] on the topic of code linting 
> in the several components of the GHC code-base. It has served as a reference 
> anchor for the Merge Requests (MR) that stemmed from it, and allowed us to 
> refine our expectations and processes. If you are not acquainted with its 
> content, I invite you to read the whole conversation.
> 
> Subsequently, several Hadrian lint rules have been integrated in the 
> following months, in order to run HLint on targeted components of the GHC 
> repository (the base library, the compiler code-base, etc).
> Being satisfied with the state of the rules we applied to the code-base, such 
> as removing extraneous pragmata and keywords, it was decided to integrate the 
> base library linting rule in the CI. This was five months ago, in 
> September[2], and I am happy to report that developer friction has been so 
> far minimal.
> In parallel to this work on the base library, I took care of cleaning-up the 
> compiler, and harmonised the various micro coding styles that have emerged 
> quite organically during the decades of development that are behind us (I 
> never realised how many variations of the same ten lines of pragmata could 
> coexist in the same folders).
> Upon feedback from stakeholders of this sub-code base, the rules file was 
> altered to better suit their development needs, such as not removing 
> extraneous `do` keywords, as they are useful to introduce a block in which 
> debug statements can be easily inserted.
> 
> Since today, the linting of the compiler code-base has been integrated in our 
> CI pipelines, without further burdening our CI times.
> Things seem to run smoothly, and I welcome comments and requests of any kind 
> related to this area of our code quality process.
> 
> Regarding our future plans, there has been a discussion about integrating 
> such a linting mechanism for our C code-base, in the RTS. Nothing is formally 
> established yet, so I would be grateful if people who have experience and 
> wisdom about it can chime in to contribute to the discussion: 
> https://gitlab.haskell.org/ghc/ghc/-/issues/19437.
> 
> And I would like to say that I am overall very thankful for the involvement 
> of the people who have been giving us feedback and have been reviewing the 
> resulting MRs.
> 
> Have a very nice day,
> Hécate
> 
> ---
> [0]: https://github.com/ndmitchell/hlint
> [1]: https://gitlab.haskell.org/ghc/ghc/-/issues/18424
> [2]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4147
> 
> -- 
> Hécate ✨
> : @TechnoEmpress
> IRC: Uniaika
> WWW: https://glitchbra.in
> RUN: BSD
> 
> ___
> 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: On CI

[Richard Eisenberg]

What about the case where the rebase *lessens* the improvement? That is, you're 
expecting these 10 cases to improve, but after a rebase, only 1 improves. 
That's news! But a blanket "accept improvements" won't tell you.

I'm not hard against this proposal, because I know precise tracking has its own 
costs. Just wanted to bring up another scenario that might be factored in.

Richard

> On Mar 24, 2021, at 7:44 AM, Andreas Klebinger  
> wrote:
> 
> After the idea of letting marge accept unexpected perf improvements and
> looking at https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4759
> which failed because of a single test, for a single build flavour
> crossing the
> improvement threshold where CI fails after rebasing I wondered.
> 
> When would accepting a unexpected perf improvement ever backfire?
> 
> In practice I either have a patch that I expect to improve performance
> for some things
> so I want to accept whatever gains I get. Or I don't expect improvements
> so it's *maybe*
> worth failing CI for in case I optimized away some code I shouldn't or
> something of that
> sort.
> 
> How could this be actionable? Perhaps having a set of indicator for CI of
> "Accept allocation decreases"
> "Accept residency decreases"
> 
> Would be saner. I have personally *never* gotten value out of the
> requirement
> to list the indivial tests that improve. Usually a whole lot of them do.
> Some cross
> the threshold so I add them. If I'm unlucky I have to rebase and a new
> one might
> make it across the threshold.
> 
> Being able to accept improvements (but not regressions) wholesale might be a
> reasonable alternative.
> 
> Opinions?
> 
> ___
> 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: Configuration documentation (Was Re: GitLab is down: urgent)

[Richard Eisenberg]

Thanks, Gershom, for the quick and very illuminating response.

> On Mar 19, 2021, at 2:21 PM, Gershom B  wrote:
> 
> Cc: ad...@haskell.org which remains (since it was set up over five?
> years ago) the contact address for haskell infra admin stuff.

How would I learn of that address? Who is ad...@haskell.org?

> There's
> also, as there has always been, the #haskell-infrastructure irc
> channel.

How would I learn of this?

> 
> This all _used_ to be on phabricator (and was on the haskell wiki
> before that) but it wasn't really suited to port over nicely to
> gitlab. At the request of the still-forming working group for HF, a
> repo was created on github with key information and policy, and sent
> to the HF, which should have this documented somewhere already:
> https://github.com/haskell-infra/haskell-admins

This is exactly the kind of stuff I was looking for. (Apologies for your need 
to repeat yourself -- we are still working hard to organize ourselves out of 
the void.)

How would I find this page? Perhaps just a link from the Committees section of 
https://www.haskell.org/community/ would be sufficient. Might also be good to 
put ad...@haskell.org in the footer.

> 
> I'll go back and try to read earlier in the thread, if I was cc'd,
> because I'm just now looped in?
> 
> I.e. I see from the message "gitlab is down" but other than that I'm
> not sure exactly what is at issue?

The thread morphed into a new topic, thanks to me. I was just wondering who I 
would reach out to if both GitLab and Ben were down. The haskell-admins repo 
answers that question nicely.

> 
> -g
> 
> ---
> 
> Davean, Herbert, Ben and me are the ones who have keys on almost every
> box, I think. Alp and Austin are both officially team members but I
> haven't interacted with them much (austin is legacy, and alp may only
> work with Ben on ghc stuff, idk).

This seems out of sync with https://github.com/haskell-infra/haskell-admins, 
which does not list Ben (or Austin or Alp) but does list Rick Elrod. I would 
think that dormant members (e.g. Austin) should be removed, but that's your 
call.

> 
> Davean manages backups.

Is this documented somewhere? Backups of what?

> 
> some significant subdomains hosted: archives.haskell.org,
> hoogle.haskell.org, downloads.haskell.org, wiki.haskell.org
> 
> there are some other smaller subdomains such as summer.haskell.org,
> pvp.haskell.org, etc.
> 
> here are  the main static subsites of haskell.org, most of which have
> existed at those urls well prior to the existence of a haskell.org
> website beyond the wiki
> 
> alexcommunities  ghc-perf  happy  hoogle  onlinereport
> 
> arrows  definition   ghcup haskell-symposium  hugsplatform
> 
> cabal   ghc  haddock   haskell-workshop   nhc98   tutorial

This stuff appears to be on 
https://github.com/haskell-infra/haskell-admins/blob/master/servers.md. Good. I 
was originally looking for each of these to have names associated with them, 
but perhaps if one needed to contact the owner of a particular subdomain, we 
could reach out to ad...@haskell.org and then get the subdomain owners by 
dereference. That's fine by me.

> 
> Sadly, joachim didn't keep up ghc-perf which was nice while it was working.

I think this is perf.haskell.org. To be fair, some of the failure belongs on my 
shoulders. I offered up an unused server at Bryn Mawr (my previous employer) to 
host this, but that situation proved to be flaky. Actually, my best guess is 
that the server is still actually alive (and in the basement of my old 
building) at perf.haskell.org, but not being updated. I don't think we should 
rely on it.

So: Howard, there may not be much work to do here, beyond emailing Gershom, as 
you've already done! :)

Richard

> 
> On Fri, Mar 19, 2021 at 2:13 PM  wrote:
>> 
>> Hi Richard, Gershom and Ben,
>> 
>> I have access to the server that runs the Haskell wiki. There are other
>> websites on that server as well. I can document them as well. I know
>> that Gershom B. has done most (all?) of the work on that server. I ask
>> him and the haskell.org committee to send me or point me at whatever
>> documentation they have already.
>> 
>> I ask Ben and others with any documentation of gitlab.haskell.org to
>> send me or point me at whatever they have already.
>> 
>> I don't want to do this alone. Other volunteers are welcome! I also
>> will abide by the Haskell Foundation and the haskell.org committee in
>> arranging this documentation according to their needs and preferences.
>> 
>> Howard
>> 
>> On Fri, 2021-03-19 at 17:32 +, Richard Eisenberg wrote:
>>> 
>>> 
>>>> On Mar 19, 2021, at 12:44 PM, howard.b.gol...@gmail.c

Re: Configuration documentation (Was Re: GitLab is down: urgent)

[Richard Eisenberg]

Thanks, Howard!

> On Mar 19, 2021, at 2:13 PM, howard.b.gol...@gmail.com wrote:
> 
> I also
> will abide by the Haskell Foundation and the haskell.org committee in
> arranging this documentation according to their needs and preferences.

Thanks for this explicit comment, but I don't think there are specific needs / 
preferences -- just to have the information out there. And it seems there is 
much more information than I thought, as we see in Gershom's email, to which I 
will respond shortly.

Richard

> 
> Howard
> 
> On Fri, 2021-03-19 at 17:32 +, Richard Eisenberg wrote:
>> 
>> 
>>> On Mar 19, 2021, at 12:44 PM, howard.b.gol...@gmail.com wrote:
>>> 
>>> I would like to help however I can. I already maintain the Haskell
>>> wiki, and I would like to improve and document its configuration
>>> using
>>> devops techniques, preferably consistent with gitlab.haskell.org.
>> 
>> Thanks, Howard!
>> 
>> I will try to take you up on your offer to help: do you think you
>> could start this documentation process more broadly? That is, not
>> just covering the Haskell Wiki, but also, say, gitlab.haskell.org.
>> (You say you wish to document the wiki's configuration consistently
>> with gitlab.haskell.org, but I don't know that the latter is
>> documented!)
>> 
>> Ideally, I would love to know what services haskell.org hosts, who
>> runs them, and what happens if those people become unavailable.
>> There's a zoo of services out there, and knowing who does what would
>> be invaluable.
>> 
>> Of course, anyone can start this process, but it takes someone
>> willing to stick with it and see it through for a few weeks. Since
>> Howard boldly stepped forward, I nominate him. :)
>> 
>> Thanks,
>> Richard
> 

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

Re: GitLab is down: urgent

[Richard Eisenberg]

> On Mar 19, 2021, at 12:44 PM, howard.b.gol...@gmail.com wrote:
> 
> I would like to help however I can. I already maintain the Haskell
> wiki, and I would like to improve and document its configuration using
> devops techniques, preferably consistent with gitlab.haskell.org 
> .

Thanks, Howard!

I will try to take you up on your offer to help: do you think you could start 
this documentation process more broadly? That is, not just covering the Haskell 
Wiki, but also, say, gitlab.haskell.org. (You say you wish to document the 
wiki's configuration consistently with gitlab.haskell.org, but I don't know 
that the latter is documented!)

Ideally, I would love to know what services haskell.org hosts, who runs them, 
and what happens if those people become unavailable. There's a zoo of services 
out there, and knowing who does what would be invaluable.

Of course, anyone can start this process, but it takes someone willing to stick 
with it and see it through for a few weeks. Since Howard boldly stepped 
forward, I nominate him. :)

Thanks,
Richard___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GitLab is down: urgent

[Richard Eisenberg]

Hi Ben,

Thanks for getting the fix in so quickly.

However: suppose you were unavailable to do this, due to a well-deserved 
holiday perhaps. Who else has the credentials and know-how to step in?

I feel as if we should have a resource somewhere with a definitive list of 
critical services and who has access to what. Perhaps this list should be kept 
private, in case the knowledge itself is a (small) security risk -- but it 
should be written down and shared widely enough that it is unlikely for all 
people with access to be unavailable at the same time.

Do we have such a resource already?

Richard

> On Mar 19, 2021, at 9:47 AM, Ben Gamari  wrote:
> 
> Simon Peyton Jones via ghc-devs  writes:
> 
>> GHC's GitLab seems to be down.  Ben?
>> (I just get 502's)
> 
> Everything should now be back to normal. I have sent a post-mortem
> describing the failure mode and fix. Apologies for the inconvenience!
> 
> 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: Is referring to GHC-proposals in GHC user manual bad practice or not?

[Richard Eisenberg]

> On Mar 17, 2021, at 2:52 PM, Oleg Grenrus  wrote:
> 
> 
> Do we agree on this interpretation?

Yes, fully. Thanks for illustrating with examples.

Richard

> 
> - Oleg
> 
> On 17.3.2021 20.35, Richard Eisenberg wrote:
>> My vote is that the manual should be self-standing. References to proposals 
>> are good, but as supplementary/background reading only. My gold standard 
>> always is: if we lost all the source code to GHC and all its compiled 
>> versions, but just had the manual and Haskell Reports (but without external 
>> references), we could re-create an interface-equivalent implementation. (I 
>> say "interface-equivalent" because we do not specify all the details of e.g. 
>> optimizations and interface files.) We are very, very far from that gold 
>> standard. Yet I still think it's a good standard to aim for when drafting 
>> new sections of the manual.
>> 
>> Of course, authors are quite free to copy-and-paste from proposal text to 
>> form a new manual chapter.
>> 
>> If we agree about this, it would be good to lay this out somewhere, perhaps 
>> in the "care and feeding" chapter.
>> 
>> Richard
>> 
>>> On Mar 17, 2021, at 1:21 PM, Oleg Grenrus  wrote:
>>> 
>>> I forgot to link a bit of relevant discussion from
>>> https://github.com/ghc-proposals/ghc-proposals/pull/406,
>>> is there a (silent) consensus on the issue?
>>> 
>>> - Oleg
>>> 
>>> On 17.3.2021 19.15, Oleg Grenrus wrote:
>>>> I have a following question:
>>>> My lexer rules related proposal was recently accepted. The biggest part
>>>> of getting it in is writing documentation for it. While looking at
>>>> Divergence from Haskell 98 and Haskell 2010 section of the user manual,
>>>> in particular Lexical syntax, it already has See "GHC Proposal #229 for
>>>> the precise rules.".
>>>> 
>>>> Can I just the same? (I think there was an implicit acceptance of that
>>>> practice in e.g.
>>>> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/1664#note_238759)
>>>> 
>>>> However, I think that referring to proposals text for "essential" bits
>>>> of information is a bad practice.
>>>> Because GHC proposals are sometimes amended, one have to look into
>>>> GitHub history to find out what were there for a particular time point
>>>> of a GHC release. Very laborous.
>>>> 
>>>> ---
>>>> 
>>>> Currently there is 23 references to about a dozen of proposals. An
>>>> example are passages like
>>>> 
>>>>In 9.0, the behavior of this extension changed, and now we require
>>>> that a negative literal must not be preceded by a closing token (see
>>>>`GHC Proposal #229
>>>> <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0229-whitespace-bang-patterns.rst>`__
>>>>for the definition of a closing token).
>>>> 
>>>> or
>>>> 
>>>> a future release will be
>>>> turned off by default and then possibly removed. The reasons for
>>>> this and
>>>> the deprecation schedule are described in `GHC proposal #30
>>>> 
>>>> <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0030-remove-star-kind.rst>`__.
>>>> 
>>>> And there are better examples, which are references for more information,
>>>> not essential one, like
>>>> 
>>>> See the proposal `DuplicateRecordFields without ambiguous field access
>>>> 
>>>> <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0366-no-ambiguous-field-access.rst>`_
>>>> and the documentation on :extension:`DuplicateRecordFields` for
>>>> further details.
>>>> 
>>>> (I'd put the internal user manual link first), or
>>>> 
>>>>But these automatic eta-expansions may silently change the semantics
>>>> of the user's program,
>>>>and deep skolemisation was removed from the language by
>>>>`GHC Proposal #287
>>>> <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst>`__.
>>>>This proposal has many more examples.
>>>> 
>>>> ---
>>>> 
>>>> So to boil down my question, can I write
>>>> 
>>>>Lexical syntax of identifiers and decimal numbers differs slightly
>>>> from the Haskell report.
>>>>See GHC Proposal #403 for the precise rules and differences.
>>>> 
>>>> - Oleg
>>>> ___
>>>> 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: Is referring to GHC-proposals in GHC user manual bad practice or not?

[Richard Eisenberg]

My vote is that the manual should be self-standing. References to proposals are 
good, but as supplementary/background reading only. My gold standard always is: 
if we lost all the source code to GHC and all its compiled versions, but just 
had the manual and Haskell Reports (but without external references), we could 
re-create an interface-equivalent implementation. (I say "interface-equivalent" 
because we do not specify all the details of e.g. optimizations and interface 
files.) We are very, very far from that gold standard. Yet I still think it's a 
good standard to aim for when drafting new sections of the manual.

Of course, authors are quite free to copy-and-paste from proposal text to form 
a new manual chapter.

If we agree about this, it would be good to lay this out somewhere, perhaps in 
the "care and feeding" chapter.

Richard

> On Mar 17, 2021, at 1:21 PM, Oleg Grenrus  wrote:
> 
> I forgot to link a bit of relevant discussion from
> https://github.com/ghc-proposals/ghc-proposals/pull/406,
> is there a (silent) consensus on the issue?
> 
> - Oleg
> 
> On 17.3.2021 19.15, Oleg Grenrus wrote:
>> I have a following question:
>> My lexer rules related proposal was recently accepted. The biggest part
>> of getting it in is writing documentation for it. While looking at
>> Divergence from Haskell 98 and Haskell 2010 section of the user manual,
>> in particular Lexical syntax, it already has See "GHC Proposal #229 for
>> the precise rules.".
>> 
>> Can I just the same? (I think there was an implicit acceptance of that
>> practice in e.g.
>> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/1664#note_238759)
>> 
>> However, I think that referring to proposals text for "essential" bits
>> of information is a bad practice.
>> Because GHC proposals are sometimes amended, one have to look into
>> GitHub history to find out what were there for a particular time point
>> of a GHC release. Very laborous.
>> 
>> ---
>> 
>> Currently there is 23 references to about a dozen of proposals. An
>> example are passages like
>> 
>> In 9.0, the behavior of this extension changed, and now we require
>> that a negative literal must not be preceded by a closing token (see
>> `GHC Proposal #229
>> `__
>> for the definition of a closing token).
>> 
>> or
>> 
>>  a future release will be
>>  turned off by default and then possibly removed. The reasons for
>> this and
>>  the deprecation schedule are described in `GHC proposal #30
>> 
>> `__.
>> 
>> And there are better examples, which are references for more information,
>> not essential one, like
>> 
>>  See the proposal `DuplicateRecordFields without ambiguous field access
>> 
>> `_
>>  and the documentation on :extension:`DuplicateRecordFields` for
>> further details.
>> 
>> (I'd put the internal user manual link first), or
>> 
>> But these automatic eta-expansions may silently change the semantics
>> of the user's program,
>> and deep skolemisation was removed from the language by
>> `GHC Proposal #287
>> `__.
>> This proposal has many more examples.
>> 
>> ---
>> 
>> So to boil down my question, can I write
>> 
>> Lexical syntax of identifiers and decimal numbers differs slightly
>> from the Haskell report.
>> See GHC Proposal #403 for the precise rules and differences.
>> 
>> - Oleg
>> ___
>> 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: On CI

[Richard Eisenberg]

> On Mar 17, 2021, at 6:18 AM, Moritz Angermann  
> wrote:
> 
> But what do we expect of patch authors? Right now if five people write 
> patches to GHC, and each of them eventually manage to get their MRs green, 
> after a long review, they finally see it assigned to marge, and then it 
> starts failing? Their patch on its own was fine, but their aggregate with 
> other people's code leads to regressions? So we now expect all patch authors 
> together to try to figure out what happened? Figuring out why something 
> regressed is hard enough, and we only have a very few people who are actually 
> capable of debugging this. Thus I believe it would end up with Ben, Andreas, 
> Matthiew, Simon, ... or someone else from GHC HQ anyway to figure out why it 
> regressed, be it in the Review Stage, or dissecting a marge aggregate, or on 
> master.

I have previously posted against the idea of allowing Marge to accept 
regressions... but the paragraph above is sadly convincing. Maybe Simon is 
right about opening up the windows to, say, be 100% (which would catch a 10x 
regression) instead of infinite, but I'm now convinced that Marge should be 
very generous in allowing regressions -- provided we also have some way of 
monitoring drift over time.

Separately, I've been concerned for some time about the peculiarity of our perf 
tests. For example, I'd be quite happy to accept a 25% regression on T9872c if 
it yielded a 1% improvement on compiling Cabal. T9872 is very very very 
strange! (Maybe if *all* the T9872 tests regressed, I'd be more worried.) I 
would be very happy to learn that some more general, representative tests are 
included in our examinations.

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

Re: GHC Exactprint merge process

[Richard Eisenberg]

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 > <mailto:alan.z...@gmail.com>> 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 
>> <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2418>
>> [2] https://gitlab.haskell.org/ghc/ghc/-/issues/17638 
>> <https://gitlab.haskell.org/ghc/ghc/-/issues/17638>
>> [3] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5158 
>> <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5158>___
>> ghc-devs mailing list
>> ghc-devs@haskell.org <mailto: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: GHC Exactprint merge process

[Richard Eisenberg]

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

Re: GHC 9.1?

[Richard Eisenberg]

Thanks for the input, all. I'm now convinced that retaining the current 
odd/even scheme has concrete benefits and am happy to continue doing it.

Richard

> On Mar 2, 2021, at 10:36 AM, Phyx  wrote:
> 
> I am also against not using the odd/even versioning scheme. 
> 
> My objections are similar to what Edward mentioned in that adding "junks" at 
> the end of the build number is problematic for packagers of the toolchain 
> where the packaging has its own way to mark something pre-release. 
> 
> If GHC were to invent its own thing, especially if it's alpha numeric this 
> would be a huge pain for no real benefit. 
> 
> A beginner can quickly see on Wikipedia or other places that the compiler 
> only does even numbered releases, but the changes has a lot of wide spreading 
> implications. 
> 
> Kind regards, 
> Tamar 
> 
> Sent from my Mobile
> 
> On Tue, Mar 2, 2021, 09:34 Edward Kmett  <mailto:ekm...@gmail.com>> wrote:
> In the past I've gained non-zero utility from having the spacer there to 
> allow me to push patches in to allow HEAD builds while features are still in 
> flux. Some of those in flux changes -- to my mild chagrin -- made it out to 
> hackage, but were handled robustly because I wasn't claiming in the code that 
> it worked on the next major release of GHC. Admittedly this was in the 
> before-times, when it was much harder to vendor specific versions of packages 
> for testing. Now with stack.yaml and cabal.project addressing that detail it 
> is much reduced concern.
> 
> That isn't to say there is zero cost to losing every other version number, 
> but if we want to allow GHC versions and PVP versions to mentally "fit in the 
> same type" the current practice has the benefit that it doesn't require us 
> either doing something like bolting tags back into Data.Version to handle the 
> "x.y.nightly" or forcing everyone to move to the real next release the moment 
> the new compiler ships with a bunch of a jump, or generally forcing more 
> string-processing nonsense into build systems. Right now version numbers go 
> up and you can use some numerical shenanigans to approximate them with a 
> single integer for easy ifdefs.
> 
> I'm ever so slightly against recoloring the bikeshed on the way we manage the 
> GHC  version number, just because I know my tooling is robust around what we 
> have, and I don't see marked improvement in the status quo being gained, 
> while I do foresee a bit of complication around the consumption of ghc as a 
> tool if we change
> 
> -Edward
> 
> On Mon, Mar 1, 2021 at 8:30 PM Richard Eisenberg  <mailto:r...@richarde.dev>> wrote:
> Hi devs,
> 
> I understand that GHC uses the same version numbering system as the Linux 
> kernel did until 2003(*), using odd numbers for unstable "releases" and even 
> ones for stable ones. I have seen this become a point of confusion, as in: 
> "Quick Look just missed the cutoff for GHC 9.0, so it will be out in GHC 9.2" 
> "Um, what about 9.1?"
> 
> Is there a reason to keep this practice? Linux moved away from it 18 years 
> ago and seems to have thrived despite. Giving this convention up on a new 
> first-number change (the change from 8 to 9) seems like a good time.
> 
> I don't feel strongly about this, at all -- just asking a question that maybe 
> no one has asked in a long time.
> 
> Richard
> 
> (*) I actually didn't know that Linux stopped doing this until writing this 
> email, wondering why we needed to tie ourselves to Linux. I coincidentally 
> stopped using Linux full-time (and thus administering my own installation) in 
> 2003, when I graduated from university.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org <mailto:ghc-devs@haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs 
> <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org <mailto:ghc-devs@haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs 
> <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 9.1?

[Richard Eisenberg]

Hi devs,

I understand that GHC uses the same version numbering system as the Linux 
kernel did until 2003(*), using odd numbers for unstable "releases" and even 
ones for stable ones. I have seen this become a point of confusion, as in: 
"Quick Look just missed the cutoff for GHC 9.0, so it will be out in GHC 9.2" 
"Um, what about 9.1?"

Is there a reason to keep this practice? Linux moved away from it 18 years ago 
and seems to have thrived despite. Giving this convention up on a new 
first-number change (the change from 8 to 9) seems like a good time.

I don't feel strongly about this, at all -- just asking a question that maybe 
no one has asked in a long time.

Richard

(*) I actually didn't know that Linux stopped doing this until writing this 
email, wondering why we needed to tie ourselves to Linux. I coincidentally 
stopped using Linux full-time (and thus administering my own installation) in 
2003, when I graduated from university.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: MR template text

[Richard Eisenberg]

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

Re: Changes to performance testing?

[Richard Eisenberg]

> On Feb 21, 2021, at 11:24 AM, Ben Gamari  wrote:
> 
> To mitigate this I would suggest that we allow performance test failures
> in marge-bot pipelines. A slightly weaker variant of this idea would
> instead only allow performance *improvements*. I suspect the latter
> would get most of the benefit, while eliminating the possibility that a
> large regression goes unnoticed.

The value in making performance improvements a test failure is so that patch 
authors can be informed of what they have done, to make sure it matches 
expectations. This need can reasonably be satisfied without stopping merging. 
That is, if Marge can accept performance improvements, while (say) posting to 
each MR involved that it may have contributed to a performance improvement, 
then I think we've done our job here.

On the other hand, a performance degradation is a bug, just like, say, an error 
message regression. Even if it's a combination of commits that cause the 
problem (an actual possibility even for error message regressions), it's still 
a bug that we need to either fix or accept (balanced out by other 
improvements). The pain of debugging this scenario might be mitigated if there 
were a collation of the performance wibbles for each individual commit. This 
information is, in general, available: each commit passed CI on its own, and so 
it should be possible to create a little report with its rows being perf tests 
and its columns being commits or MR #s; each cell in the table would be a 
percentage regression. If we're lucky, the regression Marge sees will be the 
sum(*) of the entries in one of the rows -- this means that we have a simple 
agglomeration of performance degradation. If we're less lucky, the whole will 
not equal the sum of the parts, and some of the patches interfere. In either 
case, the table would suggest a likely place to look next.

(*) I suppose if we're recording percentages, it wouldn't necessarily be the 
actual sum, because percentages are a bit funny. But you get my meaning.

Pulling this all together:
* I'm against the initial proposal of allowing all performance failures by 
Marge. This will allow bugs to accumulate (in my opinion).
* I'm in favor of allowing performance improvements to be accepted by Marge.
* To mitigate against the information loss of Marge accepting performance 
improvements, it would be great if Marge could alert MR authors that a 
cumulative performance improvement took place.
* To mitigate against the annoyance of finding a performance regression in a 
merge commit that does not appear in any component commit, it would be great if 
there were a tool to collect performance numbers from a set of commits and 
present them in a table for further analysis.

These "mitigations" might take work. If labor is impossible to produce to 
complete this work, I'm in favor of simply allowing the performance 
improvements, maybe also filing a ticket about these potential improvements to 
the process.

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

Re: On CI

[Richard Eisenberg]

There are some good ideas here, but I want to throw out another one: put all 
our effort into reducing compile times. There is a loud plea to do this on 
Discourse 
,
 and it would both solve these CI problems and also help everyone else.

This isn't to say to stop exploring the ideas here. But since time is mostly 
fixed, tackling compilation times in general may be the best way out of this. 
Ben's survey of other projects (thanks!) shows that we're way, way behind in 
how long our CI takes to run.

Richard

> On Feb 19, 2021, at 7:20 AM, Sebastian Graf  wrote:
> 
> Recompilation avoidance
> 
> I think in order to cache more in CI, we first have to invest some time in 
> fixing recompilation avoidance in our bootstrapped build system.
> 
> I just tested on a hadrian perf ticky build: Adding one line of *comment* in 
> the compiler causes
> a (pretty slow, yet negligible) rebuild of the stage1 compiler
> 2 minutes of RTS rebuilding (Why do we have to rebuild the RTS? It doesn't 
> depend in any way on the change I made)
> apparent full rebuild the libraries
> apparent full rebuild of the stage2 compiler
> That took 17 minutes, a full build takes ~45minutes. So there definitely is 
> some caching going on, but not nearly as much as there could be.
> I know there have been great and boring efforts on compiler determinism in 
> the past, but either it's not good enough or our build system needs fixing.
> I think a good first step to assert would be to make sure that the hash of 
> the stage1 compiler executable doesn't change if I only change a comment.
> I'm aware there probably is stuff going on, like embedding configure dates in 
> interface files and executables, that would need to go, but if possible this 
> would be a huge improvement.
> 
> On the other hand, we can simply tack on a [skip ci] to the commit message, 
> as I did for https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4975 
> . Variants like 
> [skip tests] or [frontend] could help to identify which tests to run by 
> default.
> 
> Lean
> 
> I had a chat with a colleague about how they do CI for Lean. Apparently, CI 
> turnaround time including tests is generally 25 minutes (~15 minutes for the 
> build) for a complete pipeline, testing 6 different OSes and configurations 
> in parallel: https://github.com/leanprover/lean4/actions/workflows/ci.yml 
> 
> They utilise ccache to cache the clang-based C++-backend, so that they only 
> have to re-run the front- and middle-end. In effect, they take advantage of 
> the fact that the "function" clang, in contrast to the "function" stage1 
> compiler, stays the same.
> It's hard to achieve that for GHC, where a complete compiler pipeline comes 
> as one big, fused "function": An external tool can never be certain that a 
> change to Parser.y could not affect the CodeGen phase.
> 
> Inspired by Lean, the following is a bit inconcrete and imaginary, but maybe 
> we could make it so that compiler phases "sign" parts of the interface file 
> with the binary hash of the respective subcomponents of the phase?
> E.g., if all the object files that influence CodeGen (that will later be 
> linked into the stage1 compiler) result in a hash of 0xdeadbeef before and 
> after the change to Parser.y, we know we can stop recompiling Data.List with 
> the stage1 compiler when we see that the IR passed to CodeGen didn't change, 
> because the last compile did CodeGen with a stage1 compiler with the same 
> hash 0xdeadbeef. The 0xdeadbeef hash is a proxy for saying "the function 
> CodeGen stayed the same", so we can reuse its cached outputs.
> Of course, that is utopic without a tool that does the "taint analysis" of 
> which modules in GHC influence CodeGen. Probably just including all the 
> transitive dependencies of GHC.CmmToAsm suffices, but probably that's too 
> crude already. For another example, a change to GHC.Utils.Unique would 
> probably entail a full rebuild of the compiler because it basically affects 
> all compiler phases.
> There are probably parallels with recompilation avoidance in a language with 
> staged meta-programming.
> 
> Am Fr., 19. Feb. 2021 um 11:42 Uhr schrieb Josef Svenningsson via ghc-devs 
> mailto:ghc-devs@haskell.org>>:
> Doing "optimistic caching" like you suggest sounds very promising. A way to 
> regain more robustness would be as follows.
> If the build fails while building the libraries or the stage2 compiler, this 
> might be a false negative due to the optimistic caching. Therefore, evict the 
> "optimistic caches" and restart building the libraries. That way we can 
> validate that the build failure was a true build failure and not just due to 
> the aggressive caching scheme.
> 
> Just my 2p
> 
> Josef
> 
> From: ghc-devs  > on behalf 

Re: Stop holding hadrian back with backwards compatibility

[Richard Eisenberg]

> On Feb 10, 2021, at 8:50 AM, Simon Peyton Jones  wrote:
> 
> build with hadrian, and then continue using make with the artifacts 
> (partially) built by Hadrian

I almost suggested that this had to be the reason for the back-compat design, 
but I assumed I had to be wrong. I also agree this is a non-goal; I'm quite 
happy to be forced to pick one or the other and stick with that choice until 
blasting away all build products.

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

Re: Newtype over (~#)

[Richard Eisenberg]

> On Feb 10, 2021, at 5:43 AM, Igor Popov  wrote:
> 
> That's a really interesting quirk. That kind of explains why an
> argument to a cast has to be a CoVar, we want all casts to be guarded
> by a case-of. But do we still need the restriction that an Id cannot
> have a coercion type?

No, we wouldn't need the restriction if GHC were implemented correctly -- that 
is, without the mkLocalIdOrCoVar abomination that looks at the type of a binder 
to determine whether it's a CoVar.

> 
> Either case it seems like we need to be extremely careful with how the
> wrapper and the matcher works for such a constructor. I was hoping a
> sledgehammer approach would work where we kind of just force (a ~# b)
> as a field into a newtype, and the existing machinery magically works
> with it.
> 
> The construction is then chock full of questions:
> 
>axiom N::~:# :: forall k. (:~:#) @k ~R (~#) @k
> 
> Is this valid? mkPrimEqPred says it doesn't like equalities on either
> side (I'm assuming this applies to eta-contracted equalities as well).

I don't see any equalities on either side here. Instead, this is a relationship 
between equality *types*. That should be just fine; GHC even produces such 
things already from time to time. I do think you'll need two `@k`s on the 
right, though. The rule you're worried about forbids constructions like (cv1 ~R 
cv2), where cv1 and cv2 have been injected into types via CoercionTy.

> mkReprPrimEqPred doesn't. Who to believe and what are the pitfalls?

mkReprPrimEqPred has the same properties here; the comments should be better.

> 
>Refl# :: forall k (a b :: k). a ~# b -> a :~:# b
>Refl# = \@k @a @b v -> v `cast` Sym (N::~:# k)  
> 
> Is this valid? You say that v has to be bound as a CoVar (current
> newtype machinery will not do this). Can a CoVar appear in the LHS of
> a cast?

No, it can't. This may be a real blocker. I hadn't thought about this part of 
the problem.
> 
> 
> `cast` Sym (N::~:# k)  
> 
> Is this valid?

No, for the same reasons.

This is unfortunate, as I thought this was a good idea. Yet I'm not hopeful 
that there's an easy way out of this particular trap.

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

Re: Stop holding hadrian back with backwards compatibility

[Richard Eisenberg]

This sounds very reasonable on the surface, but I don't understand the 
consequences of this proposal. What are these consequences? Will this break 
`make`? (It sounds like it won't, given that the change is to Hadrian.) Does 
this mean horrible things will happen if I use `make` and `hadrian` in the same 
tree? (I have never done this, other than with hadrian/ghci, which seems to 
have its own working directory.) Basically: for someone who uses the build 
system but does not work on it, how does this affect me? (Maybe not at all!)

I would explicitly like to endorse the direction of travel toward Hadrian and 
away from `make`.

Richard

> On Feb 10, 2021, at 8:05 AM, Moritz Angermann  
> wrote:
> 
> Hi,
> 
> so we've finally run into a case where we need to bump the rts version.  This 
> has a great ripple effect.  There is some implicit assumption that rts-1.0 
> will always be true. Of course that was a lie, but a lie we lived with for a 
> long time.
> 
> Now, hadrian tries *really* hard to replicate some of the Make based build 
> systems idiosyncrasies, this includes creating versionless symlinks for the 
> rts. E.g. libHSrts -> libHSrts-1.0. There is a great deal of logic just 
> to achieve this, and of course it all crumbles now.
> 
> I'd therefore like to float and propose the idea that we agree to *not* 
> bother (too?) much with make based build systems backwards compatibility and 
> warts that grew over the years in the make based build system with hadrian 
> going forward.
> 
> Yes, I can probably fix this, and add even more code to this burning pile of 
> complexity, but why?  The next person will assume libHSrts does not need to 
> be versioned and continue with this mess.
> 
> Let's have Hadrian be a clean cut in some areas (it already is, it does away 
> with the horrible abomination that ghc-cabal is--which only serves the 
> purpose of translating cabal descriptions into make readable files), and not 
> be bogged down by backwards compatibility.
> 
> This is thus my call for voicing concern or the upkeep of legacy support, or 
> I'll take silence as the collective support of making hadrian *not* be held 
> back by backwards compatibility. (This would mean in this case, that I'd just 
> delete the backwards compat code instead of adding even more to it).
> 
> I hope we all still want Hadrian to replace Make, if not and we want to keep 
> Make, why are we concerning ourselves with Hadrian in the first place. If we 
> are intending to ditch Make, let's not be held back by it.
> 
> Cheers,
>  Moritz
> ___
> 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: Newtype over (~#)

[Richard Eisenberg]

We do need a separate category, though: otherwise, we could cast by `f x`, 
where `f` is a non-terminating functions. We erase casts, so the function would 
never get called. Maybe if we required that casts are always by variables 
(essentially, A-normalize casts) we could avoid this? But then would we require 
A-normalization to build coercions from pieces (as opposed to calling 
functions)? It's unclear.

I think the first versions of this idea didn't require the separate syntactic 
category, but all work for the past decade has. I think there are other ways, 
but the way GHC handles this now is somewhat poor, because of #17291.

Richard

> On Feb 5, 2021, at 7:56 PM, Igor Popov  wrote:
> 
>> GHC cheats in this area. The problem is that (a ~# b) is a type, because 
>> that is terribly, terribly convenient. But it really shouldn't be.
>> 
>> The problem is that coercion variables are different from regular variables. 
>> So, if we say (v :: a ~# b), we must always be careful: is v a coercion 
>> variable or not? If it isn't, then v is useless. You cannot, for instance, 
>> use v in a cast.
> 
> I don't really see a problem here. The fact that only a "coercion
> variable" can be used in a cast should be enforced by the typing rule
> for cast. That doesn't require having a distinct "syntactic category"
> of coercion variables, unless I'm missing something.
> 
> -- mniip

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

Re: Newtype over (~#)

[Richard Eisenberg]

GHC cheats in this area. The problem is that (a ~# b) is a type, because that 
is terribly, terribly convenient. But it really shouldn't be.

The problem is that coercion variables are different from regular variables. 
So, if we say (v :: a ~# b), we must always be careful: is v a coercion 
variable or not? If it isn't, then v is useless. You cannot, for instance, use 
v in a cast. In a number of places, GHC must produce a variable binder of a 
certain type. It will sometimes examine that type; if the type is an equality 
type, then the binder will be a coercion variable; otherwise, it will be a 
normal Id. This is wrong, but again, very convenient. (Wrong because we should 
always know in advance whether we want a coercion variable or an Id.)

I think the problems you're running into are all around this confusion. For 
example,

(\ (v :: a ~# a) -> v `cast` _R)
   @~ _N

is ill-formed, whether v is an Id or a CoVar. If it's an Id, then this is wrong 
because you have an Id with a coercion type. (The theory of the core language 
does not prevent such things, but I'm not surprised that GHC would fall over if 
you tried it.) If v is a CoVar, then its use as the left-hand side of `cast` is 
wrong.

This is all https://gitlab.haskell.org/ghc/ghc/-/issues/17291 
.

All that said, I think your original idea is a fine one: a newtype wrapper 
around ~#. It's possible there is just some Id/CoVar confusion in your 
implementation, and that's what's causing the trouble. I don't see a correct 
implementation as impossible.

Is your implementation available somewhere?

I hope this helps!
Richard___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC Reading Guide

[Richard Eisenberg]

A quick scroll through didn't reveal anything incorrect in my areas of 
expertise.

On the "Dump intermediate languages" slide, you might want to mention these 
flags:
 -fprint-explicit-kinds: print out kind applications
 -fprint-explicit-coercions: print out details of coercions
 -fprint-typechecker-elaboration: print out extra gubbins the type-checker 
inserts
 -fprint-explicit-runtime-reps: don't simplify away RuntimeRep arguments
 
 -ddump-ds-preopt: print out the desugared Core before the very first "simple" 
optimization pass

Thanks for writing & sharing!
Richard

> On Feb 5, 2021, at 7:05 AM, Takenobu Tani  wrote:
> 
> Dear devs,
> 
> I've written a simple document about "GHC source reading" for myself
> and potential newcomers:
> 
>  * https://takenobu-hs.github.io/downloads/haskell_ghc_reading_guide.pdf
>(https://github.com/takenobu-hs/haskell-ghc-reading-guide)
> 
> Please teach me if something's wrong. I'll learn and correct them.
> 
> Happy Haskelling :)
> 
> Regards,
> Takenobu
> ___
> 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: Happy version downgrade

[Richard Eisenberg]

If you say `./configure --help`, you'll get all the flags to ./configure. 
Toward the bottom, it says that the HAPPY environment variable can contain the 
path to the happy executable. So try

> HAPPY=happy-1.19.8 ./configure

and see where you get. You might need the full path to your installed 
happy-1.19.8. It might also be possible to pass 
--with-happy=/full/path/to/happy-19.8 as an argument.

Richard

> On Feb 3, 2021, at 7:03 PM, Simon Peyton Jones via ghc-devs 
>  wrote:
> 
> Friends
> 
> I can’t build ghc-9.0 because of this:
> 
> checking for ghc-pkg matching /opt/ghc/bin/ghc... /opt/ghc/bin/ghc-pkg
> checking for happy... /home/simonpj/.cabal/bin/happy
> checking for version of happy... 1.20.0
> configure: error: Happy version 1.19 is required to compile GHC.
> What is the easiest way to fix?  I have happy 1.19.8, but it’s not called 
> plain “happy”
> 
> bash$ happy-1.19.8 --version
> Happy Version 1.19.8 Copyright (c) 1993-1996 Andy Gill, Simon Marlow (c) 
> 1997-2005 Simon Marlow
> Happy is a Yacc for Haskell, and comes with ABSOLUTELY NO WARRANTY.
> This program is free software; you can redistribute it and/or modify
> it under the terms given in the file 'LICENSE' distributed with
> the Happy sources.
> 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: -ddump-json

[Richard Eisenberg]

I have filed https://gitlab.haskell.org/ghc/ghc/-/issues/19278 
<https://gitlab.haskell.org/ghc/ghc/-/issues/19278> to try to get this sorted. 
Thanks for the quick responses!

Richard

> On Jan 29, 2021, at 4:02 AM, Hécate  wrote:
> 
> Do we provide any kind of versioning or data schema for the JSON dumps?
> 
> On 29/01/2021 09:57, Matthew Pickering wrote:
>> Just grepping Github there appears to be a few users of the flag but
>> no more than a handful. I think you can probably change it how you
>> like.
>> 
>> Cheers,
>> 
>> Matt
>> 
>> On Thu, Jan 28, 2021 at 8:20 PM Richard Eisenberg  wrote:
>>> Hi devs,
>>> 
>>> In my work with Alfredo at revising our error message infrastructure, we 
>>> ran across some code that renders error messages as JSON. Given that our 
>>> data structures are changing, it seems natural to change the JSON output, 
>>> too, but it's unclear whether that's wise. The manual currently lists 
>>> -ddump-json in the chapter on "Debugging the compiler", suggesting that a 
>>> change is fine, but I'm not yet convinced.
>>> 
>>> So:
>>>  - Is there someone in charge of -ddump-json? Matthew Pickering authored 
>>> -ddump-json in 
>>> https://gitlab.haskell.org/ghc/ghc/-/commit/91691117fc194c525f58ccd5b266dd1d10493e5a.
>>>  - Are there clients of -ddump-json?
>>>  - Is there a specification of -ddump-json?
>>>  - There will likely be a desire to evolve this feature. What is the 
>>> process for doing so?
>>> 
>>> Thanks!
>>> Richard
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 
> -- 
> Hécate ✨
> : @TechnoEmpress
> IRC: Uniaika
> WWW: https://glitchbra.in
> RUN: BSD
> 
> ___
> 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