On 02/07/2014 03:05 PM, Adam Gundry wrote:
Hi,
Good error messages are a hard problem. That said, I think little tweaks
like this might make sense. Richard Eisenberg and I were discussing this
earlier, and we wondered if the following might provide an alternative
approach:
Suppose a
Though I favor the approach Adam wrote about (he and I discussed it before his
post), I think these are very valid concerns, and would have to be taken into
account in the design of any further work in this area.
One observation I would make now is that none of this proposal, as far as I can
On Tue, Feb 11, 2014 at 3:32 AM, Nicolas Frisby nicolas.fri...@gmail.comwrote:
Hi Adam. Thanks very much for the response. I'm sorry if the rest of this
reads negatively -- I'm on my phone and hence perhaps curt. I'm excited
about any dialog here!
(I'll mention that Dimitrios Vytiniotis and
On Tue, Feb 11, 2014 at 3:55 AM, José Pedro Magalhães j...@cs.uu.nl wrote:
On Tue, Feb 11, 2014 at 3:32 AM, Nicolas Frisby
nicolas.fri...@gmail.comwrote:
type family GHC.Exts.Message (c :: Constraint) :: Maybe Symbol
While I do find this problem very relevant, and think this solution is
Are we reaching the point where a wiki page and perhaps (soon) a Trac
ticket would be appropriate?
On Tue, Feb 11, 2014 at 10:10 AM, Nicolas Frisby
nicolas.fri...@gmail.comwrote:
On Tue, Feb 11, 2014 at 3:55 AM, José Pedro Magalhães j...@cs.uu.nlwrote:
On Tue, Feb 11, 2014 at 3:32 AM,
One potential source of confusion in this thread:
When Adam initially suggested a function (Constraint - Maybe String), I
believe he was referring to constraints as they slosh around within GHC, *not*
the kind-level Constraint available with ConstraintKinds. So, the
error-reporting function
Thanks for suggesting that; I was only seeing Constraint as in
ConstraintKinds.
I think the gist of my previous concerns doesn't change, though: open type
pattern matching (or some dissatisfying approx of), assuredly pure
functions, etc.
On Feb 11, 2014 12:15 PM, Richard Eisenberg
Thanks for clarifying, Richard, I should have been clearer. Constraint
was a poor choice of type without further explanation.
Nicolas, Pedro, thanks for your feedback!
On 11/02/14 18:24, Nicolas Frisby wrote:
Thanks for suggesting that; I was only seeing Constraint as in
ConstraintKinds.
I
If, when defining the `describeError' method, I wanted to refer to one of
my library's classes from inside a pattern (or guard in the rhs, I
suppose), how would I do that? Via a Template Haskell literal name? Or
would I call the TcM interface for looking up a name?
In my opinion [1], the TcM
Hi,
Good error messages are a hard problem. That said, I think little tweaks
like this might make sense. Richard Eisenberg and I were discussing this
earlier, and we wondered if the following might provide an alternative
approach:
Suppose a module provides a function
describeError ::
Hi all. I have a question for those savvy to the type-checker's internal
workings.
For uses of the following function, can anyone suggest a means of forcing
GHC to attempt to solve C a b even if a~b fails?
dslAsTypeOf :: (C a b,a~b) = a - b - a
dslAsTypeOf x _ = x
class C a b -- no methods
Also, on the topic of patching GHC for domain-specific error messages, why
not add a simple means to emit a custom error message? It would beat
piggy-backing on the no instance messages as I currently plan to.
This seems safe and straight-forward:
-- wired-in, cannot be instantiated
class
12 matches
Mail list logo
