July 2004 - Libraries

RE: Combinators for ReadP
by Simon Peyton-Jones 26 Jul '04

26 Jul '04

Koen, not me! Simon | -----Original Message----- | From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Malcolm | Wallace | Sent: 26 July 2004 17:04 | To: libraries(a)haskell.org | Subject: Re: Combinators for ReadP | | Martin Sjögren <msjogren(a)gmail.com> writes: | | > > I think you'll find that without the local universal quantifier, | > > you cannot make ReadP a (useful) instance of Monad, because your | > > 'r' parameter would be fixed across >>=, whereas it really needs to | > > be variable. | > | > Uhh. But it works for ContT, so why not for ReadP? The only point time | > you have to fix the r is when you want to "run" the parser, all other | > parsers will be polymorphic in r: | | OK, cool. If you can successfully convert ReadP to Haskell'98, we'd | all be delighted. But Koen and Simon PJ are the people most likely | to be able to give relevant comment on whether any subtle properties | will be lost. | | Regards, | Malcolm | _______________________________________________ | Libraries mailing list | Libraries(a)haskell.org | http://www.haskell.org/mailman/listinfo/libraries

1 0

RE: Combinators for ReadP
by Simon Peyton-Jones 26 Jul '04

26 Jul '04

Martin Thanks. If you were to take the existing ReadP module, add your stuff, Haddockise it with explanatory text, then I'll put the result in place. ReadP would be much more useful if it had some introductory Haddock documentation too, including a reference to Koen Claessen's paper, if you felt up to doing that too. Many thanks for your help. Simon | -----Original Message----- | From: libraries-bounces(a)haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Martin | Sjögren | Sent: 22 July 2004 23:42 | To: libraries(a)haskell.org | Subject: Combinators for ReadP | | So I was wondering why there weren't any helpful combinators defined | in the ReadP module and found myself rewriting them over and over. I | put a bunch of combinators in the attached module (based on | corresponding combinators in Parsec.Combinator) and it would be neat | if they could be incorporated in the standard ReadP module in some | form. | | Cheers, | Martin

5 8

Haskell Graphics
by Alejandro Ramiro Ruiz 26 Jul '04

26 Jul '04

1 0

RE: Combinators for ReadP
by Graham Klyne 23 Jul '04

23 Jul '04

At 11:01 23/07/04 +0100, Simon Peyton-Jones wrote: >| Maybe I should write a test suite too, while I'm at it. Is there any >| specific location in the cvs tree where test suites should be put? > >Yes please! The right place is in > testsuite/tests/ghc-regress/lib/ >you can make a ReadP sub-directory. Er, doesn't that make it more difficult to create a library+test suite that can be shipped with other compilers? E.g., for my XML parser work, I created a separate test suite subdirectory in the source tree for that library. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

RE: Combinators for ReadP
by Simon Peyton-Jones 23 Jul '04

23 Jul '04

| Maybe I should write a test suite too, while I'm at it. Is there any | specific location in the cvs tree where test suites should be put? Yes please! The right place is in testsuite/tests/ghc-regress/lib/ you can make a ReadP sub-directory. I also think that a few paragraphs of Haddock introduction/examples would make the library much more usable, if you felt so inclined. Simon

1 0

Combinators for ReadP
by Martin Sjögren 22 Jul '04

22 Jul '04

So I was wondering why there weren't any helpful combinators defined in the ReadP module and found myself rewriting them over and over. I put a bunch of combinators in the attached module (based on corresponding combinators in Parsec.Combinator) and it would be neat if they could be incorporated in the standard ReadP module in some form. Cheers, Martin

1 0

RE: major missing piece to arrays?
by Simon Marlow 20 Jul '04

20 Jul '04

On 20 July 2004 02:23, John Meacham wrote: > Cool, I can build more efficient versions on these now that I know the > ByteArray# as Addr# trick. > > I am curious what the best way to go about writing specialized > versions is, > placing the copying functions in a class, with (slow) default methods > for everything and special instances for (IO)UArrays? or relying on > RULES pragmas to do the appropriate specialization? RULES is the way to go if you're just providing optimised versions. If you anticipate that there might be a semantic difference (I presume not), then a class is more appropriate. Cheers, Simon

1 0

major missing piece to arrays?
by John Meacham 19 Jul '04

19 Jul '04

