Announce+Question: jDrIFT
I often finding myself going back to good old trusty DrIFT, and have over the past few months made a number of changes to it, many of which i think people would appreciate. I was wondering what i should do to get my changes folded into the main drift, or even if there is a main drift any more? new working features I implemented include: * proper GetOpt command line handling, allows you to specify an output file (-o) as well as list all possible derivations this version can use (-l) and some others. * proper LINE pragmas in generated code * smarter error handling in some cases, parser smarter sometimes. * can deal with/ignore as appropriate some ghc extensions now * new rule to derive Typeable used by the Dynamic library. * new rule to derive Observable from the HOOD object debugger * rules to derive Term, a term representation for generic computation, can be used in a similar fashion to the Strafunski one, but has a number of advantages, fully lazy constant time implode/explode being the main one. (the external library is compatable with their work.) and some other patches that i collected from around the net jDrIFT -l lists the following: Binary, Typeable, Term, OldTerm, Implode, Explode, Observable, test, update, is, has, un, NFData, Eq, Ord, Enum, Show, Read, Bounded, Haskell2Xml features in the works: * smarter rule format, allow descriptions (help info) to be embedded, and options to be passed into the rule generators either from the command line or in the DrIFT pragmas themselves. among other things, the code generation should be able to find out what extensions you wish to let them use and let them fail gracefully if one doesnt exist that is needed. * MultiParameter typeclasses * smarter/rethought import chasing rules. * LibDrIFT, simply write your single rule, import libdrift and it will build to a DrIFT module. these modules can be used standalone executables and behave just like the original drift (with your extension), but if placed in a searchable spot, the main jDrIFT implementation will pick them up and integrate their rules into its capabilities. In Any case i made a prerelease of my modified version available at: http://homer.netmar.com/~john/computer/haskell/jDrIFT/ but would like to somehow merge with the main development tree of this tool, if one exists, if it doesnt look like that will happen then perhaps i will have to branch to a new maintained DrIFT inspired project. -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john@foo.net ---------------------------------------------------------------------------
John Meacham <john@foo.net> writes:
In Any case i made a prerelease of my modified version available at: http://homer.netmar.com/~john/computer/haskell/jDrIFT/ but would like to somehow merge with the main development tree of this tool, if one exists, if it doesnt look like that will happen then perhaps i will have to branch to a new maintained DrIFT inspired project.
Noel Winstanley (Glasgow) was the original author of DrIFT, but as far as I know, he no longer maintains it. He authorised me to host DrIFT at York (http://www.cs.york.ac.uk/fp/DrIFT) after it was updated to Haskell'98, and I also distribute it as part of the HaXml package, where it has received occasional bugfixes. In addition, there is an older and unmaintained version in the ghc CVS tree (under hslibs/tools). If you wish to `adopt' DrIFT and become its maintainer, that's great (but check with Noel first). I'd be happy to make HaXml dependent on your version of DrIFT rather than distributing DrIFT as part of HaXml. It would be ideal if you could make DrIFT available by CVS as well as in a stable pre-packaged form. I'm sure www.haskell.org would offer web space and cvs.haskell.org would offer CVS space to host this project. Regards, Malcolm
Hello, I am running into trouble with the HaXml parser because it is not lazy. Hence I am considering to abondon the use of XML as data-exchange format. Anyway, XML documents are too verbose. Now I wonder whether Happy-generated parsers are lazy? Michael
I do not believe they are, as they are optimized for performance, even if they were lazy, the check for the error condition right after the parse would immediatly evaluate the whole parse tree to check for errors, probably the best route is to use/roll your own parser combinator library. they are pretty easy if you are comfortable with monads, and can be made lazy. xml might be simple enough to just write a parser by hand too. if you want an efficient data-exchange format and you can wait a bit i am going to make a release of my XDR library soon, useful for both exchanging data in a machine/time independant format or communicating with known network protocols such as nfs. John On Wed, May 08, 2002 at 10:41:19AM +0200, Michael Marte wrote:
Hello,
I am running into trouble with the HaXml parser because it is not lazy. Hence I am considering to abondon the use of XML as data-exchange format. Anyway, XML documents are too verbose.
Now I wonder whether Happy-generated parsers are lazy?
Michael
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
-- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john@foo.net ---------------------------------------------------------------------------
participants (4)
-
Arjan van IJzendoorn -
John Meacham -
Malcolm Wallace -
Michael Marte