Hi, Since my hopes of finally merging Nested CPR have recently been crushed again, I hope that we can include the implementation of the UnliftedDatatypes extension (proposal https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0265-un..., implementation https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2218). It was on ice since it depends on the BoxedRep proposal, but if BoxedRep is going to make it, surely UnliftedDatatypes can make it, too. I expect quite a few bugs, simply because I don't have much code to test it on yet. But I'm very confident that existing code isn't impacted by that, as most of the functionality (CodeGen for unlifted types, most importantly) was already there and I only had to refine a conditional here and there. Cheers, Sebastian Am Mi., 10. Feb. 2021 um 18:42 Uhr schrieb Ben Gamari :

Roland Senn writes:

...

I hope ticket #19157 will make it in the GHC 9.2 release. In the GHCi debugger it adds the possibility to set ignore counts to breakpoints. The next <count> times the break point is reached the program's execution does not stop. This feature is available in nearly every debugger, but until now not yet in the GHCi debugger. Merge request !4839 is ready for review (and it's NOT rocket science...)

Indeed, this seems quite reasonable. I don't see any reason why we shouldn't be able to get it in to 9.2.1.

Cheers,

- Ben

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

Simon Peyton Jones via ghc-devs writes:

Yes I agree, unlifted data types would be terrific.

From: ghc-devs On Behalf Of Sebastian Graf Sent: 11 February 2021 10:25 To: Ben Gamari Cc: ghc-devs Subject: Re: Plan for GHC 9.2

Hi,

Since my hopes of finally merging Nested CPR have recently been crushed again, I hope that we can include the implementation of the UnliftedDatatypes extension (proposalhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fblob%2Fmaster%2Fproposals%2F0265-unlifted-datatypes.rst&data=04%7C01%7Csimonpj%40microsoft.com%7C730e3d94506e454a0e9808d8ce777010%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637486360556220696%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=RtIcZVbhIhqLo2KvXzUME5alwqQM7pI2e2dTLFGSGkI%3D&reserved=0, implementationhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fmerge_requests%2F2218&data=04%7C01%7Csimonpj%40microsoft.com%7C730e3d94506e454a0e9808d8ce777010%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637486360556230694%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=71V9d0KIbAjVD5h9B6ZtmO%2FCDpFI3ZtcfOBt5%2BTUEeY%3D&reserved=0). It was on ice since it depends on the BoxedRep proposal, but if BoxedRep is going to make it, surely UnliftedDatatypes can make it, too.

I expect quite a few bugs, simply because I don't have much code to test it on yet. But I'm very confident that existing code isn't impacted by that, as most of the functionality (CodeGen for unlifted types, most importantly) was already there and I only had to refine a conditional here and there.

It would indeed be very exciting to finally have UnliftedDataTypes. If things turn out to be non-trivial then I think we should open to letting it slide for 9.4, but otherwise I am open to merging for 9.2 if a patch appeared. Cheers, - Ben