On Tue, May 11, 2010 at 12:16 AM, Tom Hawkins tomahawk...@gmail.com wrote:
The tarball was missing its Rules.hs; as it happens, GHC has a module
named Rules.hs as well, hence the confusing error. I've uploaded a
fresh one that should work.
Thanks. This builds and installs fine.
But I
data Something = Something Int (Maybe String)
deriving Show {-! derive : Parse !-}
There is nothing in the generated parser to look for parens around the
Maybe in case it is a (Just string).
Sorry, that will be my fault. I contributed the rules for deriving
Parse to DrIFT. I am on holiday
There is the ChristmasTree package
(http://hackage.haskell.org/package/ChristmasTree) which provides a very fast
read alternative by deriving grammars for each datatype. If you want to know
the speed differences, see http://www.cs.uu.nl/wiki/bin/view/Center/TTTAS for
more information (it's in
In fact, if you just want
Read-like functionality for a set of Haskell datatypes, use polyparse: the
DrIFT tool can derive polyparse's Text.Parse class (the equivalent of Read)
for you, so you do not even need to write the parser yourself!
Cabal install DrIFT-cabalized complains. What is the
On Mon, May 10, 2010 at 4:50 PM, Tom Hawkins tomahawk...@gmail.com wrote:
In fact, if you just want
Read-like functionality for a set of Haskell datatypes, use polyparse: the
DrIFT tool can derive polyparse's Text.Parse class (the equivalent of Read)
for you, so you do not even need to write
The tarball was missing its Rules.hs; as it happens, GHC has a module
named Rules.hs as well, hence the confusing error. I've uploaded a
fresh one that should work.
Thanks. This builds and installs fine.
But I think there is something wrong with the generated parser. It
doesn't look for
In fact, the time you'd spend writing read instances would not
compare to the half hour required to learn parsec.
And your parser will be efficient (at least, according to the guys
from the parser team ;-)
I agree that Read is likely to be inefficient, but the more important
aspect is
Malcolm Wallace malcolm.wall...@cs.york.ac.uk writes:
(Declaration of interest: I wrote polyparse.)
For which I, for one, am grateful!
(So, when are you going to release an updated version with a fixed
definition of discard for the lazy parser? :p)
--
Ivan Lazar Miljenovic
On Sun, May 9, 2010 at 3:36 AM, Malcolm Wallace
(Declaration of interest: I wrote polyparse.)
Yes, I used polyparse in the VCD library. It rocks!
I'll check out the DrIFT tool.
Thanks.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
I have a lot of structured data in a program written in a different
language, which I would like to read in and analyze with Haskell. And
I'm free to format this data in any shape or form from the other
language.
Could I define a Haskell type for this data that derives the default
Read, then
tomahawkins:
I have a lot of structured data in a program written in a different
language, which I would like to read in and analyze with Haskell. And
I'm free to format this data in any shape or form from the other
language.
Could I define a Haskell type for this data that derives the
In fact, the time you'd spend writing read instances would not compare to the
half hour required to learn parsec.
And your parser will be efficient (at least, according to the guys from the
parser team ;-)
Cheers,
PE
El 08/05/2010, a las 23:32, Tom Hawkins escribió:
I have a lot of
On May 9, 2010, at 12:32 AM, Tom Hawkins wrote:
I have a lot of structured data in a program written in a different
language, which I would like to read in and analyze with Haskell. And
I'm free to format this data in any shape or form from the other
language.
Could I define a Haskell type for
13 matches
Mail list logo
