Re: New implementation for `ImpredicativeTypes`

rence system. Adding > existentials will entail a substantial change to the intermediate language, > affecting every optimisation pass. > > > > Simon > > > > *From:* Alex Rozenshteyn > *Sent:* 02 September 2021 18:13 > *To:* Simon Peyton Jones > *Cc:*

Re: New implementation for `ImpredicativeTypes`

ion. *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 > *Sent:* 02 September 2021 17:10 > *To:* Simon Peyton Jones > *Cc:* GHC developers

Re: New implementation for `ImpredicativeTypes`

> I don’t know of any work studying that question specifically, but others > may have pointers. > > > > simon > > > > *From:* Alex Rozenshteyn > *Sent:* 06 September 2019 15:21 > *To:* Simon Peyton Jones > *Cc:* Alejandro Serrano Mena ; GHC developers < > ghc-d

Re: GHC and the future of Freenode

efinitely find Zulip confusing and have failed to use it every time >> I’ve tried >> >> If normal threading is lasagna layers, Zulip threading is like trying to >> hold cooked spaghetti in your ha d. >> >> On Wed, May 19, 2021 at 2:40 PM Alex Rozenshteyn >

Re: GHC and the future of Freenode

(I'm a little ashamed that I lurk on this list but the thing that brings me out of lurking is a post on communication technologies) Not Zulip. Please not Zulip. I've used Zulip once many years ago, and once this year. Both times, its interface felt clunky, and it felt like it was trying to get

Re: New implementation for `ImpredicativeTypes`

= show x > > > > Our new system can only type programs that can be written in System F. > (The tricky bit is inferring the impredicative instantiations.) > > > > Simon > > > > *From:* ghc-devs *On Behalf Of *Alex > Rozenshteyn > *Sent:* 06 September 20

Re: New implementation for `ImpredicativeTypes`

I didn't say anything when you were requesting use cases, so I have no right to complain, but I'm still a little disappointed that this doesn't fix my (admittedly very minor) issue: https://www.reddit.com/r/haskell/comments/3am0qa/existentials_and_the_heterogenous_list_fallacy/csdwlp2/?context=8=9

Re: Separating typechecking and type error reporting in two passes?

One concern I have is with the claim that "most compiled programs are type correct". This has emphatically not been my experience while developing Haskell. Often, I edit and recompile to find the next type error to fix, or the new type of the hole; this is especially easy (and automatic) in emacs

Re: more releases

I have the impression (no data to back it up, though) that no small number of users download bindists (because most OS packages are out of date: Debian Unstable is still on 7.8.4, as is Ubuntu Wily; Arch is on 7.10.1). On Wed, Sep 2, 2015 at 12:04 PM, Ben Gamari wrote: >

Request for input on #7253: Top-level bindings in GHCI

I'm thinking of working on this ticket ( https://ghc.haskell.org/trac/ghc/ticket/7253), so, as per mpickering's suggestion (https://phabricator.haskell.org/chatlog/channel/3/?at=1353572), I'm emailing the list to solicit input. My first instinct was to treat declarations like a = 1 in GHCI as