Re: [Haskell-cafe] How to debug GHC
Donn Cave <[EMAIL PROTECTED]> writes: >> Ideally, I think something like this should be the default behavior >> for these functions. > But something like this should happen for any function, shouldn't > it? Any function where pattern match could fail, yes. (Or should that be any partial function?) The burden is on the programmer to prove that they won't fail, and some of these tend, IME, to be more troublesome than others. > [I want to know] who called who all the way from "main" to "head", > because the key function is going to be one somewhere in the middle. Perhaps. I am told stack backtraces are difficult with non-strict semantics. (Are you being ironic?) File names and line numbers are a compromise that happens to be easy to implement. > Anything less general than this seems less than ideal to me. I guess that's why we still have to suffer nearly information-free error messages, when the 90% solution is fairly trivial. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to debug GHC
Thanks, Ketil, your suggestion really helped me ! Thanks to Claus for the tips !
On 4/26/05, Ketil Malde <[EMAIL PROTECTED]> wrote:
>
> "Claus Reinke" <[EMAIL PROTECTED]> writes:
>
> > no direct answer to your question, but a general comment on the
> > original problem (speaking from bad experience;-): things like
> > "head" have no place in a Haskell program of any non-trivial size,
> > because of their useless error messages.
>
> I must say I liked John Meacham's description of his "magic
> underscore". My solution to this problem is redefining the
> troublesome functions as cpp macros, e.g:
>
> #define BUG(C_,M_) (error ("Program error - '"++C_++"' failed: "++M_++".
> Location: '"++__FILE__++"' line "++show __LINE__))
> #define head (\xs -> case xs of { (x:_) -> x ; _ -> BUG("head","empty
> list")})
>
> Ideally, I think something like this should be the default behavior
> for these functions.
>
> -kzm
>
> PS: If anybody wants, I can mail my additional cpp definitions for 'head',
> 'at' (array indexing, I couldn't work out how to redefine the bang),
> 'read' and 'fromJust'.
> --
> If I haven't seen further, it is by standing in the footprints of giants
>
>
--
Monique Louise B.Monteiro
Msc Student in Computer Science
Center of Informatics
Federal University of Pernambuco
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Small Project coder needed
Hi everyone, Calling all Haskell coders! I just got back into coding haskell and need to take over from another lecturer at our University.I need to get a solution done out to a problem he set my students last week, and as Im attending a conference on XP for the next couple of days, I doubt I'll have time to get it done between flights. Its not a very large project, and should only take an hour or two of your time to code.I can offer between £30-45 if it meets the specs I set (and functions 100% of course!). Let me know before the weekend, Thanks Mike Richards -- ___ Get your free email from http://mail.oxygen.ie Powered by Outblaze ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to debug GHC
On Tue, 26 Apr 2005, Ketil Malde wrote:
> "Claus Reinke" <[EMAIL PROTECTED]> writes:
>> no direct answer to your question, but a general comment on the
>> original problem (speaking from bad experience;-): things like
>> "head" have no place in a Haskell program of any non-trivial size,
>> because of their useless error messages.
>
> I must say I liked John Meacham's description of his "magic
> underscore". My solution to this problem is redefining the
> troublesome functions as cpp macros, e.g:
>
> #define BUG(C_,M_) (error ("Program error - '"++C_++"' failed: "++M_++".
> Location: '"++__FILE__++"' line "++show __LINE__))
> #define head (\xs -> case xs of { (x:_) -> x ; _ -> BUG("head","empty
> list")})
>
> Ideally, I think something like this should be the default behavior
> for these functions.
But something like this should happen for any function, shouldn't it?
I mean, ideally when we write a large program, we try to write many
functions that each support some general operation and are called many
times throughout the program at various levels, and maybe have some
potential to fail. The ideal situation is when I can tell, from the
top level error handler output emailed to me by the person who ran into
the problem, who called who all the way from "main" to "head", because
the key function is going to be one somewhere in the middle.
Anything less general than this seems less than ideal to me. If it's
obvious that it isn't good enough for head to announce that the error
came from "head", and instead we need to also identify head's caller,
then it should be obvious that this requirement is recursive.
Donn Cave, [EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do statement
At 10:35 AM -0500 2005/4/26, Walt Potter wrote: Can anyone point me to examples of using the do statement which does not involve IO? ParseLib.hs, which is packaged with Hugs, has many examples. -- -- Hamilton Richards, PhD Department of Computer Sciences Senior Lecturer The University of Texas at Austin 512-471-9525 1 University Station C0500 Taylor Hall 5.138Austin, Texas 78712-0233 [EMAIL PROTECTED][EMAIL PROTECTED] http://www.cs.utexas.edu/users/ham/richards -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] do statement
Walt Potter wrote: > Can anyone point me to examples of using the do statement which does > not involve IO? > > I find that the texts I have do not provide enough examples. Tale a look at the documentation for Parsec, you'll find many examples of "do" with no I/O. http://www.cs.uu.nl/~daan/download/parsec/parsec.html Greg Buchholz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] do statement
Can anyone point me to examples of using the do statement which does not involve IO? I find that the texts I have do not provide enough examples. Thanks, Walt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] FFI and pointers to pointers
On 25 April 2005 21:40, John Meacham wrote: > On Mon, Apr 25, 2005 at 12:51:04PM +0100, Simon Marlow wrote: >> The syntax you want is >> >> foreign import ccall "&bar" :: Ptr CInt >> >> But note that GHC 6.4 has a bug whereby this doesn't work as expected >> when compiling via C. Either use the native code generator (-fasm) >> or wait for 6.4.1. > > Any ETA on 6.4.1? I am debating whether to rewrite code to work around > this bug or just wait for the point-release? We don't have any firm plans yet. It makes sense to wait until the flow of bug reports has slowed, and that hasn't happened yet. But I'll take your message as a vote for sooner rather than later. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] How to debug GHC
Hi, all, I'm developing a back end for GHC and I have the following problem: my program is throwing an "empty list exception" due to head [] and I need to compile GHC with -prof -auto-all in order to see the stack trace when running it with +RTS -xc -RTS. I changed the makefile but the option +RTS -xc -RTS was not recognized as an available RTS option Does anyone have any idea about how I can do that ? Thanks in advance, -- Monique Louise B.Monteiro Msc Student in Computer Science Center of Informatics Federal University of Pernambuco ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to debug GHC
"Claus Reinke" <[EMAIL PROTECTED]> writes:
> no direct answer to your question, but a general comment on the
> original problem (speaking from bad experience;-): things like
> "head" have no place in a Haskell program of any non-trivial size,
> because of their useless error messages.
I must say I liked John Meacham's description of his "magic
underscore". My solution to this problem is redefining the
troublesome functions as cpp macros, e.g:
#define BUG(C_,M_) (error ("Program error - '"++C_++"' failed: "++M_++".
Location: '"++__FILE__++"' line "++show __LINE__))
#define head (\xs -> case xs of { (x:_) -> x ; _ -> BUG("head","empty list")})
Ideally, I think something like this should be the default behavior
for these functions.
-kzm
PS: If anybody wants, I can mail my additional cpp definitions for 'head',
'at' (array indexing, I couldn't work out how to redefine the bang),
'read' and 'fromJust'.
--
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to debug GHC
> I'm developing a back end for GHC and I have the following problem:
> my program is throwing an "empty list exception" due to head [] and I
> need to compile GHC with -prof -auto-all in order to see the stack
> trace when running it with +RTS -xc -RTS. I changed the makefile but
> the option +RTS -xc -RTS was not recognized as an available RTS option
>
> Does anyone have any idea about how I can do that ?
Hi,
no direct answer to your question, but a general comment on the original
problem (speaking from bad experience;-): things like "head" have no place
in a Haskell program of any non-trivial size, because of their useless error
messages.
Whenever you read some code that includes an unguarded call to
head (where the non-emptyness of the list is not immediately obvious),
you are looking at a nasty trouble spot - get rid of it now!
At the very least, use something like Control.Exception.assert to guard
uses of partial functions like head, or define your own "safeHead":
safeHead msg [] = error msg
safeHead msg (h:_) = h
and replace unguarded uses of head with calls to safeHead "" (such replacements can
be automated, at least partially, so you can follow this approach to
debug your problem and avoid similar problems in future).
However, that is only when you've already messed up your code and
"only want to get rid of this kind of problem quickly". Otherwise, I
often prefer explicit use of pattern matching/case for self-documentation:
case l of { (h:_) -> h; _ -> error " should never happen!"}
if you're in a branch of a case, you can not only be sure that l is
non-empty, you have already named its head.
Better to improve the code than to use bigger debuggers?-)
Cheers,
Claus
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
