RE: Pattern synonym constraints :: Ord a => () => ...

must be the union of the constraints required to match the pattern, _plus_ required to build with the pattern -- if it is bidirectional. I think that is confusing too! How about this: * ⟨CReq⟩ are the constraints required to match the pattern, in a pattern match. * ⟨CProv⟩ are the

RE: Pattern synonym constraints :: Ord a => () => ...

Perhaps I'm just stupid, and should be disqualified from using such features. Only as a result of this thread (not from the User Guide nor from the paper) do I discover "use" means match-on. You are not stupid. And since you misunderstood despite effort, the presentation is - by definition -

RE: -dinline-check for symbolic names?

| First, reading the ghc source code suggests I can only have one -ddinline- | check. Correct? Yes. The last one wins. This should be in the user manual. Would anyone like to offer a PR? | Also, I'm guessing that the inlining I didn't see reported by -dinline-check | happened inside the

RE: Avoiding construction of dead dictionaries

Hi Mike Repro case is something like * Here is a source or files * Compile like this * Look at the generated Core...observe silly thing happening Evidence of importance could be as simple as "in my application I'm seeing a lot of these redundant dictionaries being built for no reason". Or,

RE: InstanceSigs -- rationale for the "must be more polymorphic than"

Do you have a concrete example? I think that the recursive calls will all go via the original class method with its original type - we can't know that it's calling *this* instance till much later. So I still don't get it. An example would clear it up. Simon From: David Feuer Sent: 10

RE: -dinline-check for symbolic names?

It's hard to tell what is happening without a repro case. Can you share one? You suggested that it might have something to do with using an operator. Does the same thing happen if you replace the operator with an alpha-numeric name? Simon | -Original Message- | From:

RE: InstanceSigs -- rationale for the "must be more polymorphic than"

AntC, I think you see why the instance sig must be at least as polymorphic than the instantiated signature from the class - because that's what the client is going to expect. We are building a record of functions, and they must conform to the class signature. I agree with David's (1) and (2)

RE: Avoiding construction of dead dictionaries

