Lazy read

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Lazy read

Neil Mitchell
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
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Lazy read

Taral
On 2/16/06, Neil Mitchell <[hidden email]> wrote:
> 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 <[hidden email]>
"Computer science is no more about computers than astronomy is about
telescopes."
    -- Edsger Dijkstra
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Lazy read

Neil Mitchell
> 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
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Lazy read

Malcolm Wallace
Neil Mitchell <[hidden email]> writes:

> > 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
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Lazy read

John Meacham
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⑈
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe