want better error msg with Class Read
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 prefix, I get this:
Inter> readsPrec 0 "1 ) " :: [(Integer,String)] [(1," ) ")] Inter> read "1 )" :: Integer
Program error: Prelude.read: no parse
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.) In my application, the type to parse is not Integer, but some expression type that might contain parentheses. Its Read instance uses the Parsec library, but I think this is irrelevant to the above question. Best regards, -- -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ -- -- joe@informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/207 --
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.)
In my application, the type to parse is not Integer, but some expression type that might contain parentheses. Its Read instance uses the Parsec library, but I think this is irrelevant to the above question.
why bother with the read class? it seems to be only good for quick hacks. if you already have a parsec parser and worry about the quality of error messages you should probably use something different. if you want to overload the parsing function you could create your own class, with perhaps a more useful monad than the fixed combination of state and lists offered by Read. bye iavor -- ================================================== | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | ==================================================
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 function) on a string that does not parse, but that has a valid prefix, I get this:
Inter> readsPrec 0 "1 ) " :: [(Integer,String)] [(1," ) ")] Inter> read "1 )" :: Integer
Program error: Prelude.read: no parse
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.)
Why not just define your own function, much like `read`, that produces a more suitable error message? -- Dean
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 you type 'deriving Read' and the code in the prelude and any libraries you use. This is worthwhile but is quite a large change. -- Alastair Reid alastair@reid-consulting-uk.ltd.uk Reid Consulting (UK) Limited http://www.reid-consulting-uk.ltd.uk/alastair/
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 the case Johannes gave--where there was a valid parse plus trailing garbage--one could, using readsprec, report a better message. But a general solution requires significant changes as you said. -- Dean
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 to use standard (i. e. Prelude) functions and classes as far as possible. (otherwise, students will ask what the Prelude is good for :-) For some types, I have a Parsec parser, but for others I just do `deriving Read'. (So the derived parsers possibly call the Parsec parsers.) Let me repeat that I would welcome if `read' was a class method, instead of a function. I mentioned that `show' is a Show method nowadays, while it was a function in Haskell-1.4. What were the reasons to change this? Does my example count as a reason to do a similar change for `read' at some point in the future? best regards, -- -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ -- -- joe@informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/207 --
participants (4)
-
Alastair Reid -
Dean Herington -
Iavor S. Diatchki -
Johannes Waldmann