- Libraries - Haskell.org

Re: Libraries Digest, Vol 60, Issue 4
by John Lato 04 Aug '08

04 Aug '08

On Mon, Aug 4, 2008 at 5:26 AM, Duncan Coutts wrote: > > Oh, great. I didn't know OS X had a standard location for per-user > installs. That's excellent. So is there a preferred layout for those > dirs? I'm guessing there probably is. > >> * ~/.cabal is bad on Mac OS, too. Preferences ought to go into ~/ >> Library/Preferences/ ~/Library/Preferences should only be used if the .plist format is supported. In general, I agree with Brendan that unixy programs don't belong here, and I'm happy with .cabal. However, if you want to use the OSX dirs, I would think that most of the items in .cabal could be placed in ~/Library/Application Support/Cabal/. Unlike most other standard directories, this appears to be completely application-dependent. > > Ok. BTW, in that case we should probably fix > System.Directory.getAppUserDataDirectory to follow the system convention > on OSX. Currently it uses $HOME/.appname on all unix systems (and the > Windows convention on Windows). If necessary we may want to > split getAppUserDataDirectory into a variant for config and another for > data. > > Since cabal-install is a program should it still be > using ~/Library/Preferences/ or is there are > corresponding ~/Applications/Preferences/ ? Where would be > appropriate for cabal-install put its download cache and build logs? > All preferences are in ~/Library/Preferences/, in Apple's .plist format. There is no ~/Applications/Preferences/. Build logs should go in ~/Library/Logs/, either in a subdirectory or directly in this folder. There is a ~/Library/Caches/, but I believe that's reserved for the NSURL cache (accessed through Cocoa). > > It's less clear what we'd do on windows if we want versioned binaries > since there are no links. > I have personally ended up just copying the latest version of "appname-n.n.n" to "appname". Granted I've only done that on my own computer, never as part of an install process. John Lato

1 0

for old-time sakes:-) shouldn't deprecated libraries have DEPRECATED pragma?
by Claus Reinke 04 Aug '08

04 Aug '08

The haddocks for System.Time (suggestively located in old-time) state: This library is deprecated, please look at Data.Time in the time package instead. Yet, there is no DEPRECATED pragma for the module, so I actually missed all those other hints, and the improved Data.Time functionality, for a while at least. Claus

1 0

Unordered map
by Andrew Wagner 01 Aug '08

01 Aug '08

All, Forgive me if this has been brought up before, but I was just thinking about the fact that there's no Map structure in the standard library that doesn't pretty much require an Ord instance for its keys. I say "pretty much" because, while you can declare a Map with keys of a type that's not an Ord instance, you can't do hardly anything with it. E.g., you can't do an insert. Makes it kind of pointless. Now, I understand the fact that this is for efficiency purposes, but it does seem a bit inconsistent. Why allow the construction of a Map you can't do anything with? Here are two possible more consistent ways of handling this: Suppose I have some data structure that is inherently unordered, and I want to use it as a key into a Map. How would I get around this limitation on the client side? Well, the most obvious way is to create some nonsensical Ord instance, like compare _ _ = Eq. Is that the recommended solution? If so, we could create unordered versions of all the ordered methods that assume this 'ordering'. If not, what is the recommended way, and why not create unordered versions that use that? The other way to make the library more consistent, perhaps, would be to simply move the Ord requirement up to that data structure: that is, make it Ord k => Map k a, and then have a new data structure like UnorderedMap (or, to use a more standard term, Dictionary). Thoughts? Am I completely missing something?

8 12

proposal #2461: add Traversable generalizations of mapAccumL and mapAccumR
by Ross Paterson 01 Aug '08

01 Aug '08

The proposal is to add the following functions to Data.Traversable, generalizing the list versions in Data.List: -- |The 'mapAccumL' function behaves like a combination of 'fmap' -- and 'foldl'; it applies a function to each element of a structure, -- passing an accumulating parameter from left to right, and returning -- a final value of this accumulator together with the new structure. mapAccumL :: Traversable t => (a -> b -> (a, c)) -> a -> t b -> (a, t c) -- |The 'mapAccumR' function behaves like a combination of 'fmap' -- and 'foldr'; it applies a function to each element of a structure, -- passing an accumulating parameter from right to left, and returning -- a final value of this accumulator together with the new structure. mapAccumR :: Traversable t => (a -> b -> (a, c)) -> a -> t b -> (a, t c) These functions are handy for things like labelling trees, zipping, etc. Deadline: 3 weeks

7 12

Re: [Hs-Generics] Re: Owning SYB
by José Pedro Magalhães 01 Aug '08

01 Aug '08

Hello all, As Johan mentioned, here in Utrecht we are working on libraries for generic programming. We want to make it easier for people to use generic libraries, so we are packaging EMGM [1] and a library for generic programming for mutually recursive datatypes [2]. We intend to release these on Hackage soon (Summer vacations are delaying us a bit), along with useful generic applications (a zipper and a generic rewriting framework). Maintaining SYB fits well in this idea, and if no other natural maintainers volunteer, I (with some support from the other people at Utrecht) am happy to take it upon me. I probably won't do heavy development on the library, but including patches, and providing support is fine. We're also planning to maintain EMGM here in Utrecht, although we didn't develop that ourselves. Recently, (at least) Claus and Oleg have been posting interesting suggestions of improvements/modifications to SYB. Those should be further analyzed and discussed, and finally introduced (or not) in the library. The generic map for SYB, for instance, evolved from the "impossible to implement", through the "unsafe implementation", until the latest gmap2 as described by Oleg [3]. If further tests show this function behaves as expected, then it's clearly a good candidate for extending SYB. We should also rethink if other things previously deemed impossible remain so. Maintaining SYB, alongside with the other generic libraries, will require things such as: * Releasing packages in Hackage, properly documented with Haddock; * Updating such packages as necessary for new releases of GHC; * Writing examples of how to use the libraries (from a user perspective); * Writing testsuites, which are important for checking backwards compatibility of any changes; * Having an updated webpage linking to the library sources, documentation, possibly a bug tracker, etc. These are all things we plan to do for the libraries. Additionally, we could think of improving syb-with-class [4] in parallel with regular SYB. This is something to ask to its maintainer. Cheers, Pedro [1] http://books.google.com/books?id=OyY3ioMJRAsC&pg=PA199&sig=ACfU3U1nczeRAIjN… [2] http://www.cs.uu.nl/research/techreps/UU-CS-2008-019.html [3] http://www.haskell.org/pipermail/generics/2008-July/000362.html [4] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/syb-with-class

2 2

darcs patch: Fix Unicode bug in haskell-src
by Andrea Vezzosi 31 Jul '08

31 Jul '08

Language.Haskell.Parser currently can't parse modules with unicode symbols in operators, which are allowed by the haskell98 standard. The attached patch is a small change in the lexer code to fix this. Since parseModule expects a String of Unicode codepoints as usual, examples/hsparser.hs will still raise errors on modules that use unicode, because it doesn't decode the source. The correct behaviour, assuming an utf-8 source, can be tested like this: > import System.IO.UTF8 as U -- from utf8-string > import Language.Haskell.Parser > import Language.Haskell.Pretty > main = do file <- U.readFile "module.hs" > case parseModule of > ParseOk m -> U.putStrLn (prettyPrint m) > e@(ParseError _ _) = print e

3 2

Owning SYB
by Simon Peyton-Jones 30 Jul '08

30 Jul '08

