Re: [Haskell-cafe] How efficient is read?
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 right now, but will try to take a look shortly. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How efficient is read?
On Tue, May 11, 2010 at 12:16 AM, Tom Hawkins 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 think there is something wrong with the generated parser. It > doesn't look for (..) groupings. For example: > > 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). > > Am I missing something? I don't know. If you could check whether the original Drift has that error as well, then I suspect Drift's author, Meachem, would be interested to know. (I only maintain drift-cabalized as a packaging fork; I tried not to change any actual functionality.) -- gwern ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How efficient is read?
> > 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 (..) groupings. For example: 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). Am I missing something? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How efficient is read?
On Mon, May 10, 2010 at 4:50 PM, Tom Hawkins 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 parser yourself! > > Cabal install DrIFT-cabalized complains. What is the module "Rules"? > I've never seen it before. > > Is there a quick fix? I didn't see a "build-depends" line in my > ~/.cabal/config file. > > > > e0082...@e0082888-laptop:~$ cabal install DrIFT-cabalized > Resolving dependencies... > Configuring DrIFT-cabalized-2.2.3.1... > Preprocessing executables for DrIFT-cabalized-2.2.3.1... > Building DrIFT-cabalized-2.2.3.1... > > src/DrIFT.hs:19:17: > Could not find module `Rules': > It is a member of the hidden package `ghc-6.12.2'. > Perhaps you need to add `ghc' to the build-depends in your .cabal file. > Use -v to see a list of the files searched for. > cabal: Error: some packages failed to install: > DrIFT-cabalized-2.2.3.1 failed during the building phase. The exception was: > ExitFailure 1 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. -- gwern ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How efficient is read?
> 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 module "Rules"? I've never seen it before. Is there a quick fix? I didn't see a "build-depends" line in my ~/.cabal/config file. e0082...@e0082888-laptop:~$ cabal install DrIFT-cabalized Resolving dependencies... Configuring DrIFT-cabalized-2.2.3.1... Preprocessing executables for DrIFT-cabalized-2.2.3.1... Building DrIFT-cabalized-2.2.3.1... src/DrIFT.hs:19:17: Could not find module `Rules': It is a member of the hidden package `ghc-6.12.2'. Perhaps you need to add `ghc' to the build-depends in your .cabal file. Use -v to see a list of the files searched for. cabal: Error: some packages failed to install: DrIFT-cabalized-2.2.3.1 failed during the building phase. The exception was: ExitFailure 1 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How efficient is read?
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 the Haskell Do You Read Me paper, see section 5 for a comparison of efficiency). -chris On 9 mei 2010, at 05:32, 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 this data that derives the default > Read, then simply print out Haskell code from the program and 'read' > it in? Would this be horribly inefficient? It would save me some > time of writing a parser. > > -Tom > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How efficient is read?
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 http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How efficient is read?
Malcolm Wallace 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 ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How efficient is read?
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 that it gives you no useful error message if the parse fails. Parser combinators are really rather easy to learn and use, and tend to give decent error reports when something goes wrong. 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! I would caution against using Parsec if your dataset is large. Parsec does not return anything until it has seen the entire input, so can use a huge amount of memory. The other day someone was observing on haskell-cafe that parsing a 9Mb XML file using a Parsec-based parser required >7Gb of memory, compared with 1.3Gb for a strict polyparse- based parser (still too much), and the happy conclusion was that the lazy polyparse variant uses a neglible amount by comparison. (Declaration of interest: I wrote polyparse.) Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How efficient is read?
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 this data that derives the default Read, then simply print out Haskell code from the program and 'read' it in? Would this be horribly inefficient? It would save me some time of writing a parser. -Tom If your types contain infix constructors, the derived Read instances may be almost unusable; see http://hackage.haskell.org/trac/ghc/ticket/1544 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How efficient is read?
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 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 simply print out Haskell code from the program and 'read' > it in? Would this be horribly inefficient? It would save me some > time of writing a parser. > > -Tom > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How efficient is read?
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 default > Read, then simply print out Haskell code from the program and 'read' > it in? Would this be horribly inefficient? It would save me some > time of writing a parser. It would be easy but inefficient for more than say, 100k of data. deriving Binary will be faster and almost as easy (the derive script is in the binary/scripts dir). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] How efficient is read?
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 simply print out Haskell code from the program and 'read' it in? Would this be horribly inefficient? It would save me some time of writing a parser. -Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe