- Haskell-Cafe - Haskell.org

Is it possible to get the information of instances of a type?
by Magicloud Magiclouds 07 Nov '11

07 Nov '11

Hi, If this was in ruby or other languages that support reflection, it won't be a question. But in Haskell, could I write a code to list the classes that a type instanced? TemplateHaskell as well. -- 竹密岂妨流水过山高哪阻野云飞

7 9

memorize function with number parameterized types in GHC
by Bin Jin 07 Nov '11

07 Nov '11

Hi, everyone I'm recently trying to implement the Montgomery reduction algorithm[1] in Haskell, the code can be found on my Github page[2]. After doing some benchmark testing I found that the library works rather slow. With the help of `trace` function from Debug.Trace, I found that GHC is not magical enough to memorize values with the same type(well, it's actually dynamically generated number parameterized type). I used binary representation to handle all positive numbers in type system. > data One = One > data D0 a = D0 a > data D1 a = D1 a > class PostiveN a where > p2num :: (Num b, Bits b) => a -> b > instance PostiveN One ... > instance PostiveN a => PostiveN (D0 a) ... > instance PostiveN a => PostiveN (D1 a) ... Here is a function that will be called everytime by `(*)` in `Num` typeclass > montgKeys :: (PostiveN p, Integral a, Bits a) => p -> a as you can imagine, I always pass (undefined :: p) as parameter to `montgKeys`, so if it's handled well, it should be memorized for future usage. But tracing shows that both `p2num` and `montgKeys` are evaluated every time being called. So my question is, how to force GHC memorizing this kind of functions? [1]: http://en.wikipedia.org/wiki/Montgomery_reduction [2]: https://github.com/bjin/montg-reduce Regards, Bin

6 14

Re: [Haskell-cafe] memorize function with number parameterized types in GHC
by DavidA 06 Nov '11

06 Nov '11

Bin Jin <bjin1990 <at> gmail.com> writes: > > > In order to represent Z/nZ, regular way need to store two integers, > and a data constructer. With number parameterized types, newtype+Integer > can be used, it's much more efficient. For this project, montg reduce > require to calculate a key for each modulus, but the modulus won't be > changed within Num typeclass. It's better to fix it in type system. > On Nov 7, 2011 1:38 AM, "DavidA" <polyomino <at> f2s.com> wrote: > What's the purpose of all the type trickery? > Why not just implement the algorithm using Integer? > _______________________________________________ > Haskell-Cafe mailing listHaskell-Cafe <at> haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe <at> haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > Ok, but even if you want to represent the inputs and outputs to be in Z/nZ, that doesn't mean that you have to work in Z/nZ while performing the algorithm. I think it would probably be faster to convert from Z/nZ to Integer, do the algorithm, and then convert the result back to Z/nZ. Anyway, good luck, and if you succeed in getting it fast enough, I hope you'll make the results available somewhere.

1 0

Cabal install problem
by Victor Miller 06 Nov '11

06 Nov '11

Lately whenever I try to install a cabal package it fails with the following error message: Could not find module `Control.Monad.State': Perhaps you haven't installed the profiling libraries for package `mtl-2.0.1.0'? Use -v to see a list of the files searched for. The strange thing is that I can load Control.Monad.State from ghci. How do I fix this -- i.e. where should I look?

4 3

[ANNOUNCE] cereal-0.3.4.0
by Trevor Elliott 06 Nov '11

06 Nov '11

Hi Everyone, I'm happy to announce version 0.3.4.0 of the cereal serialization library. This release includes a patch from Adam Foltzer to provide support for IEEE754 encoded Float/Double values. This functionality is exposed through Serialize instances for both types, and specialized get/put functions in the new Data.Serialize.IEEE754 module. Happy hacking! --trevor

3 2

How do you describe systems in general with Haskell?
by Grigory Sarnitskiy 06 Nov '11

06 Nov '11

If you are to describe a system, which consists of several subsystems, how do you approach the problem? What types, classes, functions whatever do you introduce? I guess it is a common problem, is there a general method? Just to describe, not to solve (though if the description implies the solution then it is wonderful). Obviously this is not just a haskell-specific problem, but I think there might be people who are aware of the best current solution (category theory?). For a dummy example, how would you describe the system from a fox, goose and bag of beans puzzle (wolf, goat and cabbage)?

5 4

New CoreErlang maintainer + patch
by Alex Kropivny 05 Nov '11

05 Nov '11

Hello, I've got a patch [1] for the CoreErlang package. It fixes a parsing bug and adds Typeable+Data instances to the syntax tree. I was unable to contact the developers/maintainers via provided email. (No response in ~3 weeks.) The package hasn't been touched for three years, since first uploaded. I would like to take over maintenance of the package, and upload the fix ASAP. Regards, Alex Kropivny [1] https://github.com/amtal/CoreErlang/tree/0.0.2

