Re: Rewriting plugins: request for feedback

[Sam Derbyshire]

Hey everyone,

I've put up some haddocks for this new type-checking plugin API, see here:
https://sheaf.github.io/ghc-tcplugin-api/GHC-TcPlugin-API.html.
(The page is mainly meant to be navigated using the contents pane.)

I hope this might be a more welcoming point of entry for people who are
interested in learning about GHC typechecker plugins.

Let me know what you think,

Thanks,

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

Re[2]: GHC and the future of Freenode

[Sebastian Graf]

Re: memory usage: I get that people don't like bloated Electron clients 
when they already run a browser instance, but fortunately, Element 
doesn't need to be run as a standalone app (*).
Well, except when you want to search encrypted history. But then you're 
out of luck with irccloud, too...


I run Element in a pinned Firefox tab, and according to its task manager 
it reports 27.4MB, which is about the same for my WhatsApp tab. It's a 
bit more than irccloud (about 20MB), but I also have quite a few chats 
in that one tab. It's also quite a lot less than every individual MR 
page of our GitLab instance (27-110MB), of which I have pinned about 
5-10 at any time, so it really doesn't matter much.


Since the Matrix<->Libera.chat bridge works now, I have next to no 
incentive to push for Matrix at the moment, although I still would 
prefer it.
All arguments have been said, so I won't repeat them. It seems like this 
discussion will go stale in time without anyone stepping up to force a 
migration. Fine with me.


Sebastian

-- Originalnachricht --
Von: "Jakub Zalewski" 
An: "Janek Stolarek" ; ghc-devs@haskell.org
Gesendet: 16.06.2021 17:02:28
Betreff: Re: GHC and the future of Freenode


On Tue Jun 15, 2021 at 3:18 PM CEST, Janek Stolarek wrote:

 Apparently, Freenode deleted all registered users and channels several
 hours ago.


I guess that should solve the problem of communities being split between
Freenode and Libera.

If I may add towards using IRC, even though it may seem archaic towards
newcomers:

- it allows them to join without registration (via web.libera.chat), and
- it allows them to use a client of their choosing (I am not aware of
  any stable Matrix clients beside Element).

From my own experience, Electron-based clients (Element included)
consume unreasonable amounts of RAM:  Element is consuming ~700MiB of
RAM just to stay idle on my machine.  To give a fair comparison, the tab
for irccloud tends to consume ~300MiB.

--
Jakub
___
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 simplified subsumption really necessary?

[Simon Peyton Jones via ghc-devs]

rather, it's that it completely screws up my intuition about what should be 
valid Haskell.

I'm sorry to hear that Chris.   It's exactly backwards from what I would expect 
- the typing rules with simple subsumption are, well, simpler than those for 
complicated subsumption, and so one might hope that your intuition had fewer 
complexities to grapple with.

Maybe it's partly a matter of explanation and presentation.  Do you have an 
example of a case in which your intuition was screwed up by the simple 
subsumption rules?  Discussing in the abstract is often un-illuminating.

But wouldn't it be possible to choose a desugaring with seq that doesn't do so?

I just don't know how to do that.  Maybe someone else does.

Meanwhile, Quick 
Look
 depends strongly on simple subsumption.  And I'm very keen on QL.

Simon


From: ghc-devs  On Behalf Of Chris Smith
Sent: 16 June 2021 14:39
To: GHC developers 
Subject: Is simplified subsumption really necessary?

This might be in the "ship has sailed" territory, but I'd like to bring it up 
anyway.  
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst
 says:

Suppose GHC lacked all four features, and someone proposed adding them. That 
proposal would never leave the launchpad.

Let's test that hypothesis.

I've been spending increasing amounts of time fighting against simplified 
subsumption while porting Haskell code to GHC 9.0.  It's not that any specific 
instance of this problem is hard to fix; rather, it's that it completely screws 
up my intuition about what should be valid Haskell.  It doesn't help that HLS 
still requires 8.10.4, so I usually don't find out I've broken my libraries for 
GHC 9.0 until continuous integration kicks in.  At this point, it's become 
fairly routine that my code that works fine with 8.10.4 is broken with 9.0, and 
this makes me sad.

Understandably, eta expansion reducing the strictness of terms is bad.  But 
wouldn't it be possible to choose a desugaring with seq that doesn't do so?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC and the future of Freenode

[Jakub Zalewski]

On Tue Jun 15, 2021 at 3:18 PM CEST, Janek Stolarek wrote:
> Apparently, Freenode deleted all registered users and channels several
> hours ago.

I guess that should solve the problem of communities being split between
Freenode and Libera.

If I may add towards using IRC, even though it may seem archaic towards
newcomers:

- it allows them to join without registration (via web.libera.chat), and
- it allows them to use a client of their choosing (I am not aware of
  any stable Matrix clients beside Element).

From my own experience, Electron-based clients (Element included)
consume unreasonable amounts of RAM:  Element is consuming ~700MiB of
RAM just to stay idle on my machine.  To give a fair comparison, the tab
for irccloud tends to consume ~300MiB.

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

Is simplified subsumption really necessary?

[Chris Smith]

This might be in the "ship has sailed" territory, but I'd like to bring it
up anyway.
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst
says:

Suppose GHC lacked all four features, and someone proposed adding them.
> That proposal would never leave the launchpad.
>

Let's test that hypothesis.

I've been spending increasing amounts of time fighting against simplified
subsumption while porting Haskell code to GHC 9.0.  It's not that any
specific instance of this problem is hard to fix; rather, it's that it
completely screws up my intuition about what should be valid Haskell.  It
doesn't help that HLS still requires 8.10.4, so I usually don't find out
I've broken my libraries for GHC 9.0 until continuous integration kicks
in.  At this point, it's become fairly routine that my code that works fine
with 8.10.4 is broken with 9.0, and this makes me sad.

Understandably, eta expansion reducing the strictness of terms is bad.  But
wouldn't it be possible to choose a desugaring with seq that doesn't do so?
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs