oid in a call-by-need language.
>
> Simon
>
> | -Original Message-
> | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Alastair Reid
> | Sent: 23 June 2004 21:44
> | To: S. Alexander Jacobson
> | Cc: [EMAIL PROTECTED]
> | Subject: Re: [Haskell] modern lang
> This is due to the nature of exceptions in Haskell. Evaluating the
> expression (do a <- getLine; hPutStrLn ...) does not do any IO, and it
> doesn't raise any exceptions, so the mapException doesn't get to
> annotate any exceptions.
Urgh, so the automatic annotation I suggested suffers from t
On 24 June 2004 11:54, MR K P SCHUPKE wrote:
> With reference to "mapException", I thought this seemed a good idea.
> I like the 'AnnotatedException' idea... this is much better than
> concatenating strings... However for not I thought I would test it
> as is, but it doesn't work as I thought - pe
With reference to "mapException", I thought this seemed a good idea.
I like the 'AnnotatedException' idea... this is much better than
concatenating strings... However for not I thought I would test it
as is, but it doesn't work as I thought - perhaps someone could
point out where I have gone wrong
On 24 June 2004 10:31, Alastair Reid wrote:
>> [...]
>> 2. Use the mapException trick to annotate exceptions as they
>> travel up the stack (see Alastair Reid's message). [...]
>> (2) requires that you add lots of annotations to your code, so it's
>> not entirely satisfactory for that rea
> [...]
> 2. Use the mapException trick to annotate exceptions as they
> travel up the stack (see Alastair Reid's message).
> [...]
> (2) requires that you add lots of annotations to your code, so it's not
> entirely satisfactory for that reason.
Would it be possible to generalise ghc's -
On 23 June 2004 18:39, Fergus Henderson wrote:
> On 23-Jun-2004, MR K P SCHUPKE <[EMAIL PROTECTED]> wrote:
>> This may not be the right answer to the question (which is of
>> course lets write a debugger) - But I have never used a debugger,
>> and find them more or less the most unfriendly and use
MR K P SCHUPKE <[EMAIL PROTECTED]> writes:
>>Thank you for the programming practice recomendation,
> Sorry if it seemed like that...
Huh - I thought that was sincere; certainly I am happy to learn about
sensible (or not) practices that others find useful.
> but I do feel that 'commercial quali
t: Re: [Haskell] modern language design, stone age tools
|
| On Wednesday 23 June 2004 20:38, S. Alexander Jacobson wrote:
| > It would be really nice if you could pass an
| > error message down to every function that might
| > fail. e.g. using implicit parameters*:
| >
| >myF
On Wed, Jun 23, 2004 at 06:52:32PM +0100, MR K P SCHUPKE wrote:
> >So how do you debug problems like "Prelude.head: empty list"
> >in large programs?
> for precisely this reason - and the fact that I dont like bindings
> that can fail...
Note that pattern matching rather than deconstruction funct
On Wed, Jun 23, 2004 at 09:43:46PM +0100, Alastair Reid wrote:
> 2) If you don't want to put errors in the type system, you could instead use
>exceptions something along the lines of:
>
> myFunc 0 x = mapException
> (\ err -> show err ++ "when invoked by myFunc 0")
On Wed, Jun 23, 2004 at 10:39:08AM -0700, Fergus Henderson wrote:
> On 23-Jun-2004, MR K P SCHUPKE <[EMAIL PROTECTED]> wrote:
> > This may not be the right answer to the question (which is of
> > course lets write a debugger) - But I have never used a debugger,
> > and find them more or less the mo
>Thank you for the programming practice recomendation,
Sorry if it seemed like that... I was really trying to suggest
practical measures that someone could use in the absence of a
debugger - but I do feel that 'commercial quality' code
should be bullet proof, and of a different calibre to code
for
On Wednesday 23 June 2004 20:38, S. Alexander Jacobson wrote:
> It would be really nice if you could pass an
> error message down to every function that might
> fail. e.g. using implicit parameters*:
>
>myFunc 0 x = head x with ?failMsg="myfunc 0 caused the error"
Interesting. Two variations
Thank you for the programming practice
recomendation, but I would still prefer to
have something like the implicit parameters
solution I described.
The solution you describe forces you to put code
in functions to handle cases that are outside its
domain. Usually I just want to know what function
I like to write programs so functions cannot fail...
so head should really be:
maybeHead :: [a] -> Maybe a
maybeHead (a:_) = Just a
maybeHead _ = Nothing
etc...
The the calling function can do something like:
case maybeHead x of
Just y ->
It would be really nice if you could pass an
error message down to every function that might
fail. e.g. using implicit parameters*:
myFunc 0 x = head x with ?failMsg="myfunc 0 caused the error"
Head would be defined as e.g.
head [] = fail $ "empty list.\n" ++ ?failMsg
head (x:xs) = x
I
On 23-Jun-2004, Hal Daume III <[EMAIL PROTECTED]> wrote:
> On Wed, 23 Jun 2004, Fergus Henderson wrote:
>
> > On 23-Jun-2004, MR K P SCHUPKE <[EMAIL PROTECTED]> wrote:
> > > This may not be the right answer to the question (which is of
> > > course lets write a debugger) - But I have never used a
>Hmmm... chickens and eggs. I don't see a lot of *companies* using Haskell
Actually I have used Haskell in commercial projects... and am continuing to
do so. My development environment is Vim and GHC. Same one I have used for
C/C++ VHDL Perl, and anything else...
It is not that lack of GUI tool
>So how do you debug problems like "Prelude.head: empty list"
>in large programs?
I normally dont use head, but instead code:
case x of
(a0:_) ->
_ -> fail
for precisely this reason - and the fact that I dont like bindings
that can fail...
Keean.
___
On 23-Jun-2004, Ketil Malde wrote:
> > Thirdly, profiling seems to be incompatible with the use of ghci; there
> > doesn't seem to be any easy way to build a workspace so that you can
> > get stack traces and use ghci in that workspace at the same time.
>
> You can compile with: -prof -auto-all -
On 23-Jun-2004, MR K P SCHUPKE <[EMAIL PROTECTED]> wrote:
> This may not be the right answer to the question (which is of
> course lets write a debugger) - But I have never used a debugger,
> and find them more or less the most unfriendly and useless things
So how do you debug problems like "Prelu
At 11:48 23/06/04 +0100, Malcolm Wallace wrote:
If companies are willing to invest in development, they will get the
tools they want.
Hmmm... chickens and eggs. I don't see a lot of *companies* using Haskell
right now. And probably they won't until the tools they want are available
(and more...
MR K P SCHUPKE <[EMAIL PROTECTED]> writes:
> You either end up single stepping through a million lines of code,
> or you find the error is of a complex non-localised kind anyway.
Or you find that inserting a breakpoint (or waiting to hit an exception),
examining data structures which are either i
>Unless, of course, you have:
>1) A large program operating on a large body of data that takes a long time to
debugs logs go to a file, grep and awk let you quickly find things
>3) A complex library written by someone else which contains a bug or makes
before calling out print a funtion trace li
> Seeing as Haskell is apparently such a popular language these days,
> I don't suppose a working debugger would be too much to ask for, would it?
I agree.
> In case you're wondering, yes I have already tried using Hat and Buddha.
> But I'm trying to debug a real application, not a toy one, and n
This may not be the right answer to the question (which is of
course lets write a debugger) - But I have never used a debugger,
and find them more or less the most unfriendly and useless things
You either end up single stepping through a million lines of code,
or you find the error is of a complex
--- Simon Marlow <[EMAIL PROTECTED]> wrote:
> We would be delighted if someone would take Robert's
> hsdebug and port it
> to the non-speculative version of the compiler. In
> fact, this is one of
> the items on the GHC Task list:
>
>
http://sourceforge.net/pm/task.php?func=detailtask&project_tas
On 23 June 2004 09:27, Robert Ennals wrote:
> I wrote such a debugger as part of my PhD work. It is called
> "hsdebug" and you can read the Haskell Workshop paper on it here:
>
> http://www.cambridge.intel-research.net/~rennals/hw2003.pdf
>
> Unfortunately, HsDebug depends on Optimistic Evaluati
I wrote such a debugger as part of my PhD work. It is called "hsdebug" and you
can read the Haskell Workshop paper on it here:
http://www.cambridge.intel-research.net/~rennals/hw2003.pdf
Unfortunately, HsDebug depends on Optimistic Evaluation, and it seems unlikely
that Optimistic Evaluation w
Fergus Henderson <[EMAIL PROTECTED]> writes:
> Seeing as Haskell is apparently such a popular language these days,
> I don't suppose a working debugger would be too much to ask for, would it?
Hah. You're not supposed to debug, just stare at the code until
you become enlightened (why did you thin
\begin{gripe}
Seeing as Haskell is apparently such a popular language these days,
I don't suppose a working debugger would be too much to ask for, would it?
Or even just a decent call stack trace when a program terminates with an exception?
In case you're wondering, yes I have already tried using
32 matches
Mail list logo