Hi Mike | The right-hand argument of <+ leads to a dictionary construction that is a | proof of a certain property, but the dictionary itself ends up being dead, | like so: | |case $w$dOpCon_r2kGJ ... |of |{ (# ww1_s27L3 #) -> ... } | ^ |

RE: Avoiding construction of dead dictionaries

> . So apparently it is possible for a dictionary to be bottom somehow. That should not happen. Except in the case of single-method dictionaries like class C a where op :: a -> a In these cases the "dictionary" is represented by a newtype, like this newtype C a =

RE: exhausted simplifier ticks and hs-boot files

Ganesh It's an old bug that has somehow reappeared. I opened https://gitlab.haskell.org/ghc/ghc/issues/17140 But it seems OK in HEAD, and hence probably in GHC 8.8. Can you try? Maybe put further comments on the issue tracker, rather than here. thanks Simon | -Original Message- |

RE: Equality constraints (~): type-theory behind them

I'd far rather see GHC's implementation of FunDeps made more coherent (and learning from Hugs) than squeezing it into the straitjacket of System FC and thereby lose expressivity. To call System FC a straitjacket is to suggest that there is a straightforward alternative that would serve the

Guidelines for respectful communication

Friends As many of you will know, I have been concerned for several years about the standards of discourse in the Haskell community. I think things have improved since the period that drove me to write my Respect email,

Summit on Advances in Programming Languages 2019

Haskellers The Summit oN Advances in Programming Languages (SNAPL) is a biennial venue for discussions about programming languages. SNAPL focuses on experience-based insight, innovation, and visionary ideas spanning from foundations to applications of

RE: Natural number comparisons with evidence

I see this in GHC.TypeNats sameNat :: (KnownNat a, KnownNat b) => Proxy a -> Proxy b -> Maybe (a :~: b) sameNat x y | natVal x == natVal y = Just (unsafeCoerce Refl) | otherwise= Nothing The unsafeCoerce says that sameNat is part of the trusted code base. And

RE: Open up the issues tracker on ghc-proposals

I can volunteer to at least scrape together all the objections to ScopedTypeVariables as currently. It's not yet a proposal, so not on github. Start a wiki page? A cafe thread? (It'll get lost.) A ghc-users thread? (It'll get ignored.) That’s a fair question. We have lots of forums, but your

RE: Open up the issues tracker on ghc-proposals

| > Sometimes, a language extension idea could benefit from | some community discussion before it's ready for a formal proposal. | | Can I point out it's not only ghc developers who make proposals. I'd | rather you post this idea more widely. The Right Thing is surely for the main GHC

RE: How to highlighting subexpressions in dumped core?

I'm not keen on adding more Tick complexity -- it's a bit out of hand already, and all transformations must "do the right thing". AnnExpr adds an annotation at every node. You could, I guess use that to annotate -- but then you'd need a pretty printer for it so you'd end up with duplication.

RE: Why is EvTerm limited?

| What would break if we had | | | EvExpr CoreExpr | | as an additional constructor there? This has come up before. I think that'd be a solid win. In fact, eliminate all the existing evidence constructors with "smart constructors" that produce an EvExpr. That'd mean moving stuff from

RE: GHC rewrite rule type-checking failure

* Is it feasible for GHC to combine the constraints needed LHS and RHS to form an applicability condition? I don’t think so. Remember that a rewrite rule literally rewrites LHS to RHS. It does not conjure up any new dictionaries out of thin air. In your example, (D k b) is needed in the

RE: Inhibiting the specialiser?

Did you try -fno-specialise? From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Conal Elliott Sent: 15 September 2017 02:45 To: glasgow-haskell-users@haskell.org Subject: Inhibiting the specialiser? Is there a GHC flag for inhibiting the specializer (but

RE: Trouble with injective type families

Functional dependencies and type-family dependencies only induce extra "improvement" constraints, not evidence. For example class C a b | a -> b where foo :: a -> b instance C Bool Int where ... f :: C Bool b => b -> Int f x = x -- Rejected Does the fundep on

RE: 8.2.1-rc2 upgrade report

Thanks for the report. Going from 67G to 56G allocation is a very worthwhile improvement in runtime! Hurrah. However, trebling compile time is very bad. It is (I think) far from typical: generally 8.2 is faster at compiling than 8.0 so you must be hitting something weird. Anything you can

RE: Unused import warning on re-export

| Is there a reason GHC considers this case an unused import? It seems that | the use of the import is explicitly stated right within the import | itself. Should I submit a ticket for this? Hmm. I think you are saying that module A where import B as A(f) g = True that is equivalent

RE: join points and stream fusion?

Thank you! | -Original Message- | From: Christian Höner zu Siederdissen [mailto:choe...@bioinf.uni- | leipzig.de] | Sent: 28 April 2017 00:14 | To: Simon Peyton Jones | Cc: glasgow-haskell-users@haskell.org | Subject: Re: join points and stream fusion? | |

RE: join points and stream fusion?

I'm afraid I don't have enough context to understand this thread. Could you offer a concrete example (as small as possible), and explain how to reproduce the problem you are seeing. Don't forget to give the compiler version you are using, and any libraries you depend on (as few as poss). Is

RE: Why isn't this Overlapping?

Moreover, as discussed in the user manual section, GHC doesn’t complain about overlapping instances at the instance decl, but rather where the instances are used. That’s why there is no overlap

RE: Accessing the "original" names via GHC API

The TyCon has a Name (use tyConName to get it). The Name has a Module and an OccName (use nameModule and nameOccName to get them) The OccName has a string (occNameString) The Module has a ModuleName and a Package. All of these will give the “original-name” info, ignoring what’s in scope. Does

RE: GHC rewrite rules for class operations & laws

| Indeed, we could eliminate several hundred lines of boilerplate in GHC if we | could lift this restriction. Can you be more specific? Which hundreds of lines? Do add this info to the ticket when Gorge makes it. Or just make one! Simon | -Original Message- | From: Ben Gamari

RE: GHC rewrite rules for class operations & laws

Conal Is it possible to apply GHC rewrite rules to class methods? Not currently. See https://ghc.haskell.org/trac/ghc/ticket/11688, esp comment:7 which gives links to similar examples. https://ghc.haskell.org/trac/ghc/ticket/10528 comment:13 gives more background. It’d be great if someone

RE: Getting rid of -XImpredicativeTypes

1) ImpredicativeTypes enables types like `Maybe (forall a. a)`. Do those just disappear, or are they also enabled anyway? (I would guess the former.) Yes, they’d disappear. 2) There was a sketch drawn up around a year ago (I think) aiming to actually fix ImpredicativeTypes. I don't recall who

FW: Getting rid of -XImpredicativeTypes

Friends GHC has a flag -XImpredicativeTypes that makes a half-hearted attempt to support impredicative polymorphism. But it is vestigial…. if it works, it’s really a fluke. We don’t really have a systematic story here at all. I propose, therefore, to remove it entirely. That is, if you use

RE: Type families in kind signatures with TypeInType

Interesting. Is this case also an example, or is it a non-feature? class C t where type K t :: Type type T t :: K t -> Type m :: t -> T t a Ah, that’s quite different! We should do strongly-connected-component analysis of the associated-type declarations within a single class

RE: Type families in kind signatures with TypeInType

This is an example of https://ghc.haskell.org/trac/ghc/ticket/12088. The “type instance T List” declaration actually depends on the “type instance K List” declaration; the latter must be typechecked before the former. But this dependency is absolutely unclear. There’s a long discussion on the

RE: GHC Performance / Replacement for R?

Sounds bad. But it'll need someone with bytestring expertise to debug. Maybe there's a GHC problem underlying; or maybe it's shortcoming of bytestring. Simon | -Original Message- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | boun...@haskell.org] On Behalf Of

RE: ArgumentDo proposal updated

I've added record construction and update to the syntax, which makes it clearer how the other constructs are analogous to them. Simon | -Original Message- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | boun...@haskell.org] On Behalf Of Akio Takano | Sent: 11 July

RE: Rethinking GHC's approach to managing proposals

Just to be clear: * We are actively seeking feedback about the proposal [4] below. It's not a fait-accompli. * You can join the dialogue by (a) replying to this email, (b) via the "Conversations" tab of [4], namely https://github.com/ghc-proposals/ghc-proposals/pull/1 Doubtless via

Simon's email classified as spam

Dear GHC devs/users This is another test to see if email from me, relayed via Haskell.org, ends up in your spam folder. Gershom thinks he’s fixed it (below). Can I trespass on your patience once more? Just let me know if this email ends up in your inbox or spam. Can you cc John and Gershom