One thing that wasn't available when this discussion was last active
is 'mapException' (btw, similar to 'catch'/'catches', a 'mapExceptions'
would be useful).
so for mere traces, dynamic seems to be the choice (with an option of
pseudo-cbv or the real dynamic stack).
I don't know what
Claus Reinke wrote:
Perhaps I've been misunderstanding what you mean by lexical stack?
lexical to me implies only scope information, nothing related to run
time call chains, which would be dynamic. In the dynamic case, one
can then distinguish between call-by-need stack (what actually happens
On 28/05/2009 15:09, Claus Reinke wrote:
One thing that wasn't available when this discussion was last active
is 'mapException' (btw, similar to 'catch'/'catches', a 'mapExceptions'
would be useful). For instance, appended below is the example from that
wiki page, with entirely local
Simon Marlow wrote:
On 28/05/2009 15:09, Claus Reinke wrote:
so for mere
traces, dynamic seems to be the choice (with an option of pseudo-cbv
or the real dynamic stack).
I don't know what pseudo-cbv is. And I claim the dynamic stack is
almost never what you want.
Ok, so there's one place
On 23/05/2009 14:53, Claus Reinke wrote:
JHC has had this for a while, but it calls the pragma 'SRCLOC_ANNOTATE'.
It is actually mentioned on this page:
http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack
Yes, I know, but the discussion on that page wanted to go beyond this
(possibly
One thing that wasn't available when this discussion was last active
is 'mapException' (btw, similar to 'catch'/'catches', a 'mapExceptions'
would be useful). For instance, appended below is the example from that
wiki page, with entirely local transformations to add source locations
and to use
Here are the +RTS -xc and mapException outputs together (when I
remove the mapError annotations, only the first .. is printed, so
that is the part to focus on, the rest is confusion)
Actually, it looks as if the implementation of mapException modifies
the stack that +RTS -xc prints. Not
| I'd be happy to be proven wrong in this, of course!-) I had the feeling
| that there'd been some recent work on all this and, indeed, reddit has:
|
|
http://www.reddit.com/r/haskell/comments/8mbar/finding_the_needle_stack_traces_for_g
| hc_pdf/
Sorry I've been very buried recently. Some brief
JHC has had this for a while, but it calls the pragma 'SRCLOC_ANNOTATE'.
It is actually mentioned on this page:
http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack
Yes, I know, but the discussion on that page wanted to go beyond this
(possibly triggered by your demonstration
What is really frustrating is that GHC has the machinery to do this
trivially (RULES, soon core2core phase plugins as well), only that this machinery gets applied
when source location information is no longer available, so it is useless for this problem:-(
I'd be happy to be proven wrong in
JHC has had this for a while, but it calls the pragma 'SRCLOC_ANNOTATE'.
It is actually mentioned on this page:
http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack
I am not entirely sure whether I will keep the current syntax (it
doesn't really make sense for operators), but if
Ok, I went with the preprocessor solution only. It is simple, stupid and
works well enough ... and template haskell alternative needs it anyway
not to be too unportable.
Both template haskell alternatives reported Pattern match(es) are
non-exhaustive of their own. The second alternative
Do you really want exhaustiveness, or is what you actually want safety?
I want both. Exhaustiveness checking now and forever, because it's a
modular property. Safety when somebody gets around to implementing
whole-program analysis in the compiler I use, when I feel like waiting
around
Catch already does assertion checking (1). Its runtime on moderate to
small programs (HsColour in particular) is far less than the time GHC
takes to compile them, and I still have no idea what its runtime is on
enormous programs (2). An analysis can be whole program and can be
slow, one does
Catch already does assertion checking (1). Its runtime on moderate to
small programs (HsColour in particular) is far less than the time GHC
takes to compile them, and I still have no idea what its runtime is on
enormous programs (2). An analysis can be whole program and can be
slow, one does
ndmitchell:
Catch already does assertion checking (1). Its runtime on moderate to
small programs (HsColour in particular) is far less than the time GHC
takes to compile them, and I still have no idea what its runtime is on
enormous programs (2). An analysis can be whole program and can be
If Catch says your program will not crash, then it will not crash. I
even gave an argument for correctness in the final appendix of my
thesis http://community.haskell.org/~ndm/thesis/ (pages 175-207). Of
course, there are engineering concerns (perhaps your Haskell compiler
will mis-translate
ndmitchell:
If Catch says your program will not crash, then it will not crash. I
even gave an argument for correctness in the final appendix of my
thesis http://community.haskell.org/~ndm/thesis/ (pages 175-207). Of
course, there are engineering concerns (perhaps your Haskell compiler
OK. i'm just trying to get an intuition for the analysis.
Catch is defined by a small Haskell program. You can write a small
Haskell evaluation for a Core language. The idea is to write the
QuickCheck style property, then proceed using Haskell style proof
steps. The checker is recursive - it
ndmitchell:
OK. i'm just trying to get an intuition for the analysis.
Catch is defined by a small Haskell program. You can write a small
Haskell evaluation for a Core language. The idea is to write the
QuickCheck style property, then proceed using Haskell style proof
steps. The checker is
-users@haskell.org
| Subject: Re: Should exhaustiveness testing be on by default?
|
| Neil Mitchell wrote:
| I'm not a particular fan of exhaustiveness checking. It just
| encourages people to write:
|
| foo (Just 1) [x:xs] = important case
| foo _ _ = error doh!
|
| So now when the program
...@haskell.org] On Behalf Of Peter Hercek
| Sent: 18 May 2009 10:46
| To: glasgow-haskell-users@haskell.org
| Subject: Re: Should exhaustiveness testing be on by default?
|
| Neil Mitchell wrote:
| I'm not a particular fan of exhaustiveness checking. It just
| encourages people to write:
|
| foo (Just 1
I was looking for something which works in optimized builds too.
{-# OPTIONS_GHC -fno-ignore-asserts #-}
overrides the -O default setting -fignore-asserts.
I know I could do it with preprocessor or (I think) template haskell too
but these tools seem to heavy for such a simple goal.
Given
Claus Reinke wrote:
Given how long http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack
has been under discussion, it is probably time to provide a short-term
workaround in GHC, just a token to be replaced by the current source
location.
This would be the best solution.
Although
The second solution requires QuasiQuotes, so I do not know. If I would
want to compile with a different compiler it would break. If srcloc can be
defined as a simple token (not requiring special extensions at places where
it is used) then I could define it to an empty string in some low level
... exhaustive pattern checking might well help out a lot of
people coming from untyped backgrounds...
Or even people from typed backgrounds. I worship at the altar of
exhaustiveness checking.
Do you really want exhaustiveness, or is what you actually want safety?
I want
@haskell.org
| Subject: Re: Should exhaustiveness testing be on by default?
|
| On Mon, May 18, 2009 at 4:00 PM, Norman Ramsey n...@eecs.harvard.edu wrote:
| P.S. The exhaustiveness checker does need improvement...
|
| Is it documented somewhere what deficiencies the exhaustiveness
| checker has (where
| Cc: glasgow-haskell-users@haskell.org
| Subject: Re: Should exhaustiveness testing be on by default?
|
| On Mon, May 18, 2009 at 4:00 PM, Norman Ramseyn...@eecs.harvard.edu wrote:
| P.S. The exhaustiveness checker does need improvement...
|
| Is it documented somewhere what deficiencies
... exhaustive pattern checking might well help out a lot of
people coming from untyped backgrounds...
Or even people from typed backgrounds. I worship at the altar of
exhaustiveness checking.
Do you really want exhaustiveness, or is what you actually want safety?
With
Excellent, is there a -fuse-catch flag for ghc? :)
On Tue, May 19, 2009 at 12:01 PM, Neil Mitchell ndmitch...@gmail.com wrote:
... exhaustive pattern checking might well help out a lot of
people coming from untyped backgrounds...
Or even people from typed backgrounds. I worship at the
Excellent, is there a -fuse-catch flag for ghc? :)
No, but there is for Yhc. If you write to the Haskell standard (minus
a little bit), don't like libraries and can get Yhc to compile (good
luck!) then it's just a few command lines away.
If GHC (or GHC + some scripts) could produce a single
I'm not a particular fan of exhaustiveness checking. It just
encourages people to write:
foo (Just 1) [x:xs] = important case
foo _ _ = error doh!
So now when the program crashes, instead of getting a precise and
guaranteed correct error message, I get doh! - not particularly
helpful for
Neil Mitchell wrote:
I'm not a particular fan of exhaustiveness checking. It just
encourages people to write:
foo (Just 1) [x:xs] = important case
foo _ _ = error doh!
So now when the program crashes, instead of getting a precise and
guaranteed correct error message, I get doh! - not
I'm not sure I'd want -Wall on by default (though being -Wall clean is
very good). But exhaustive pattern checking might well help out a lot of
people coming from untyped backgrounds.
http://ocaml.janestreet.com/?q=node/64
Ron's also wondering why exhaustive pattern checking isn't on ?
On 18/05/2009 12:06, Claus Reinke wrote:
I'm not sure I'd want -Wall on by default (though being -Wall clean is
very good). But exhaustive pattern checking might well help out a lot of
people coming from untyped backgrounds.
http://ocaml.janestreet.com/?q=node/64
Ron's also wondering why
... exhaustive pattern checking might well help out a lot of
people coming from untyped backgrounds...
Or even people from typed backgrounds. I worship at the altar of
exhaustiveness checking.
Anyone know why it isn't the default?
I have been bleating to GHC Central about the generally
On Mon, May 18, 2009 at 4:00 PM, Norman Ramsey n...@eecs.harvard.edu wrote:
P.S. The exhaustiveness checker does need improvement...
Is it documented somewhere what deficiencies the exhaustiveness
checker has (where it can report problems that don't exist or fails to
report problems that do...),
On Mon, May 18, 2009 at 7:59 PM, Robert Greayer robgrea...@gmail.com wrote:
On Mon, May 18, 2009 at 4:00 PM, Norman Ramsey n...@eecs.harvard.edu wrote:
P.S. The exhaustiveness checker does need improvement...
Is it documented somewhere what deficiencies the exhaustiveness
checker has (where
I'm not sure I'd want -Wall on by default (though being -Wall clean is
very good). But exhaustive pattern checking might well help out a lot of
people coming from untyped backgrounds.
http://ocaml.janestreet.com/?q=node/64
Ron's also wondering why exhaustive pattern checking isn't on ?
The exhaustiveness checker in ghc is not good. It reports
non-exhaustive matching a bit too often and also the error messages
are often not in terms of the original source but some desugared
version.
If those things were improved I think it should be always on.
On Mon, May 18, 2009 at 12:53 AM,
40 matches
Mail list logo
