Hi,
I would like to learn a reasonable way (ie how others do it) to debug
programs in Haskell. Is it possible to see what's going on when a
function is evaluated? Eg in
f a b = let c = a+b
d = a*b
in c+d
evaluating
f 1 2
would output something like
f called with values
Hi Tamas
There are several ways to debug a Haskell program.
The most advanced ones are based in offline analysis of traces, I
think Hat [1] is the most up-to-date tool for this. There is a Windows
port of Hat at [5].
Another approach is to simply use Debug.Trace. A more powerful
alternative
mnislaih:
Hi Tamas
There are several ways to debug a Haskell program.
The most advanced ones are based in offline analysis of traces, I
think Hat [1] is the most up-to-date tool for this. There is a Windows
port of Hat at [5].
Another approach is to simply use Debug.Trace. A more
Tamas K Papp [EMAIL PROTECTED] writes:
I would like to learn a reasonable way (ie how others do it) to debug
programs in Haskell. Is it possible to see what's going on when a
function is evaluated? Eg in
f a b = let c = a+b
d = a*b
in c+d
evaluating
f 1 2
Hi
But why should c and d exist at runtime? They're only used
once each, so the compiler is free to replace f with
\a b - (a+b)+ a*b
Yes, and if the compiler is this clever, it should also be free to
replace them back at debug time.
I've said this before, but I think it's worth repeating:
I've also used Visual Studio, and I wouldn't mind having something
like that for Haskell. But I have to agree with Jon, I think the
best way of debugging is to understand your code. I think people who
come from imperative programming come with a mind set that you
understand your code by
Thanks for the suggestion Don,
I started the wiki page at http://haskell.org/haskellwiki/Debugging
On 06/09/06, Donald Bruce Stewart [EMAIL PROTECTED] wrote:
mnislaih:
Hi Tamas
There are several ways to debug a Haskell program.
The most advanced ones are based in offline analysis of
On Wed, Sep 06, 2006 at 06:33:32AM -0400, Lennart Augustsson wrote:
I've also used Visual Studio, and I wouldn't mind having something
like that for Haskell. But I have to agree with Jon, I think the
best way of debugging is to understand your code. I think people who
come from
Hi,
I have a question about coding and compilers. Suppose that a function
is invoked with the same parameters inside another function declaration, eg
-- this example does nothing particularly meaningless
g a b c = let something1 = f a b
something2 = externalsomething (f a b) 42
On Wed, Sep 06, 2006 at 02:19:14PM +0200,
Tamas K Papp [EMAIL PROTECTED] wrote
a message of 23 lines which said:
Cleanly means that it ends up in the right directory. How do
people usually do that? I am using ghc6 on debian testing.
Follow the usual cabal routine (everything is in the
Hallo,
On 9/6/06, Tamas K Papp [EMAIL PROTECTED] wrote:
PS: I realize that I am asking a lot of newbie questions, and I would
like to thank everybody for their patience and elucidating replies.
I am a newbie myself (second week of learning Haskell), but I'll
give it a shot: Since
[Warnings: newbie and not having tested or read the generated assembly
code.]
On Wed, Sep 06, 2006 at 09:32:07AM -0300,
Alex Queiroz [EMAIL PROTECTED] wrote
a message of 18 lines which said:
I am a newbie myself (second week of learning Haskell), but I'll
give it a shot: Since functions
Furthermore, doing that optimization (common subexpression
elimination) can lead to space leaks. So you should not count on the
compiler doing it. Besides, I often find it more readable and less
error prone to name a common subexpression; only one place to change
when you need to change
Hallo,
On 9/6/06, Lennart Augustsson [EMAIL PROTECTED] wrote:
Furthermore, doing that optimization (common subexpression
elimination) can lead to space leaks. So you should not count on the
compiler doing it. Besides, I often find it more readable and less
error prone to name a common
On Wed, Sep 06, 2006 at 02:12:28PM +0100,
Sebastian Sylvan [EMAIL PROTECTED] wrote
a message of 36 lines which said:
I think most compilers actually do CSE
And automatic memoization? Because common subexpressions can be
difficult to recognize but, at run-time, it is much easier to
recognize
On Wed, Sep 06, 2006 at 03:26:29PM +0200, Stephane Bortzmeyer wrote:
On Wed, Sep 06, 2006 at 02:12:28PM +0100,
Sebastian Sylvan [EMAIL PROTECTED] wrote
a message of 36 lines which said:
I think most compilers actually do CSE
And automatic memoization? Because common subexpressions
On 9/6/06, Sebastian Sylvan [EMAIL PROTECTED] wrote:
On 9/6/06, Stephane Bortzmeyer [EMAIL PROTECTED] wrote:
On Wed, Sep 06, 2006 at 02:12:28PM +0100,
Sebastian Sylvan [EMAIL PROTECTED] wrote
a message of 36 lines which said:
I think most compilers actually do CSE
And automatic
tpapp:
Hi,
I have a question about coding and compilers. Suppose that a function
is invoked with the same parameters inside another function declaration, eg
-- this example does nothing particularly meaningless
g a b c = let something1 = f a b
something2 =
On Wed, Sep 06, 2006 at 09:44:05AM -0400,
David Roundy [EMAIL PROTECTED] wrote
a message of 33 lines which said:
Have you even considered the space costs of this? For almost any
non-trivial bit of code I've written, automatic memoization would
result in a completely useless binary, as it
Tamas K Papp [EMAIL PROTECTED] writes:
Most of the mistakes I make are related to indentation,
I use Emacs, which has a reasonably decent mode for this. Hit TAB
repeatedly to show the possible indentations.
precedence (need to remember that function application binds
tightly).
It's not
Purely functional does give you some performance benefits, though.
Nice theory. People don't use functional languages for their performance,
mind you. All the optimizations that are supposedly made possible by having
a pure functional language tend to be either not quite doable (because of
Neil Mitchell [EMAIL PROTECTED] writes:
Hi
But why should c and d exist at runtime? They're only used
once each, so the compiler is free to replace f with
\a b - (a+b)+ a*b
Yes, and if the compiler is this clever, it should also be free to
replace them back at debug time.
And
On 9/6/06, Tamas K Papp [EMAIL PROTECTED] wrote:
or does the compiler perform this optimization? More generally, if a
function is invoked with the same parameters again (and it doesn't
involve anything like monads), does does it makes sense
(performancewise) to store the result somewhere?
Hi
All the optimizations that are supposedly made possible by having
a pure functional language tend to be either not quite doable (because of
non-termination making the language a bit less pure) or simply too hard: the
difficulty being to decide when/where the optimization is indeed going to
Hi
Yes, and if the compiler is this clever, it should also be free to
replace them back at debug time.
And where does that get us? You snipped the salient bit
where I said that you'd be debugging a different programme.
In Visual C there are two compilation modes. In debug mode, if you
Tamas K Papp [EMAIL PROTECTED] writes:
On Wed, Sep 06, 2006 at 06:33:32AM -0400, Lennart Augustsson wrote:
I've also used Visual Studio, and I wouldn't mind having something
like that for Haskell. But I have to agree with Jon, I think the
best way of debugging is to understand your
On 06/09/2006, at 8:22 PM, Neil Mitchell wrote:It's been my experience that debugging is a serious weakness ofHaskell - where even the poor mans printf debugging changes thesemantics! And everyone comes up with arguments why there is no needto debug a functional language - that sounds more like
Neil Mitchell [EMAIL PROTECTED] writes:
Hi
Yes, and if the compiler is this clever, it should also be free to
replace them back at debug time.
And where does that get us? You snipped the salient bit
where I said that you'd be debugging a different programme.
In Visual C there
Hi
I think that when it comes to debuggers and Haskell its fairly safe to say:
1) There aren't any which are production quality, regularly work out
of the box and are avaiable without much effort. There may be ones
which are debuggers (Hat/GHCi breakpoints), but we probably haven't
got to the
I simply can't let this pass without comment. It's irrelevant if you're
using a functional or imperative language, debuggers are invariably
a waste of time. The only reason to use a debugger is because you need
to inspect the contents of a processes address-space;
That's a very narrow
On 06/09/2006, at 17:10, Andrae Muys wrote:On 06/09/2006, at 8:22 PM, Neil Mitchell wrote:It's been my experience that debugging is a serious weakness ofHaskell - where even the poor mans printf debugging changes thesemantics! And everyone comes up with arguments why there is no needto debug a
Andrae Muys [EMAIL PROTECTED] wrote:
It's a truism to say if your code doesn't work it's because you don't
understand it; ...
Indeed, but tracing the execution of the code, on the test example where
it fails, will often give insight into one's misunderstanding. And often,
the person trying
On 06/09/06, David Roundy [EMAIL PROTECTED] wrote:
Before something like this were to be implemented, I'd rather see
automatic strictifying for avoidence of stack overflows (i.e. when the
stack starts filling up, start evaluating things strictly), which is
most likely another insanely dificult
On 9/6/06, Neil Mitchell [EMAIL PROTECTED] wrote:
Let take for example a bug I spent tracking down in Haskell this
weekend. The bug can be summarized as Program error: pattern match
failure: head []. And indeed, thats all you get. A quick grep reveals
there are about 60 calls to head in the
Note: I meant to send this to the whole list a couple of messages ago
but accidentally I only sent it to Lennart, sorry Lennart!
I know that Linus Torvalds doesn't find debuggers all that useful
either and he hacks C [1].
1. http://linuxmafia.com/faq/Kernel/linus-im-a-bastard-speech.html
On
John Hughes wrote:
The trouble is that this isn't always an optimisation. Try these two
programs:
powerset [] = [[]]
powerset (x:xs) = powerset xs++map (x:) (powerset xs)
and
powerset [] = [[]]
powerset (x:xs) = pxs++map (x:) pxs
where pxs = powerset xs
Try computing length (powerset
On Wed, Sep 06, 2006 at 09:56:17AM -0700, Jason Dagit wrote:
Or maybe even more extreme you could use template haskell or the c
preprocessor to fill in the line number + column.
Which is precisely what darcs does for fromJust (which we use a lot):
we define a C preprocessor macro fromJust.
David Roundy wrote:
On Wed, Sep 06, 2006 at 09:56:17AM -0700, Jason Dagit wrote:
Or maybe even more extreme you could use template haskell or the c
preprocessor to fill in the line number + column.
Which is precisely what darcs does for fromJust (which we use a lot):
we define a C
Hi
On 9/6/06, David Roundy [EMAIL PROTECTED] wrote:
Fortunately, the undefined behavior in this case is unrelated to the
lazy IO. On windows, the removal of the file will fail, while on
posix systems there won't be any failure at all. The same behavior
would show up if you opened the file for
John Hughes wrote:
The trouble is that this isn't always an optimisation. Try these two
programs:
powerset [] = [[]]
powerset (x:xs) = powerset xs++map (x:) (powerset xs)
and
powerset [] = [[]]
powerset (x:xs) = pxs++map (x:) pxs
where pxs = powerset xs
Try computing length (powerset
Hi,
prompted by a discussion about http://www.spoj.pl/problems/MUL/ on
#haskell I implemented some faster routines for reading integers,
and managed to produce a program that passes this problem.
Currently I have a single module that provides reading operations
for Integers and Ints. I'm not
Hi
I don't know what your getout plan was but when I'm in this situation
I do the following (hopefully listing this trick will help the OP):
I have headNote, fromJustNote, fromJustDefault, lookupJust,
lookupJustNote, tailNote - a whole set of functions which take an
extra note parameter - or
Hi Bertram,
Currently I have a single module that provides reading operations
for Integers and Ints. I'm not quite sure what to do with it.
Get it into base! Where it is, or what its called is less relevant -
perhaps entirely decoupled from the Read class, and I wouldn't have
thought reading
Neil Mitchell wrote:
Currently I have a single module that provides reading operations
for Integers and Ints. I'm not quite sure what to do with it.
Get it into base! Where it is, or what its called is less relevant -
Ok, one vote for base.
I'm pondering breaking compatibility with Haskell
On 2006-09-06, Andrae Muys [EMAIL PROTECTED] wrote:
Jon understates it by implying this is a Functional/Haskell specific
quality - it's not. Debuggers stopped being useful the day we
finally delegated pointer handling to the compiler/vm author and got
on with writing code that actually
scientists, who ought to know,
assure us that it must be so,
oh, let us never, never, doubt,
what nobody is sure about.
(or something like that..;-)
as everyone else in this thread, I have my own experiences and
firm opinions on the state of debugging support in Haskell (in
particular on the
Neil Mitchell [EMAIL PROTECTED] writes:
I wrote:
H'm. I've never been completely convinced that head should
be in the language at all. If you use it, you really have
to think, every time you type in the letters h-e-a-d, Am I
/really/ /really/ sure the argument will never be []?
Claus Reinke [EMAIL PROTECTED] writes:
thinking helps, but claiming that tools can't help doesn't.
Lets be absolutely clear about this: I've never claimed that
tools can't help. In this thread I've been using the term
debugger in the narrow sense implied by the OP's question --
something that
David Roundy [EMAIL PROTECTED] writes:
On Wed, Sep 06, 2006 at 09:56:17AM -0700, Jason Dagit wrote:
Or maybe even more extreme you could use template haskell or the c
preprocessor to fill in the line number + column.
Which is precisely what darcs does for fromJust (which we use a lot):
What is the practical meaning of monad laws?
(M, return, =) is not qualified as a category-theoretical monad, if
the following laws are not satisfied:
1. (return x) = f == f x
2. m = return == m
3. (m = f) = g == m (\x - f x = g)
But what practical problems can unsatisfying them cause?
50 matches
Mail list logo
