Re: Distinct closure types vs. known infotables for stack frames

On Tue, Jun 27, 2023 at 4:13 AM Simon Peyton Jones < simon.peytonjo...@gmail.com> wrote: > In short, why are the design considerations for stack frames different to > heap objects? I think of a stack frame simply as a heap object that > happens to be allocated on the stack > I agree with this

Distinct closure types vs. known infotables for stack frames

Hello all, I am tinkering with the RTS again while trying to fix #23513 , and every time I touch the exceptions/continuations code, I find myself waffling about whether to introduce more closure types. I’d like to get a second opinion so I can

The GHC(i)/RTS linker and Template Haskell

Hi all, I’ve recently been trying to better understand how and where time is spent at compile-time when running Template Haskell splices, and one of the areas I’ve been struggling to figure out is the operation of the linker. From reading the source code, here’s a summary of what I think I’ve

Seeking RTS experts to review delimited continuations MR

Hi all, I have recently opened a draft MR with my initial implementation of first-class delimited continuations in the RTS, available here: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7942 The MR is not entirely finished—it still requires docs and tests, which I am gradually working on.

Re: Concrete#, SpecialPred, and CtEvidence invariants

On Wed, Dec 8, 2021 at 2:20 PM Richard Eisenberg wrote: > Does this help? > Yes, it does, and what you said makes sense. Really, the intent of the invariant isn’t “zonkedness” *per se*, but merely that the type of the evidence should be “at least as zonked” as ctev_pred is. But that is a

Concrete#, SpecialPred, and CtEvidence invariants

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

Re: GHC indecisive whether matching on GADT constructors in arrow notation is allowed

