On 7 Nov 2002, Alastair Reid wrote:
> > Why not just define your own function, much like `read`, that
> > produces a more suitable error message?
>
> readsPrec (i.e., the class method) doesn't report how far it got when
> it reports failure.
Yes, that's true if no prefix is a valid parse. In th
thanks for the suggestions along the lines of
> Why not just define your own function, much like `read`, that produces a
> more suitable error message?
but in this case, I can't change the names and types
(since the code is used by students in assignments that are already running)
also, I want t
> Why not just define your own function, much like `read`, that
> produces a more suitable error message?
readsPrec (i.e., the class method) doesn't report how far it got when
it reports failure.
One could change that but this requires a change to the report and to
the code compilers derive when
On Thu, 7 Nov 2002, Johannes Waldmann wrote:
> Dear all, I would welcome some advice
> on getting better error messages
> when using read :: Read a => a
>
> The problem is, `readsPrec' (the class method)
> eats the longest feasible input prefix,
> but when I call `read' (built-in prelude funct
hi,
Johannes Waldmann wrote:
This is correct, but I would like to show (in the error message)
the prefix that *was* parsed as well.
If `read' was a class method, I could override it.
(Compare class Show, where there is the method `showsPrec',
but since H98 (?), `show' is a class method as well.)
Dear all, I would welcome some advice
on getting better error messages
when using read :: Read a => a
The problem is, `readsPrec' (the class method)
eats the longest feasible input prefix,
but when I call `read' (built-in prelude function)
on a string that does not parse, but that has a valid p
