of work, I know.)
Start a wiki page! Stuff in email threads gets lost
Simon
From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
Christopher Allen
Sent: 19 June 2015 04:27
To: Ömer Sinan Ağacan
Cc: ghc-devs
Subject: Re: expanding type synonyms in error
...@haskell.org] On Behalf Of
Christopher Allen
Sent: 19 June 2015 04:27
To: Ömer Sinan Ağacan
Cc: ghc-devs
Subject: Re: expanding type synonyms in error messages
Just to add my own +1, having this when working with streaming
libraries
(I've needed it less with lens, oddly) would
threads gets lost
Simon
From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Christopher
Allen
Sent: 19 June 2015 04:27
To: Ömer Sinan Ağacan
Cc: ghc-devs
Subject: Re: expanding type synonyms in error messages
Just to add my own +1, having this when working with streaming libraries
From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
Christopher Allen
Sent: 19 June 2015 04:27
To: Ömer Sinan Ağacan
Cc: ghc-devs
Subject: Re: expanding type synonyms in error messages
Just to add my own +1, having this when working with streaming libraries
(I've
Of
Christopher Allen
Sent: 19 June 2015 04:27
To: Ömer Sinan Ağacan
Cc: ghc-devs
Subject: Re: expanding type synonyms in error messages
Just to add my own +1, having this when working with streaming
libraries
(I've needed it less with lens, oddly) would be a tremendous help
the
examples takes a bit of work, I know.)
Start a wiki page! Stuff in email threads gets lost
Simon
From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
Christopher Allen
Sent: 19 June 2015 04:27
To: Ömer Sinan Ağacan
Cc: ghc-devs
Subject: Re: expanding type synonyms
From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
Christopher Allen
Sent: 19 June 2015 04:27
To: Ömer Sinan Ağacan
Cc: ghc-devs
Subject: Re: expanding type synonyms in error messages
Just to add my own +1, having this when working with streaming libraries
(I've needed
*From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of
*Christopher
Allen
*Sent:* 19 June 2015 04:27
*To:* Ömer Sinan Ağacan
*Cc:* ghc-devs
*Subject:* Re: expanding type synonyms in error messages
Just to add my own +1, having this when working with streaming libraries
(I've
Just to add my own +1, having this when working with streaming libraries
(I've needed it less with lens, oddly) would be a tremendous help for
people learning them I think. I think I've run into the same thing as
Kostiantyn in the past.
On Thu, Jun 18, 2015 at 9:42 PM, Ömer Sinan Ağacan
It's good to see that I'm not the only one who wants this. I'm doing
some GHC hacking nowadays and I'll give it a try.
2015-06-18 4:41 GMT-04:00 Kostiantyn Rybnikov k...@k-bx.com:
I wanted to add that synonym expansion would be especially helpful in
error-messages like:
Expected type:
I wanted to add that synonym expansion would be especially helpful in
error-messages like:
Expected type: non-expanded, small type, like Producer a m ()
Actual type: your type, like Proxy a a' b b' m v
I would be glad if we could have an expansions enabling flag in GHC, and
could consider
Hi all,
While working with complex types with lots of arguments etc. errors are
becoming annoying very fast. For example, GHC prints errors in this way:
Expected type: type without any synonyms
Actual type: type with synonyms
Now I have to expand that synonym in my head to understand
Clang (and recent GCC versions) do something like this in error
messages. They say
MyString (aka std::string...lots of junk...) is uncool
maybe a similar system would help you?
Cheers,
Gabor
On 6/16/15, Ömer Sinan Ağacan omeraga...@gmail.com wrote:
Hi all,
While working with complex
GHC tries hard to preserve type synonyms where possible, but of course, it
can't preserve all of them. The general rule it tries to follow is: preserve
vanilla type synonyms; expand type families. This is true both in expected
types and actual types.
If you have a case where you believe that
14 matches
Mail list logo