, x_a2jb), ()) > @ (Showable x_a2jb) > (\ (ds_d2kX :: ((Show x_a2jb, x_a2jb), ())) -> > case ds_d2kX of { (ds_d2kW, _ [Occ=Dead]) -> > case ds_d2kW of { ($dShow_a2jl, x_a2hL) -> >

Arrow notation, existentials, and TcType demotion

Hello, As I mentioned in a previous email , GHC seems currently somewhat uncertain about whether or not matching on GADTs is permitted in arrow notation. Sam Derbyshire suggested on Twitter

GHC indecisive whether matching on GADT constructors in arrow notation is allowed

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

Re: How does GHC implement layout?

On 4/5/21 2:36 PM, Ian Lynagh wrote: It was originally designed by John Meacham: https://gitlab.haskell.org/haskell/prime/-/wikis/alternative-layout-rule https://www.mail-archive.com/haskell-prime@haskell.org/msg01938.html Thanks, Ian—I had stumbled across a link to the old Haskell Prime trac

Re: How does GHC implement layout?

On 4/4/21 1:52 PM, Iavor Diatchki wrote: Hi Alexis, I wasn't sure what the "alternative layout" is either and did some googling, and it appears that it is something that was never really documented properly.   The following link contains pointers to the commit that introduced it (in 2009!)

How does GHC implement layout?

Hi all, I’m wondering if there are any resources that discuss the design of GHC’s implementation of layout. (I haven’t been able to find any.) From looking at the code, here’s what I’ve gathered so far: * Layout is implemented in the lexer (compiler/GHC/Parser/Lexer.x). * The

Re: Type inference of singular matches on GADTs

On 3/28/21 9:17 PM, Richard Eisenberg wrote: I think this is the key part of Alexis's plea: that the type checker take into account exhaustivity in choosing how to proceed. […] Does this match your understanding? Yes, precisely. :) Without GADTs, exhaustivity doesn’t yield any useful

Type inference of singular matches on GADTs

Hi all, Today I was writing some code that uses a GADT to represent heterogeneous lists: data HList as where   HNil  :: HList '[]   HCons :: a -> HList as -> HList (a ': as) This type is used to provide a generic way to manipulate n-ary functions. Naturally, I have some functions

Nested constructed product results?

Hi all, I spent some time today looking into the performance of a program involving a parser type that looks something like this: data AnnotatedParser a = AnnotatedParser { annotation :: Annotation , parser :: String -> (Maybe a, String) } The `Annotation` records metadata

Async exceptions and delimited continuations

Hi all, As some of you are likely aware, I have an open GHC proposal[1] to add native support for delimited continuations to the RTS. I also have an incomplete implementation,[2] and the only major remaining obstacle concerns async exceptions. The issue is subtle, so I’ve tried to provide all the

Re: Introducing GHC whole program compiler (GHC-WPC)

Hi Csaba, I originally posted this comment on /r/haskell before I saw you also sent this to ghc-devs. I’ve decided to reproduce my comment here as well, since this list probably has a more

Re: Expanding a particular type family in type errors

> On May 5, 2020, at 04:00, Richard Eisenberg wrote: > > reportWanteds reports errors, yes, but it also fills in deferred type errors. > [snip] It's a bit awkward that a function called reportWanteds does this, but > it actually makes good sense, because reportWanteds knows the text that >

Re: Expanding a particular type family in type errors

> On May 4, 2020, at 04:25, Richard Eisenberg wrote: > > 1. pprType seems a very challenging place to do this, given that pprType > works on IfaceTypes, which are not amenable to much of any analysis. Maybe > you could do the switcho-changeo before converting to IfaceType. Are your > type

Re: Expanding a particular type family in type errors

the expansion. This still seems like a bit of a hack, but I can’t think of a better way. Do tell me if there’s a better approach! > On May 1, 2020, at 16:36, Alexis King wrote: > > Hi all, > > As part of my ongoing rework of arrow notation > <https://gitlab.haskell.org/ghc

Expanding a particular type family in type errors

Hi all, As part of my ongoing rework of arrow notation , I have introduced two wired-in type families, which assist in the typechecking process. The details are not terribly important (you can read the proposal if you’d like for

Re: Why doesn’t the simple optimizer fuse casts?

Hi Richard, Nested casts can absolutely happen after the simple optimizer runs. Suppose we produce a desugared expression like: let { y = x `cast` co1 } in y `cast` co2 The simple optimizer will inline y, since it only appears once, so now we have a nested cast. Perhaps you mean you expect

Why doesn’t the simple optimizer fuse casts?

This question is spurred by curiosity more than anything else, but I’ve noticed that the simple optimizer doesn’t fuse nested casts, and I’m wondering if there’s any reason it couldn’t. To make what I’m talking about more concrete, suppose we have an expression like this: (x |> co) |> sym co

Desugaring matches with already-desugared RHSs?

Hi all, I’m currently in the process of rewriting most of the arrow desugaring code. One of the most awkward parts of the current implementation is the way case commands are desugared. Given a case command like case e1 of A a b -> cmd1 B c -> cmd2 C d e f -> cmd3 the

Re: Fusing loops by specializing on functions with SpecConstr?

I fiddled with alternative representations for a while and didn’t make any progress—it was too easy to end up with code explosion in the presence of any unknown calls—but I seem to have found a RULES-based approach that works very well on the examples I’ve tried. It’s quite simple, which makes it

Re: Fusing loops by specializing on functions with SpecConstr?

> On Apr 1, 2020, at 03:21, Sebastian Graf wrote: > > That is indeed true. But note that as long as you manage to inline > `mapMaybeSF`, the final `runSF` will only allocate once on the "edge" of each > iteration, all intermediate allocations will have been fused away. But the > allocation of

Re: Fusing loops by specializing on functions with SpecConstr?

> On Mar 31, 2020, at 17:05, Sebastian Graf wrote: > > Yeah, SPEC is quite unreliable, because IIRC at some point it's either > consumed or irrelevant. But none of the combinators you mentioned should rely > on SpecConstr! They are all non-recursive, so the Simplifier will take care > of

Re: Fusing loops by specializing on functions with SpecConstr?

Sebastian and Simon, Thank you both for your responses—they are all quite helpful! I agree with both of you that figuring out how to do this kind of specialization without any guidance from the programmer seems rather intractable. It’s too hard to divine where it would actually be beneficial,

Fusing loops by specializing on functions with SpecConstr?

Hi all, I have recently been toying with FRP, and I’ve noticed that traditional formulations generate a lot of tiny loops that GHC does a very poor job optimizing. Here’s a simplified example: newtype SF a b = SF { runSF :: a -> (b, SF a b) } add1_snd :: SF (String, Int) (String, Int)

Re: Specializing functions with implicit parameters

> On Mar 14, 2020, at 20:03, Sandy Maguire wrote: > > What GHC are you testing against? I suspect > https://gitlab.haskell.org/ghc/ghc/merge_requests/668 > will fix this. I’ve tested against HEAD. I think the change you link is helpful,

Specializing functions with implicit parameters

Hi all, I discovered today that GHC never specializes functions with implicit parameters. This is not that surprising—I wouldn’t expect GHC to specialize the implicit parameters themselves—but it’s unfortunate because it means a single implicit parameter somewhere can transitively destroy

Re: Feasibility of native RTS support for continuations?

As a small update on this for anyone following along, I submitted a GHC proposal about a week ago to add the discussed primops (albeit with some tweaked names). For those who haven’t seen it already, the pull request is here: https://github.com/ghc-proposals/ghc-proposals/pull/313 So far,

Re: Calling an unknown function from low-level Cmm

> On Feb 24, 2020, at 20:03, Simon Peyton Jones wrote: > > I don’t know the answer to this, but Alexis when you find out can I ask (I > know I'm a broken record on this) that you write a Note to explain, with > pointers from the various places you looked when you were trying to find out > the

Calling an unknown function from low-level Cmm

Hi all, I’m trying to understand how to properly call an unknown function from low-level Cmm code. If I’m just applying a function to a state token, it’s easy; I can just do R1 = io; jump stg_ap_v_fast [R1]; since the calling convention is consistent in that case. But what if my

Re: Confused about PAP object layout

Disclaimer: I am not an expert. But I happened to have been looking at this code just yesterday, so I’ll try to answer to check my understanding. :) Fundamentally, a PAP is not fully-saturated, so the number of arguments in its payload may be smaller than the information contained in the

Re: Feasibility of native RTS support for continuations?

> On Feb 10, 2020, at 02:18, Simon Marlow wrote: > >> On Mon, 10 Feb 2020 at 08:17, Simon Marlow wrote: >> >> Let me just say "unsafePerformIO" :) You probably want to at least ensure >> that things don't crash in that case, even if you can't give a sensible >> semantics to what actually

Re: Feasibility of native RTS support for continuations?

> On Feb 6, 2020, at 02:28, Simon Marlow wrote: > > The issue here is that raiseAsync is destructive - it *moves* the stack to > the heap, rather than copying it. So if you want to continue execution where > you left off, for shift#, you would have to copy it back onto the stack > again.

Re: Feasibility of native RTS support for continuations?

I took a stab at implementing this today, using the “continuation is a stack” implementation strategy I described in my previous email. I haven’t tried very hard to break it yet, but this tiny test program works: {-# LANGUAGE BangPatterns, BlockArguments, MagicHash,

Re: Feasibility of native RTS support for continuations?

> On Jan 30, 2020, at 02:35, Simon Marlow wrote: > > My guess is you can almost do what you want with asynchronous exceptions but > some changes to the RTS would be needed. > > There's a bit of code in the IO library that literally looks like this >

Re: Feasibility of native RTS support for continuations?

> On Jan 29, 2020, at 03:32, Simon Peyton Jones wrote: > > Suppose a thread happens to be evaluating a pure thunk for (factorial 200). > […] This stack-freezing stuff is definitely implemented. That’s fascinating! I had no idea, but your explanation makes sense (as do the papers you linked).

Re: Feasibility of native RTS support for continuations?

> On Jan 28, 2020, at 04:09, Simon Peyton Jones wrote: > > I've thought about this quite a bit in the past, but got stalled for lack of > cycles to think about it more. But there's a paper or two Many thanks! I’d stumbled upon the 2007 paper, but I hadn’t seen the 2016 one. In the case of

Feasibility of native RTS support for continuations?

Hi all, tl;dr: I want to try to implement native support for capturing slices of the RTS stack as a personal experiment; please tell me the obstacles I am likely to run into. Much more context follows. --- I have been working on an implementation of an algebraic effect system that uses unsafe

Re: Superclasses of type families returning constraints?

> On Jan 6, 2020, at 15:41, Simon Peyton Jones wrote: > > Ah, I see a bit better now. So you want a way to get from evidence that > co1 :: F a b ~# () > to evidence that > co2 :: a ~# b > > So you'd need some coercion form like > co2 = runBackwards co1 > > or something,

Re: Superclasses of type families returning constraints?

> On Jan 6, 2020, at 05:29, Richard Eisenberg wrote: > > You're absolutely right that improvement doesn't solve your problem. But > what I didn't say is that there is no real reason (I think) that we can't > improve improvement to produce givens. This would likely require a change to > the

Re: Superclasses of type families returning constraints?

> On Jan 6, 2020, at 12:05, Alexis King wrote: > >type family F a b where > F a b = () -- regular (), not (() :: Constraint) (Err, sorry, this should be `F a a = ()`. But I think you can understand what I’m getting at.) ___ ghc-

Re: Superclasses of type families returning constraints?

> On Jan 6, 2020, at 08:52, Simon Peyton Jones wrote: > > This is rejected, and it's not in the least bit puzzling! You have evidence > for (F a b) and you need to prove (a~b) -- for any a and b. Obviously you > can't. And in Core you could write (eq @Int @Bool (error "urk")) and you >

Re: Superclasses of type families returning constraints?

> On Jan 4, 2020, at 20:38, Richard Eisenberg wrote: > > I thought that, maybe, we could use partial improvement to give you what you > want I think that improvement alone cannot possibly be enough here, as improvement by its nature does not provide evidence. Improvement allows us to take a

Re: Superclasses of type families returning constraints?

Hi Richard, Thanks for the pointer to constrained type families—that’s helpful to clarify some of my thoughts about this, and it is indeed relevant! One example I had in my real code seems difficult to express even with constrained type families, however; here is a stripped-down version of it:

Superclasses of type families returning constraints?

Hello all, I recently noticed that GHC rejects the following program: type family F a b :: Constraint where F a a = () eq :: F a b => a :~: b eq = Refl This is certainly not shocking, but it is a little unsatisfying: as far as I can tell, accepting this program would be

Simplifier bug fixed in GHC 8.8.1?

Hi all, I have an odd question: I’ve bumped into a clear simplifier bug, and although it only happens on GHC 8.6.5, not 8.8.1, I’d like to locate the change that fixed it. My library’s test suite currently fails on GHC 8.6.5 due to the bug, and I’d rather not force all my users to upgrade to

Debugging specialization

Hi all, I am trying to understand why GHC is not specializing an imported INLINABLE instance method, and the information provided by -ddump-spec -Wall-missed-specialisations has not been enough to help me figure it out. Is there some easy/well-trodden way that I could build GHC with some

Re: Compiling projects with dependencies using GHC HEAD

> On Oct 1, 2019, at 18:56, Ben Gamari wrote: > > Indeed it's just a function of this being a bit work in progress; we > only started allowing multiple patch versions relatively recently and it > looks like the constraint file generation hasn't been updated to account > for this yet. I'll try to

Re: Compiling projects with dependencies using GHC HEAD

> On Oct 1, 2019, at 18:19, Ben Gamari wrote: > > Your question is a very good one which, until quite recently, there was > not a particularly good answer to. However, in the past months we have > been working on infrastructure (in the form of head.hackage [0]) to make > GHC more testable in

Compiling projects with dependencies using GHC HEAD

Hi all, I have a project that I’d like to try to build with GHC HEAD, but it’s a large project with a lot of dependencies, and while there’s a lot of information on building GHC itself, I haven’t been able to find very many resources on what workflow people use to actually build projects in the

Typechecker plugins and BuiltInSynFamily

Hello all, As I’ve been dabbling with typechecker plugins, I’ve found myself primarily using them to define new “magic” type families, and I don’t think I’m alone—Sandy Maguire recently released the magic-tyfams package for precisely that purpose. However, I can’t help but notice that GHC

Re: Properly writing typechecker plugins

Apologies for the long delay before replying to this, I ended up becoming very busy for a couple weeks. > On Aug 2, 2019, at 02:57, Simon Peyton Jones wrote: > > We should not need to delete solved _givens_ from the inert set. We can > augment givens with extra facts, but deleting them

Re: Properly writing typechecker plugins

here are quite a few > “customers” but few enough that they’ll probably be happy to adapt to > changes. Go for it, in consultation with them! > > Simon > > > > From: ghc-devs On Behalf Of Alexis King > Sent: 01 August 2019 07:55 > To: ghc-devs@haskell.org > Sub

Properly writing typechecker plugins

Hi all, I have recently decided to try writing a GHC typechecker plugin so I can get my hands on some extra operations on type-level strings. My plugin works, but only sort of—I know some things about it are plain wrong, and I have a sneaking suspicion that plenty of other things are not