Hi, I have a nice big data structure that I serialise to a file using "show", and read back in using "read". This data structure has deriving (Read, Show), which makes it all nice and easy to save and load this data structure, without worrying about parsing code etc. The problem is that this data structure can become quite big, and while show operates lazily, read does not. I understand the reason for this - that it internally calls reads and that on a parse error reads will not return a result - i.e. it has to get to the end to determine whether the parse was valid or not. However, in my particular case, I know the data structure is valid, and if it isn't then I'm quite happy with the parser throwing an error half way through - after having lazily returned half of the data. A short example, which shows up the exact same issue is: head ((read $ show [1..n]) :: [Int]) The time of this operation is dependant on n, because of the strictness of read. What is the best way to modify the code to have read operate lazily? Is there any method that doesn't require writing a custom parser? Is there any standard way for solving a problem like this? Thanks Neil
On 2/16/06, Neil Mitchell
What is the best way to modify the code to have read operate lazily? Is there any method that doesn't require writing a custom parser? Is there any standard way for solving a problem like this?
Honestly, don't use read. It's icky.
Check out ReadP or parsec, they are far superior in general. I think
there was a suggestion of replacing Read with ReadP?
--
Taral
Honestly, don't use read. It's icky.
Check out ReadP or parsec, they are far superior in general. I think there was a suggestion of replacing Read with ReadP?
The whole point is not about writing a parser, its about having a parser written for me with deriving Read - unfortunately their is no deriving LazyRead or deriving Parsec etc. Thanks Neil
Neil Mitchell
Check out ReadP or parsec, they are far superior in general. I think there was a suggestion of replacing Read with ReadP?
The whole point is not about writing a parser, its about having a parser written for me with deriving Read - unfortunately their is no deriving LazyRead or deriving Parsec etc.
Well, DrIFT can derive my TextParser class (another proposal for a replacement of Read in haskell-prime). However, TextParser isn't lazy in the way you would like. It can detect failure early and commit to it, but detecting success early, in order to commit to returning the initial portion of the datastructure, is not so nice to express. Essentially, rather than having an indication of success/failure in the type system, using the Maybe or Either types, you are asking to return the typed value itself, with no wrapper, but perhaps some hidden bottoms buried inside. One could certainly define such a parsing set-up, but there are no standard ones I know of. The attraction of lazy parsing is obvious, but there is a cost in terms of safety. Regards, Malcolm
On Thu, Feb 16, 2006 at 11:28:08PM +0000, Malcolm Wallace wrote:
Essentially, rather than having an indication of success/failure in the type system, using the Maybe or Either types, you are asking to return the typed value itself, with no wrapper, but perhaps some hidden bottoms buried inside. One could certainly define such a parsing set-up, but there are no standard ones I know of. The attraction of lazy parsing is obvious, but there is a cost in terms of safety.
Yeah, I have thought about the best way to do this before, something like all combinators by default being irrefutable meaning they always succeed perhaps placing bottoms in the structure, with a specific 'try' like in parsec that will let you try a path and backtrack locally. I was thinking something like a continuation based error monad where the error continuation was 'bottom' unless overridden locally, but I never could get the types to work out quite right. perhaps rank-n types or following the process outlined in the parallel parsing combinators paper will afford a better result. John -- John Meacham - ⑆repetae.net⑆john⑈
participants (4)
-
John Meacham -
Malcolm Wallace -
Neil Mitchell -
Taral