Dear Generic folk [I'm spamming libraries(a)haskell.org too, in case anyone interested in generics is not on generics(a)haskell.org.] As you know, Claus has offered a somewhat-detailed proposal for changes to the SYB library (below). But I don't think that we have an active maintainer for any of the generic-programming libraries (esp SYB) apart from Uniplate. Then there's the related question of what generic-programming technology to promote for clients of the GHC API. The obvious candidates are Claus himself, or Alexey Rodriguez, or Thomas Schilling; but perhaps there are others too? Maybe no one has stepped forward because you all think that I'm on the job! But I'm not... I'm busy with GHC itself, and would love a maintainer for SYB and associated gubbins. I fear that otherwise we may lose the benefits of Claus's homework. Simon | -----Original Message----- | From: generics-bounces(a)haskell.org [mailto:generics-bounces@haskell.org] On Behalf Of Claus Reinke | Sent: 21 July 2008 14:16 | To: generics(a)haskell.org | Subject: [Hs-Generics] Data.Generics with GPS (using Maps to avoid getting lost in Data) | | | summary: speed up Syb with Uniplate-inspired techniques | | == Performance issues in Syb == | | As it stands, classic Syb, while well-supported in GHC isn't exactly the | fastest generic programming option. In fact, it routinely seems to come | out last in performance comparisons, sometimes by a substantial factor. | | That isn't always a problem in practice, because the gains in | expressiveness/conciseness/maintainability outweigh the loss in | performance, because traversal performance is not the bottleneck, or | because practical use often involves hand-tuned traversal schemes | instead of the example schemes typically used in benchmarks. | | Be that as it may, performance is a consideration, negative results have | been published, and it seems that performance of experimental code has | led to Syb being abandoned in at least one project. While it would be | unrealistic to expect Syb traversals to compete with hand-written ones | with current compilers, there are several obvious areas where Syb | traversal performance could be subjected to improvements: | | (a) traversing irrelevant parts of the structure (because everything is | treated generically) | (b) combining results in simple, but inefficient ways ((++) nesting with | the structure) | (c) repeated runtime type checks to determine which function in a | generically extended transformation/query to apply | | While runtime type checks are inherent in SYB (and alternatives have | been proposed that claim to avoid them), all of a/b/c can be addressed | to some extent in defining tuned traversals using the basic library. | There tends to be a trade-off for a vs c, as avoiding senseless generic | traversals of specific substructures implies additional runtime type | checks to identify those substructures [...rest snipped...]

3 3

Re: compositional gMap in SYB1
by Claus Reinke 29 Jul '08

29 Jul '08

> Hello! Hello again!-) > Claus wrote: >> Perhaps we can combine our versions to get the best of both? > > I have done so. I have committed a new version of > /comparison/SYB1_2/GMap.lhs [for readers of libraries@: that is in the generics code repo at http://darcs.haskell.org/generics/comparison/SYB1_2/GMap.lhs , look for gmap2/gmapt and comments; the topic is defining Functor fmap generically (hence gmap) in terms of Data/Typeable] Ah, of course! Silly me, if I had followed my own choice of metaphor to the end, I would have known that X marks the spot only on a map, not on the real thing (or else everyone could find the treasure..). Your shallow, incrementally built not-quite copy is just another representation of a map, and since both map and X are hidden from users of the function, everyone is happy. That something out of nothing trick is also used in the PlateData optimization and in my adaptation of it. The difference, apart from choice of representation, is mainly in whether to extract substructure placeholders/types on a type basis once per traversal or on a value basis, incrementally. Here is a re-run of the technique, for defining traverse in terms of Data/Typeable. Apart from being useful for Data.Traversable library users, the type of 'traverse id' is similar to the type of transpose, which should interest the generics readers. {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE RankNTypes #-} import Control.Applicative import Data.Generics data X = X deriving (Data,Typeable) traverseData :: forall f a b t . (Applicative f,Typeable1 f,Typeable a,Typeable b, Data (t a),Data (t b),Data (t X)) => (a -> f b) -> t a -> f (t b) traverseData f = traverseWithMap f (Dyn (undefined::t X)) where traverseWithMap :: forall f a b x y . (Applicative f,Typeable1 f,Typeable a,Typeable b,Data x,Data y) => (a -> f b) -> Dyn -> x -> f (y) traverseWithMap f (Dyn t) x | typeOf t==typeOf X = maybe (error "traverseData: non-applicable type marked") ($x) (cast f) | otherwise = rebuildWith (traverseWithMap f) t1 x where t1 = Dyn (fromConstr (toConstr x) `asTypeOf` t) rebuildWith :: forall f x y . (Applicative f,Data x,Data y) => (forall x y . (Data x,Data y) => Dyn -> x -> f y) -> Dyn -> x -> f y rebuildWith f (Dyn t) x = case gunfold (k f) (\g -> UnfldStateF2 (pure g) tkids kids) con of UnfldStateF2 a [] [] -> a where (tcon,tkids) = dynamize t (con,kids) = dynamize x k :: forall a b . (Data a) => (forall x y . (Data x,Data y) => Dyn -> x -> f y) -> UnfldStateF2 f (a->b) -> UnfldStateF2 f b k f (UnfldStateF2 ca (tkid:tkids) ((Dyn kid):kids)) = UnfldStateF2 (ca <*> (f tkid kid)) tkids kids data UnfldStateF2 f a = UnfldStateF2 (f a) [Dyn] [Dyn] data Dyn = forall a. Data a => Dyn a data Kids a = Kids{growUp:: [Dyn]} dynamize :: Data a => a -> (Constr,[Dyn]) dynamize x = (toConstr x, growUp $ gfoldl f (const (Kids [])) x) where f (Kids l) a = Kids (l ++ [Dyn a]) test = do print $ traverseData (Just . not) tuple print $ traverseData (Just . not) list traverseData print tuple >>= print traverseData print list >>= print where tuple = (True,True) list = [True,True] Btw, while the type of 'traverseData id' matches that of transpose, its behavious doesn't quite, depending on example: *Main> :t traverseData id traverseData id :: (Data (t X), Data (t b), Data (t (f b)), Typeable b, Typeable1 f, Applicative f) => t (f b) -> f (t b) *Main> traverseData id [Just x|x<-[1..3]] Just [1,2,3] *Main> traverseData id [[1..3],[4..6]] [[1,4],[1,5],[1,6],[2,4],[2,5],[2,6],[3,4],[3,5],[3,6]] > optimization: if it is determined that a structured value has no > components to map, no traversal is performed and the value is returned > as it is. That should speed things up a little. The trick is producing > something out of nothing. That optimization is another indication of the relation to the substructure types map building, although pleasingly different in form (always nice to learn new tricks;-). > Too bad that the deadline to amend a Haskell workshop paper > has passed, and so has the deadline for the generics workshop. Perhaps > we should write a separate paper? Sounds like a good idea. When you're back. > I'm afraid I would be out of town again for two weeks and so > would not be able to follow the discussion closely. Ah, you're just trying to hide the two-week round trips for lightspeed messages resulting from your space travels!-) Thanks for yet another useful contribution, Claus

1 0

Text.JSON Questions
by R Hayes 29 Jul '08

29 Jul '08

I'm using Haskell to build a web services client. The API uses JSON, so I've been playing around with Text.JSON. Text.JSON works, but it seems kind of clumsy to me. I suspect that it's my failure to understand the proper usage pattern, rather than an issue with the design. For much of what I'm doing, I don't know *exactly* what I'm going to get back. I know that there will be specific JSON fields I'm interested in, but there may be ones I'm not expecting. Writing a readJSON for a pre-designed data structure is not the right answer. I'm not marshalling and un-marshalling structures that originate in Haskell. The structures I am un-marshalling are subject to extension. it seems like the default invocation of decode is something like: (decode aString) :: Result JSValue Is that correct? I'm unclear on the design goals of parameterizing JSObject. Why isn't JSObject just a list of (String,JSValue) tuples? What do we get from parameterizing it? What's the intent of having JSObject as a data constructor for JSValue and as a distinct type constructor (whose hidden data constructor is JSONObject)? What do we get from this? Why hide JSONObject? The way things are constructed, we always end up with two layers of data constructors for JSON objects JSObject (JSONObject ...). What do we get from this additional complexity. -r hayes

4 3

Data.Time.Clock.DiffTime documentation error
by Alexander Dunlap 29 Jul '08

29 Jul '08

Hi all, The documentation for Data.Time.Clock.DiffTime says that DiffTime has an *accuracy* of 10^-12 seconds. Since (I assume) the datatype can't ensure the accuracy of external timekeeping mechanisms, shouldn't this say *precision* of 10^-12 seconds? The same is true for NominalDiffTime. I don't know if a change this simple needs to go though the Library Submissions Process, but it certainly could. Alex

2 1