News aggregator

Improve error reporting with semantic validations in Parsec?

Haskell on Reddit - Thu, 05/22/2014 - 1:43am

I've been trying to get more accurate Parsec error reporting when failure is determined by the semantic value for a parsed item. For instance, consider the following simple parser (which is a minimal example for the problem at hand, but one which I actually encountered):

import Control.Applicative import Control.Monad import Data.Word import Text.Parsec hiding ((<|>)) import Text.Parsec.ByteString parseWord16 :: Parser Word16 parseWord16 = do n <- read <$> many1 digit unless (0 <= n && n <= 0xffff) $ fail ("Word16 literal out of range ("++show n++")") return $! fromInteger (n :: Integer) parseW16Pair :: Parser (Word16,Word16) parseW16Pair = (,) <$> parseWord16 <* char '#' <*> parseWord16

This already works quite ok:

> parse (parseW16Pair <* eof) "" "12345#123" Right (12345,123) > parse (parseW16Pair <* eof) "" "#12345#123" Left (line 1, column 1): unexpected "#" expecting digit > parse (parseW16Pair <* eof) "" "12345#123#" Left (line 1, column 10): unexpected '#' expecting digit or end of input > parse (parseW16Pair <* eof) "" "12345##123#" Left (line 1, column 7): unexpected "#" expecting digit > parse (parseW16Pair <* eof) "" "12345" Left (line 1, column 6): unexpected end of input expecting digit or "#"

However, if the parsing fails due to the out-of-range fail, the error reporting is rather confusing and doesn't point to the proper source-location (I'd expect the error to point to the start of the offending word16-literal, and not expecting an additional item):

> parse (parseW16Pair <* eof) "" "123456" Left (line 1, column 7): unexpected end of input expecting digit Word16 literal out of range (123456) > parse (parseW16Pair <* eof) "" "123456#1234" Left (line 1, column 7): unexpected "#" expecting digit Word16 literal out of range (123456)

How can I write the parser in such a way to get more accurate error reporting?

submitted by RedLambda
[link] [3 comments]
Categories: Incoming News

pipes: Why must a producer block on yield?

Haskell on Reddit - Wed, 05/21/2014 - 7:41pm

A producer without effects does not have to wait to continue producing values correctly. It could keep working in a separate thread and hold a buffer for the rest of the pipe so it doesn't have to wait that long.

I know it's possible with Pipes.Concurrent but then you must spawn mailboxes beforehand and such for what's actually just an effectless parallelisation. Could it be possible to hide this in a buffer Pipe?

submitted by vincentrevelations
[link] [5 comments]
Categories: Incoming News

Haskell.org server status

del.icio.us/haskell - Wed, 05/21/2014 - 4:28pm
Categories: Offsite Blogs

Haskell.org server status

del.icio.us/haskell - Wed, 05/21/2014 - 4:28pm
Categories: Offsite Blogs

www.fpcomplete.com

del.icio.us/haskell - Wed, 05/21/2014 - 3:45pm
Categories: Offsite Blogs

mergesort Haskell

del.icio.us/haskell - Wed, 05/21/2014 - 2:41pm
Categories: Offsite Blogs