Perhaps I am just missing something, but a major piece of efficient array functionality seems to be missing. Namely the ability to efficiently copy spans of arrays into one another and/or compare spans of memory. (basically memcpy and memcmp from C). any particular reason these basic building blocks were left out? I am trying to write an efficient packed string library and having to go through intermediate lists kills the garbage collector as well as the overall speed of my program. Ideally concatination should be a simple alloc + pair of memcpys. (yeah, I know they are both of linear order, but the constant factor on a system tuned assembler memcpy vs. chugging of the STG-machine is absurdly different when cache is taken into account) So, my question is also, as a workaround for the moment, how might I implement these rountines (without resorting to rewriting all the array functionality with Foreign)? Looking at the implementations of arrays, they all seem to be built on ByteArray#'s, if I could get a (Ptr a) out of them, that would be ideal, but I imagine that might be problematic without some mechanism to temporarily pin the address in place so the GC doesn't move it. I am thinking a family of routines. (with psuedosignatures) copySpan: range -> MArray -> whereto -> MArray -> m () extractSpan : range -> IArray -> IArray extractSpanM : range -> MArray -> m IArray saveSpan : range -> IArray -> whereto -> MArray -> m () hopefully the meaning of all is clear... perhaps better names can be come up with though. A similar set of routines which perform 'memcmp' would also be useful, but less vital at the moment. Sorry if I am just blind and missing these rountines... John -- John Meacham - ⑆repetae.net⑆john⑈

2 3

Haskell Extensions in various compilers (Cabal)
by Isaac Jones 19 Jul '04

19 Jul '04

I've implemented a mapping[1] between compiler extensions and command-line flags in Cabal[2] for GHC, NHC98, and Hugs. Can some representatives from each take a look at these and let me know if I'm wrong about how any of them work, whether I missed support for any of the compilers, or what-have-you? Some notes & questions: - I gathered these by the rather error-prone process of copying them from the end-user documentation. If anyone notices anything that's missing, or can suggest some way I could discover missing items, please do. - I'm not including any non-standard modules, since maybe those will be handled by the packaging system. - Are the "hood debugging extensions" in NHC and Hugs compatible? Should they be included? - Do any of Hugs, GHC, and NHC disallow Long.Hierarchical.Module.Names by default? Can they all turn them off? - Should there be a "Force98" option or something which does "-98" in NHC, "+98" in Hugs, and forces no other extensions in GHC? Presumably, it would disallow other extensions for the other compilers as well. - Does anyone care to provide such a mapping for any other compiler flavors? peace, isaac [2] formerly LIP: http://www.haskell.org/cabal ------------------------------------------------------------ [1] data Extension = OverlappingInstances | RecursiveDo | ParallelListComp | MultiParamTypeClasses | NoMonomorphismRestriction | FunctionalDependencies | RankTwoTypes | PolymorphicComponents | ExistentialQuantification | PatternTypeAnnotations | ImplicitParams | FlexibleContexts | FlexibleInstances | TypeSynonymInstances | TemplateHaskell | ForeignFunctionInterface | AllowOverlappingInstances | AllowUndecidableInstances | AllowIncoherentInstances | InlinePhase | ContextStack | Arrows | Generics | NoImplicitPrelude | ExtensibleRecords | RestrictedTypeSynonyms | HereDocuments | HoodDebugging | UnsafeOverlappingInstances deriving (Show, Read, Eq) -- |GHC: Return the unsupported extensions, and the flags for the supported extensions extensionsToGHCFlag :: [ Extension ] -> ([Extension], [Opt]) extensionsToGHCFlag l = splitEither $ nub $ map extensionToGHCFlag l where extensionToGHCFlag :: Extension -> Either Extension String extensionToGHCFlag OverlappingInstances = Right "-fallow-overlapping-instances" extensionToGHCFlag TypeSynonymInstances = Right "-fglasgow-exts" extensionToGHCFlag TemplateHaskell = Right "-fth" extensionToGHCFlag ForeignFunctionInterface = Right "-ffi" extensionToGHCFlag NoMonomorphismRestriction = Right "-fno-monomorphism-restriction" extensionToGHCFlag AllowOverlappingInstances = Right "-fallow-overlapping-instances" extensionToGHCFlag AllowUndecidableInstances = Right "-fallow-undecidable-instances" extensionToGHCFlag AllowIncoherentInstances = Right "-fallow- incoherent-instances" extensionToGHCFlag InlinePhase = Right "-finline-phase" extensionToGHCFlag ContextStack = Right "-fcontext-stack" extensionToGHCFlag Arrows = Right "-farrows" extensionToGHCFlag Generics = Right "-fgenerics" extensionToGHCFlag NoImplicitPrelude = Right "-fno-implicit-prelude" extensionToGHCFlag ImplicitParams = Right "-fimplicit-params" extensionToGHCFlag RecursiveDo = Right "-fglasgow-exts" extensionToGHCFlag ParallelListComp = Right "-fglasgow-exts" extensionToGHCFlag MultiParamTypeClasses = Right "-fglasgow-exts" extensionToGHCFlag FunctionalDependencies = Right "-fglasgow-exts" extensionToGHCFlag RankTwoTypes = Right "-fglasgow-exts" extensionToGHCFlag PolymorphicComponents = Right "-fglasgow-exts" extensionToGHCFlag ExistentialQuantification = Right "-fglasgow-exts" extensionToGHCFlag PatternTypeAnnotations = Right "-fglasgow-exts" extensionToGHCFlag FlexibleContexts = Right "-fglasgow-exts" extensionToGHCFlag FlexibleInstances = Right "-fglasgow-exts" extensionToGHCFlag e@ExtensibleRecords = Left e extensionToGHCFlag e@RestrictedTypeSynonyms = Left e extensionToGHCFlag e@HereDocuments = Left e extensionToGHCFlag e@HoodDebugging = Left e extensionToGHCFlag e@UnsafeOverlappingInstances = Left e -- |NHC: Return the unsupported extensions, and the flags for the supported extensions extensionsToNHCFlag :: [ Extension ] -> ([Extension], [Opt]) extensionsToNHCFlag l = splitEither $ nub $ map extensionToNHCFlag l where extensionToNHCFlag NoMonomorphismRestriction = Right "" -- not implemented in NHC extensionToNHCFlag ForeignFunctionInterface = Right "" extensionToNHCFlag HoodDebugging = Right "" extensionToNHCFlag e = Left e -- |Hugs: Return the unsupported extensions, and the flags for the supported extensions extensionsToHugsFlag :: [ Extension ] -> ([Extension], [Opt]) extensionsToHugsFlag l = splitEither $ nub $ map extensionToHugsFlag l where extensionToHugsFlag OverlappingInstances = Right "+o" extensionToHugsFlag UnsafeOverlappingInstances = Right "+O" extensionToHugsFlag HereDocuments = Right "+H" extensionToHugsFlag RecursiveDo = Right "-98" extensionToHugsFlag ParallelListComp = Right "-98" extensionToHugsFlag MultiParamTypeClasses = Right "-98" extensionToHugsFlag FunctionalDependencies = Right "-98" extensionToHugsFlag RankTwoTypes = Right "-98" extensionToHugsFlag PolymorphicComponents = Right "-98" extensionToHugsFlag ExistentialQuantification = Right "-98" extensionToHugsFlag PatternTypeAnnotations = Right "-98" extensionToHugsFlag ImplicitParams = Right "-98" extensionToHugsFlag ExtensibleRecords = Right "-98" extensionToHugsFlag RestrictedTypeSynonyms = Right "-98" extensionToHugsFlag HoodDebugging = Right "-98" extensionToHugsFlag FlexibleContexts = Right "-98" extensionToHugsFlag FlexibleInstances = Right "-98" extensionToHugsFlag e = Left e splitEither :: [Either a b] -> ([a], [b]) splitEither l = ([a | Left a <- l], [b | Right b <- l]) type Opt = String

