Why doesn't the implementation simply tack on a line number to the error
message? One easy way to do this is to give an address/offset to where the
error occurred, and then recompile the module to find the line number. This
is a fairly common strategy among traditional compilers, especially Bor
People have written:
| Or you can do what hbc has done for donkey's years
| and include 'showType' in Show.
:
| Incidentally, nhc98 also has had 'showType' in class
| Show since the year dot - only Hugs and ghc lack it.
| (Does anyone know why this idea didn't make it into
| Haskell'98?)
Malcolm Wallace wrote:
>
> > > class ShowType a where
> > > showType :: a -> String
> >
> > Or you can do what hbc has done for donkey's years and
> > include 'showType' in Show.
>
> Incidentally, nhc98 also has had 'showType' in class Show since the
> year dot - only Hugs and ghc la
> > class ShowType a where
> > showType :: a -> String
>
> Or you can do what hbc has done for donkey's years and
> include 'showType' in Show.
Incidentally, nhc98 also has had 'showType' in class Show since the
year dot - only Hugs and ghc lack it. (Does anyone know why this
idea d
[EMAIL PROTECTED] writes:
>
...
>
> Although you can't show the value (because there isn't one), you can
> at least show the type of the expression:
>
> class ShowType a where
> showType :: a -> String
Or you can do what hbc has done for donkey's years and
include 'showType'
On 31-Mar-2000, S.D.Mechveliani <[EMAIL PROTECTED]> wrote:
>
> Now, what should Prelude.take
> think of Prelude.take (-1) (x:y:z:xs),
>
> how could it decide to display x ?
> The compiler does not know whether show x
> would lead to the infinite printing.
>
> Example: take (-1)
To my suggestions on the error messages
Marc van Dongen <[EMAIL PROTECTED]> writes
> Printing the argument of a function as part of an error
> message may lead to infinite error messages.
> [..]
> A call to error terminates execution of the program
> and returns an appropr
> instance ShowType a => ShowType [a]
>where
>showsType xs = ('[':) . showsType x . (']':) where ~(x:_) = xs
>
> Looks like ~(x:_) gives access to a constant instance operation
> on the type of an element of xs even when xs is empty.
>
> Looks like it works. But I do not understan
Fri, 31 Mar 2000 12:37:13 +0100, Keith Wansbrough <[EMAIL PROTECTED]>
pisze:
> [it's no accident that class constraints `C a =>' are written the way
> they are... they are really extra arguments `CDict a ->'.]
Why are they written uncurried?
It's easier to split a curried long context among se
On 31-Mar-2000, Keith Wansbrough <[EMAIL PROTECTED]> wrote:
> Sergey writes:
> > [sketch of how to implement better error messages]
> The problem with this is that there is a performance penalty to be
> paid for overloading a function in this way.
...
> Perhaps this c
Malcom and Sergey write:
> instance ShowType a => ShowType [a]
> where
> showsType xs = ('[':) . showsType x . (']':) where ~(x:_) = xs
Perhaps
where [x] = [error "not used"] `asTypeOf` xs
gives the idea better.
--KW 8-)
--
: Keith Wansbrough, MSc, BSc(Hons) (Auckland) --
| To: Simon Peyton-Jones
| Cc: '[EMAIL PROTECTED]'; [EMAIL PROTECTED]
| Subject: Re: improving error messages
|
|
| On 30-Mar-2000, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
| > | What do you think of improving the error messages like
| > | Prelu
On 30-Mar-2000, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
> | What do you think of improving the error messages like
> | Prelude.take: negative argument
> | (for say, take (-1) [(0,'b'),(1,'a')] )
>
> That would b
Malcolm Wallace <[EMAIL PROTECTED]> writes
>> And for (head []) there's really no useful info to hand. So I'm stumped.
> Although you can't show the value (because there isn't one), you can
> at least show the type of the expression:
Printing the type is very desirable in this situation.
But
On Fri, 31 Mar 2000, S.J.Thompson wrote:
> To help students I have compiled a list of messages and examples of code that
> provoke them. In many cases a little effort would, I guess, lead to vastly
> more informative error messages. I'd be interested to hear what you (an
> The problem with this is that there is a performance penalty to be
> paid for overloading a function in this way. `take' is implemented as
> a function of two arguments, as you would expect. It is given a
> number and a list; it has no idea what type the list has, nor does it
> need to: it jus
Sergey writes:
> Maybe, there exists another possibility to print the values in the
> error message like for
>take (-1) xs, y % 0
>
> The implementors declare the "internal"
> class ServiceShow where serviceShows :: ...
> invisible for the us
ing* to be the instance of ServiceShow,
serviceShow the *functions* as `' ...
and apply serviceShows to form the error messages.
?
But I wrote recently kind of rubbish on the subject of head [].
And I am sorry if this one occurs silly too!
--
Sergey Mechveliani
[EMAIL PROTECTED]
To my suggestion on the error messages
Ketil Malde <[EMAIL PROTECTED]> writes
> [..]
> e.g instead of Hugs' Prelude head:
>
>head :: [a] -> a
>head (x:_)= x
>
> we can use:
>
>head :: [a] ->
> take :: Int -> [a] -> [a]
>If you want to define your own take
> mytake :: Show a => Int -> [a] -> [a]
>that's fine, but it's a different function.
>
>And for (head []) there's really no useful info to hand. So I'm stumped.
Although you can't show the value (because there isn't one)
students do have, however, is
with error messages, which often leave a bit to be desired. An incorrectly
terminated block of definitions can lead to the message
ERROR "test.lhs" (line 2): Syntax error in input (unexpected `;')
for a file in which there is no a `;' i
| What do you think of improving the error messages like
| Prelude.take: negative argument
| (for say, take (-1) [(0,'b'),(1,'a')] )
That would be splendid. But I don't see how to do it.
take :: Int -> [a] -> [a]
Since ta
As a relative novice who's been bitten by these things, I'd like to
second the request for more detailed "program error" messages.
When the question was last raised on comp.lang.functional, I think it
sort of concluded with a suggestion to add an 'error' case t
Dear Haskell implementors,
What do you think of improving the error messages like
Prelude.head: empty list
(for say, head [] :: (Int,Char) )
Prelude.take: negative argument
(for say, take (-1) [(0,'b&#x
On 19 Aug, Mark P Jones wrote:
> [...] note that the error messages that prompted
> Jon's comment didn't have anything to do with sophisticated type systems.
> Dealing with those kinds of things requires some hard work, but it isn't
> research, and so it's
Reg writes:
> This little problem raises two challenges for compiler developers:
> (a) improving diagnostic messages (a perennial issue), and (b) (semi)
> automating error correction. In this case the diagnostic message
> is pretty good, except that is doesn't indicate where the IO term
> is or w
26 matches
Mail list logo
