Hello Tamar,
Just wanted to send a quick note expressing my gratitude for these
improvements! My first professional work in Haskell targeted Windows
platforms, and I'm sure there are many others out there who appreciate
the tireless work you've done to keep GHC's Windows support chugging
along.
On July 17, 2020 6:51:25 PM EDT, Moritz Angermann
wrote:
>Can’t dependent haskell be 10?
>
>On Sat, 18 Jul 2020 at 1:09 AM, Alan & Kim Zimmerman
>
>wrote:
>
>> I have to admit this thought had crossed my mind too.
>>
>> Alan
>>
>> On Fri, 17 Jul 2020 at 17:11, Brandon Allbery
>wrote:
>>
>>>
Hi,
There is an exceptional number of changes stated for the next release.
* Better pattern matching coverage detection
* New windows IO manager
* Linear types
* Large-scale typechecker changes - Taming the Kind Inference Monster,
simplified subsumption
* Better register allocation, improving
It is interesting that Eric choose this particular example, as it is one of
the few types of errors where I usually find GHC's suggestions for fixes to
be quite useful---I am talking about the errors where you forgot to import
something (or you mistype it's name) and GHC suggests that you import
Hi All,
In case you've missed it, about 150 or so commits were committed to master
yesterday. These commits add WinIO (Windows I/O) to GHC. This is a new I/O
manager that is designed for the native Windows I/O subsystem instead of
relying on the broken posix-ish compatibility layer that MIO
> And while Simon is the only
> one I'm aware of, for whom this breaks
For what it's worth, I am hitting the same issue when building GHC.
Ryan S.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
On July 17, 2020 12:10:33 AM EDT, Erik de Castro Lopo
wrote:
>Hi all,
>
>Although it was many years ago I did spend soem time working on GHC
>and I do know what a thankless task it is. I made a compliant about
>GHC error messages on an internal Slack channel and Mortiz encouraged
>me to repeat
I agree that good error messages are crucial. I also agree that it can be hard
for new feature designers to anticipate all the ways things might go wrong, and
you've hit several bumps here.
I've filed https://gitlab.haskell.org/ghc/ghc/-/issues/18466, which observes
how painful this can be and
Thanks Erik. Error message quality is crucial, as you say.
But it's a very hard thing to measure, because it's a matter of human
judgement. For example, you suggest
| I would like to suggest that a prerequesite for merging of new features would
| be that it provides good error messages