2 1

XML and RDF parsers
by Graham Klyne 14 Jul '04

14 Jul '04

Further to my work on HaXml announced last month [1][2][3][4], I've added two new filters to perform xml:base and xml:lang processing, and fixed up some minor problems. The code is available at [5], with browseable directories at [6]. I've also developed an RDF/XML parser as part of my Swish project [11] (the RDF/XML parser can be used separately from all the other Swish components); the code is at [7], with browseable online directories at [8]. All this has a dependency on some revised network modules [9][10]. ... As part of developing the RDF/XML parser, I believe I have identified a fairly significant problem with HaXml's handling of whitespace. The core fix is, I believe, quite easy, but there are knock-on changes required to the validation module and 20-30 of the test suite test cases. The code changes could cause some existing HaXml applications to break because they would result in additional content items in the resulting XML data containing just whitespace text -- e.g. whitespace appearing between elements would be returned to the application. #g -- [1] http://www.haskell.org//pipermail/libraries/2004-June/002243.html [2] http://www.haskell.org//pipermail/libraries/2004-June/002266.html [3] http://www.haskell.org//pipermail/libraries/2004-June/002276.html [4] http://www.haskell.org//pipermail/libraries/2004-June/002282.html [5] http://www.ninebynine.org/Software/HaskellUtils/20040713-Haxml-1.12.zip [6] http://www.ninebynine.org/Software/HaskellUtils/HaXml-1.12/ [7] http://www.ninebynine.org/Software/HaskellRDF/20040713-HaskellRDF.zip http://www.ninebynine.org/Software/HaskellUtils/20040713-HaskellUtils.zip [8] http://www.ninebynine.org/Software/HaskellRDF/ http://www.ninebynine.org/Software/HaskellUtils/ [9] http://www.ninebynine.org/Software/HaskellUtils/20040609-Network.zip [10] http://www.ninebynine.org/Software/HaskellUtils/Network/ [11] http://www.ninebynine.org/RDFNotes/Swish/Intro.html ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0