1 0

Is generic information dumpable?
by Magicloud Magiclouds 04 Nov '11

04 Nov '11

Hi, I am learning the new generic feature of ghc. I'd have to say, it is harder than template to enter. When I started to learn template, ghc -ddump-slices really helped. So I wonder if I could get the representation generated when deriving Generic. I think that would be a great help. -- 竹密岂妨流水过山高哪阻野云飞

3 7

ANN: websockets 0.4.0.0
by Jasper Van der Jeugt 04 Nov '11

04 Nov '11

Hello all, I'm pleased to announce the release of websockets [1] 0.4.0.0 today. You can grab it on Hackage [2]. This update brings an (almost completely rewritten) library which has support for multiple versions of the protocol, meaning you can choose to write backwards-compatible applications, or use the latest and greatest, all using a common API. All feedback is obviously welcome, I'd be glad to hear what you guys think. For the next version, client-side support is planned, so the library user can write clients in addition to servers. If there's any other feature you would like to see, feel free to let me know. [1]: http://jaspervdj.be/websockets/ [2]: http://hackage.haskell.org/package/websockets Cheers, Jasper

1 0

Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 99, Issue 9
by yrazes 04 Nov '11

04 Nov '11

Hi This is a very simple basic case, but I have a little trouble with this... I hope somebody can help me main :: IO() main = return :: f tipos :: Int -> Int -> Int -> Float tipos a b c f = b / a * c where (a,b,c) = (8,3,15) Julita On Thu, Nov 3, 2011 at 11:10 PM, <haskell-cafe-request(a)haskell.org> wrote: > Send Haskell-Cafe mailing list submissions to > haskell-cafe(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.haskell.org/mailman/listinfo/haskell-cafe > or, via email, send a message with subject or body 'help' to > haskell-cafe-request(a)haskell.org > > You can reach the person managing the list at > haskell-cafe-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Haskell-Cafe digest..." > > > Today's Topics: > > 1. Re: How to speedup generically parsing sum types? > (Jos? Pedro Magalh?es) > 2. Re: How to speedup generically parsing sum types? (Bas van Dijk) > 3. Re: The type class wilderness + Separating instances and > implementations into separate packages (Ryan Newton) > 4. Re: How to speedup generically parsing sum types? (Bas van Dijk) > 5. Re: The type class wilderness + Separating instances and > implementations into separate packages (Bas van Dijk) > 6. Re: How to speedup generically parsing sum types? (Claus Reinke) > 7. Re: How to speedup generically parsing sum types? (Bas van Dijk) > 8. [ANNOUNCE] cereal-0.3.4.0 (Trevor Elliott) > 9. System calls and Haskell threads (Andreas Voellmy) > 10. Re: System calls and Haskell threads (Johan Tibell) > 11. Is generic information dumpable? (Magicloud Magiclouds) > 12. Re: Is generic information dumpable? (Jos? Pedro Magalh?es) > 13. Re: How to speedup generically parsing sum types? > (Twan van Laarhoven) > 14. compiler construction (Timo von Holtz) > 15. Re: System calls and Haskell threads (David Barbour) > 16. Re: System calls and Haskell threads (David Barbour) > 17. Re: How to speedup generically parsing sum types? (Bas van Dijk) > 18. Re: compiler construction (Sean Leather) > 19. Re: compiler construction (Thomas Schilling) > 20. Mailing lists at haskell.org (Giovanni Tirloni) > 21. Re: Mailing lists at haskell.org (Bas van Dijk) > 22. Re: Is generic information dumpable? (Bas van Dijk) > 23. Re: Is generic information dumpable? (Jos? Pedro Magalh?es) > 24. Re: Is generic information dumpable? (Bas van Dijk) > 25. Re: Message (Ryan Newton) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 3 Nov 2011 11:49:17 +0000 > From: Jos? Pedro Magalh?es <jpm(a)cs.uu.nl> > Subject: Re: [Haskell-cafe] How to speedup generically parsing sum > types? > To: Bas van Dijk <v.dijk.bas(a)gmail.com> > Cc: Haskell Cafe <haskell-cafe(a)haskell.org> > Message-ID: > <CA%2BZFbn_N27z_OABxHr1DPGRE%2B4m-t1BkK%3D-W%2BbDLvp66UC7G4Q(a)mail.gmail.com > > > Content-Type: text/plain; charset="iso-8859-1" > > Hi Bas, > > First of all, thanks for these numbers. I have previously compared the > performance of GP libs [1] and your results confirm what I would expect, > except for that last one, BigSum/fromJSON/generic. > > It's good that you're using INLINE pragmas on the generic function already. > What I would also try: > - Compile with -O2 and -fno-spec-constr-count (this last one is > particularly important) > - Add {-# INLINE [1] #-} pragmas to the to/from methods of your Generic > instances. > > To add these INLINE pragmas you will have to give your own instances of > Generic (so you can't derive them). I'd suggest you get hold of them with > -ddump-deriv, copy-paste and add the pragmas, just for testing purposes. > The phase is important: you first want to make sure you inline the generic > function definition, and only then the from/to. > > Please keep me posted on the effects of these suggestions. In particular, > if the INLINE pragmas on the from/to methods are essential, I'll be happy > to add them to the derived instances. > > > Cheers, > Pedro > > [1] http://dreixel.net/research/pdf/ogie.pdf > > 2011/11/3 Bas van Dijk <v.dijk.bas(a)gmail.com> > > > Hello, > > > > I recently added default generic implementations of toJSON and > > parseJSON to the aeson package. Now I'm optimizing them. Here are some > > benchmark results that compare: > > > > * th: toJSON and fromJSON generated by template-haskell. Can be > > compared to hand-written code. Should be the fastest of all. > > > > * syb: toJSON and fromJSON from the Data.Aeson.Generic module. Uses > > the Data type class. > > > > * generic: my toJSON and fromJSON using GHC Generics. > > > > The benchmark itself can be found here: > > > > > https://github.com/basvandijk/aeson/blob/optimizations/benchmarks/AesonComp… > > > > toJSON > > ====== > > > > D/toJSON/th 3.631734 us > > D/toJSON/syb 32.66679 us > > D/toJSON/generic 3.371868 us > > > > BigRecord/toJSON/th 8.982990 us > > BigRecord/toJSON/syb 48.90737 us > > BigRecord/toJSON/generic 8.971597 us > > > > BigProduct/toJSON/th 1.578259 us > > BigProduct/toJSON/syb 29.21153 us > > BigProduct/toJSON/generic 1.623115 us > > > > BigSum/toJSON/th 51.81214 ns > > BigSum/toJSON/syb 1.256708 us > > BigSum/toJSON/generic 71.32851 ns > > > > > > fromJSON > > ======== > > > > D/fromJSON/th 7.017204 us > > D/fromJSON/syb 23.46567 us > > D/fromJSON/generic 7.968974 us > > > > BigRecord/fromJSON/th 8.513789 us > > BigRecord/fromJSON/syb 36.64501 us > > BigRecord/fromJSON/generic 10.07809 us > > > > BigProduct/fromJSON/th 2.430677 us > > BigProduct/fromJSON/syb 17.97764 us > > BigProduct/fromJSON/generic 2.201130 us > > > > BigSum/fromJSON/th 414.8699 ns > > BigSum/fromJSON/syb 4.113170 us > > BigSum/fromJSON/generic 13.62614 us !!! > > > > > > As can be seen, in most cases the GHC Generics implementation is much > > faster than SYB and just as fast as TH. I'm impressed by how well GHC > > optimizes the code! > > > > Unfortunately the last benchmark, generically parsing a big sum type, > > is much slower. The code for parsing sums, which can be found here: > > > > > > > https://github.com/basvandijk/aeson/blob/optimizations/Data/Aeson/Types/Int… > > > > is basically this: > > > > > > instance (GFromSum a, GFromSum b) => GFromJSON (a :+: b) where > > gParseJSON (Object (M.toList -> [keyVal])) = gParseSum keyVal > > gParseJSON v = typeMismatch "sum (:+:)" v > > {-# INLINE gParseJSON #-} > > > > > > class GFromSum f where > > gParseSum :: Pair -> Parser (f a) > > > > instance (GFromSum a, GFromSum b) => GFromSum (a :+: b) where > > gParseSum keyVal = (L1 <$> gParseSum keyVal) <|> > > (R1 <$> gParseSum keyVal) > > {-# INLINE gParseSum #-} > > > > instance (Constructor c, GFromJSON a, ConsFromJSON a) => > > GFromSum (C1 c a) where > > gParseSum (key, value) > > | key == pack (conName (undefined :: t c a p)) = > > gParseJSON value > > | otherwise = notFound $ unpack key > > {-# INLINE gParseSum #-} > > > > > > notFound :: String -> Parser a > > notFound key = fail $ "The key \"" ++ key ++ "\" was not found" > > {-# INLINE notFound #-} > > > > > > Any idea how to make it faster? > > > > Regards, > > > > Bas > > >

2 2