[Haskell-cafe] Haskell-Cafe Digest, Vol 99, Issue 9

yrazes yrazes at gmail.com
Fri Nov 4 06:21:10 CET 2011


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 at haskell.org> wrote:

> Send Haskell-Cafe mailing list submissions to
>        haskell-cafe at 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 at haskell.org
>
> You can reach the person managing the list at
>        haskell-cafe-owner at 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 at cs.uu.nl>
> Subject: Re: [Haskell-cafe] How to speedup generically parsing sum
>        types?
> To: Bas van Dijk <v.dijk.bas at gmail.com>
> Cc: Haskell Cafe <haskell-cafe at haskell.org>
> Message-ID:
>        <CA+ZFbn_N27z_OABxHr1DPGRE+4m-t1BkK=-W+bDLvp66UC7G4Q at 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 at 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/AesonCompareAutoInstances.hs
> >
> > 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/Internal.hs#L1059
> >
> > 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
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.haskell.org/pipermail/haskell-cafe/attachments/20111103/226d77dd/attachment-0001.htm
> >
>
> ------------------------------
>
> Message: 2
> Date: Thu, 3 Nov 2011 13:27:37 +0100
> From: Bas van Dijk <v.dijk.bas at gmail.com>
> Subject: Re: [Haskell-cafe] How to speedup generically parsing sum
>        types?
> To: Jos? Pedro Magalh?es <jpm at cs.uu.nl>
> Cc: Haskell Cafe <haskell-cafe at haskell.org>
> Message-ID:
>        <CADLz5wWgU9S=ihgGtANny1rh59JpcBRk0BDfMQTY3vQWJzvQRA at mail.gmail.com
> >
> Content-Type: text/plain; charset=UTF-8
>
> 2011/11/3 Jos? Pedro Magalh?es <jpm at cs.uu.nl>:
> > - Compile with -O2 and -fno-spec-constr-count (this last one is
> particularly
> > important)
>
> I already compiled with -O2. Adding -fno-spec-constr-count does not
> change the results.
>
> > - Add {-# INLINE [1] #-} pragmas to the to/from methods of your Generic
> > instances.
>
> I tried:
>
> BigSum/toJSON/generic goes from 70 ns to 52 ns! So inlining 'from' is
> an improvement.
>
> Unfortunately BigSum/fromJSON/generic stays at 13 us.
>
> Bas
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 3 Nov 2011 09:56:47 -0400
> From: Ryan Newton <rrnewton at gmail.com>
> Subject: Re: [Haskell-cafe] The type class wilderness + Separating
>        instances and implementations into separate packages
> To: Johan Tibell <johan.tibell at gmail.com>
> Cc: Haskell Cafe <haskell-cafe at haskell.org>
> Message-ID:
>        <CACYs5Aao+74zYJ248hWkq1KrU-e6a6UMxKJAs0mkb=sVKU+gWQ at mail.gmail.com
> >
> Content-Type: text/plain; charset=ISO-8859-1
>
> > I think the best option at the moment is to break out type classes in
> their> own packages. That's what I did with hashable.
> Indeed!  I greatly believe in this mantra now.  Really, my point was
> only this banal one -- packages with only interfaces in them have no
> dependencies and are much less likely than implementation packages to
> break when the GHC version changes.
>
> > Aside: The problem with collections is that we don't have the programming
> > language means to do this well yet (although soon!). The issue is that we
> > want to declare a type class where the context of the methods depends on
> the
> > instance e.g.
> > class MapLike m where
> > ? ? type Ctx :: Context ?-- Can't do this today!
> > ? ? insert Ctx => k -> v -> m -> m
> > Java et all cheats in their container hierarchy by doing unsafe casts
> (i.e.
> > they never solved this problem)!
>
> Ah, interesting.  Is there a proposal to do this?  While we need to
> avoid an infinite regress of generalization and abstraction (type
> programming => kind programming?, etc) -- it does seem like class
> contexts on types and type class instances themselves would be nice to
> have *some* control over.  (In the above message, for example I was
> having trouble due to not being able to hide instances on import.)
>
> > I would hope that we could get all the important interfaces into the
> Haskell
> > Platform eventually (and have all packages there use them).
>
> +1!
>
> Cheers,
>  -Ryan
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 3 Nov 2011 15:21:24 +0100
> From: Bas van Dijk <v.dijk.bas at gmail.com>
> Subject: Re: [Haskell-cafe] How to speedup generically parsing sum
>        types?
> To: Jos? Pedro Magalh?es <jpm at cs.uu.nl>
> Cc: Haskell Cafe <haskell-cafe at haskell.org>
> Message-ID:
>        <CADLz5wWtmSrMRou8+yXfL6v2fg25V996aEUE90KUPxs9h1kzuQ at mail.gmail.com
> >
> Content-Type: text/plain; charset=UTF-8
>
> For those who find this interesting. Here's the code of the BigSum
> benchmark
> with a manual Generic instance with inlined 'from' and 'to':
> https://gist.github.com/1336426
>
> Jos?, I was thinking about the following idea. Say GHC generates the
> following instance for BigSum:
>
> instance Generic BigSum where
>  type Rep BigSum = D1 D1BigSum SumOfBigSum
>  ...
>
> type SumOfBigSum =
>       (   (   (    C1 C1_0BigSum U1
>               :+: (C1 C1_1BigSum U1 :+: C1 C1_2BigSum U1)
>               )
>           :+: (    C1 C1_3BigSum U1
>               :+: (C1 C1_4BigSum U1 :+: C1 C1_5BigSum U1)
>               )
>           )
>       :+: (   (    C1 C1_6BigSum U1
>               :+: (C1 C1_7BigSum U1 :+: C1 C1_8BigSum U1)
>               )
>           :+: (    C1 C1_9BigSum  U1
>               :+: (C1 C1_10BigSum U1 :+: C1 C1_11BigSum U1)
>               )
>           )
>       )
>  :+: (   (   (    C1 C1_12BigSum U1
>              :+: (C1 C1_13BigSum U1 :+: C1 C1_14BigSum U1)
>              )
>          :+: (    C1 C1_15BigSum U1
>              :+: (C1 C1_16BigSum U1 :+: C1 C1_17BigSum U1)
>              )
>          )
>      :+: (   (    C1 C1_18BigSum U1
>              :+: (C1 C1_19BigSum U1 :+: C1 C1_20BigSum U1)
>              )
>          :+: (   (C1 C1_21BigSum U1 :+: C1 C1_22BigSum U1)
>              :+: (C1 C1_23BigSum U1 :+: C1 C1_24BigSum U1)
>              )
>          )
>      )
>
> It also generates the following function (or method): (I haven't
> figured out the correct type yet. A correct version might need to use
> type families or functional dependencies)
>
> conPath :: String -> Maybe (C1 ? ? ? -> SumOfBigSum)
> conPath "F01" = Just $ L1 . L1 . L1 . L1
> conPath "F02" = Just $ L1 . L1 . L1 . R1 . L1
> conPath "F03" = Just $ L1 . L1 . L1 . R1 . R1
> conPath "F04" = Just $ L1 . L1 . R1 . L1
> conPath "F05" = Just $ L1 . L1 . R1 . R1 . L1
> conPath "F06" = Just $ L1 . L1 . R1 . R1 . R1
> conPath "F07" = Just $ L1 . R1 . L1 . L1
> conPath "F08" = Just $ L1 . R1 . L1 . R1 . L1
> conPath "F09" = Just $ L1 . R1 . L1 . R1 . R1
> conPath "F10" = Just $ L1 . R1 . R1 . L1
> conPath "F11" = Just $ L1 . R1 . R1 . R1 . L1
> conPath "F12" = Just $ L1 . R1 . R1 . R1 . R1
> conPath "F13" = Just $ R1 . L1 . L1 . L1
> conPath "F14" = Just $ R1 . L1 . L1 . R1 . L1
> conPath "F15" = Just $ R1 . L1 . L1 . R1 . R1
> conPath "F16" = Just $ R1 . L1 . R1 . L1
> conPath "F17" = Just $ R1 . L1 . R1 . R1 . L1
> conPath "F18" = Just $ R1 . L1 . R1 . R1 . R1
> conPath "F19" = Just $ R1 . R1 . L1 . L1
> conPath "F20" = Just $ R1 . R1 . L1 . R1 . L1
> conPath "F21" = Just $ R1 . R1 . L1 . R1 . R1
> conPath "F22" = Just $ R1 . R1 . R1 . L1 . L1
> conPath "F23" = Just $ R1 . R1 . R1 . L1 . R1
> conPath "F24" = Just $ R1 . R1 . R1 . R1 . L1
> conPath "F25" = Just $ R1 . R1 . R1 . R1 . R1
> conPath _     = Nothing
>
> conPath is given the name of the constructor. If it's a valid name it
> will return a function that constructs a SumOfBigSum given the
> corresponding constructor. Of course, since the types of the
> constructors can vary (not in this case) coming up with a correct
> implementation is a challenge.
>
> Using conPath in my gParseJSON is easy:
>
> instance (GFromJSON a, GFromJSON b) => GFromJSON (a :+: b) where
>    gParseJSON (Object (M.toList -> [(key, val)])) =
>        case conPath key of
>          Nothing   -> mzero
>          Just path -> path <$> gParseJSON val
>
>    gParseJSON v = typeMismatch "sum (:+:)" v
>    {-# INLINE gParseJSON #-}
>
> I suspect this to be much more efficient.
>
> Bas
>
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 3 Nov 2011 15:43:01 +0100
> From: Bas van Dijk <v.dijk.bas at gmail.com>
> Subject: Re: [Haskell-cafe] The type class wilderness + Separating
>        instances and implementations into separate packages
> To: rrnewton at gmail.com
> Cc: Haskell Cafe <haskell-cafe at haskell.org>
> Message-ID:
>        <CADLz5wVZu2DWZO0YM5XDwm4hfVT_TGFX9Duy2ecxdMKv4ww58A at mail.gmail.com
> >
> Content-Type: text/plain; charset=UTF-8
>
> On 3 November 2011 14:56, Ryan Newton <rrnewton at gmail.com> wrote:
> >> Aside: The problem with collections is that we don't have the
> programming
> >> language means to do this well yet (although soon!). The issue is that
> we
> >> want to declare a type class where the context of the methods depends
> on the
> >> instance e.g.
> >> class MapLike m where
> >> ? ? type Ctx :: Context ?-- Can't do this today!
> >> ? ? insert Ctx => k -> v -> m -> m
> >> Java et all cheats in their container hierarchy by doing unsafe casts
> (i.e.
> >> they never solved this problem)!
> >
> > Ah, interesting. ?Is there a proposal to do this?
>
> Even better: it's already implemented by Max Bolingbroke and will be
> in ghc-7.4! See:
>
> http://hackage.haskell.org/trac/ghc/wiki/Status/Oct11
>
> So be patient and wait for your Christmas present ;-)
>
> Bas
>
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 3 Nov 2011 15:44:30 +0100
> From: "Claus Reinke" <claus.reinke at talk21.com>
> Subject: Re: [Haskell-cafe] How to speedup generically parsing sum
>        types?
> To: "Bas van Dijk" <v.dijk.bas at gmail.com>,      "Haskell Cafe"
>        <haskell-cafe at haskell.org>
> Cc: Jos? Pedro Magalh?es <jpm at cs.uu.nl>,        Bryan O'Sullivan
>        <bos at mailrank.com>
> Message-ID: <3DC9BEF4C6464535BA6628D8E5788DD4 at VAIO>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
>        reply-type=original
>
> > * syb: toJSON and fromJSON from the Data.Aeson.Generic module. Uses
> > the Data type class.
> >..
> > 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!
>
> Not that it matters much if you're going with other tools, but your
> SYB code has a long linear chain of type rep comparisons, at every
> level of the recursive traversals. That is partially inherent in the SYB
> design (reducing everything to cast), but could probably be improved?
>
> Claus
>
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 3 Nov 2011 15:53:16 +0100
> From: Bas van Dijk <v.dijk.bas at gmail.com>
> Subject: Re: [Haskell-cafe] How to speedup generically parsing sum
>        types?
> To: Claus Reinke <claus.reinke at talk21.com>
> Cc: Jos? Pedro Magalh?es <jpm at cs.uu.nl>,        Bryan O'Sullivan
>        <bos at mailrank.com>,     Haskell Cafe <haskell-cafe at haskell.org>
> Message-ID:
>        <CADLz5wW7CotdHaaLS3uU9LG=Un2Og6FhnHxSm8k=zq6zwMT3Wg at mail.gmail.com
> >
> Content-Type: text/plain; charset=UTF-8
>
> 2011/11/3 Claus Reinke <claus.reinke at talk21.com>:
> > Not that it matters much if you're going with other tools, but your SYB
> code
> > has a long linear chain of type rep comparisons, at every
> > level of the recursive traversals. That is partially inherent in the SYB
> > design (reducing everything to cast), but could probably be improved?
>
> I'm not an expert on the SYB code. So if you have an idea how to
> improve it please file a ticket or even better send a pull request.
>
> Cheers,
>
> Bas
>
>
>
> ------------------------------
>
> Message: 8
> Date: Thu, 03 Nov 2011 08:27:58 -0700
> From: Trevor Elliott <trevor at galois.com>
> Subject: [Haskell-cafe] [ANNOUNCE] cereal-0.3.4.0
> To: Haskell Cafe <haskell-cafe at haskell.org>
> Message-ID: <4EB2B2FE.2010701 at galois.com>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>
> 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
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/pkcs7-signature
> Size: 2298 bytes
> Desc: S/MIME Cryptographic Signature
> URL: <
> http://www.haskell.org/pipermail/haskell-cafe/attachments/20111103/914a2430/attachment-0001.bin
> >
>
> ------------------------------
>
> Message: 9
> Date: Thu, 3 Nov 2011 11:35:28 -0400
> From: Andreas Voellmy <andreas.voellmy at gmail.com>
> Subject: [Haskell-cafe] System calls and Haskell threads
> To: Haskell Cafe <haskell-cafe at haskell.org>
> Message-ID:
>        <CADdwyZkTas7ULo6Bd96YieNAz6YUuM9HZ=SSJVpyEpc9KRy=2w at mail.gmail.com
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> I just read Kazu Yamamoto's article on a high performance web server in the
> latest Monad.Reader, and I came across a statement that doesn't sound
> correct to me. He says:
>
> "When a user thread issues a system call, a context switch occurs. This
> means that all Haskell user threads stop, and instead the kernel is given
> the CPU time. "
>
> Is this right? I thought that when a system call is made by a Haskell
> thread being run by a particular worker thread on a CPU, other runnable
> Haskell threads in the run queues of the HECs for other CPUs can continue
> running concurrently (provided we've run our Haskell program with multiple
> CPUs using the -Nx RTS argument). That's what I understood from the
> discussion of foreign calls in "Runtime Support for Multicore Haskell".
>
> Andreas
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.haskell.org/pipermail/haskell-cafe/attachments/20111103/d5b504b7/attachment-0001.htm
> >
>
> ------------------------------
>
> Message: 10
> Date: Thu, 3 Nov 2011 09:26:01 -0700
> From: Johan Tibell <johan.tibell at gmail.com>
> Subject: Re: [Haskell-cafe] System calls and Haskell threads
> To: Andreas Voellmy <andreas.voellmy at gmail.com>
> Cc: Haskell Cafe <haskell-cafe at haskell.org>
> Message-ID:
>        <CAK-tuPatRsYbY35zgtOOgZUXVp8ewXva571bEUA4oUOrOZ_Xfg at mail.gmail.com
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Thu, Nov 3, 2011 at 8:35 AM, Andreas Voellmy
> <andreas.voellmy at gmail.com>wrote:
>
> > I just read Kazu Yamamoto's article on a high performance web server in
> > the latest Monad.Reader, and I came across a statement that doesn't sound
> > correct to me. He says:
> >
> > "When a user thread issues a system call, a context switch occurs. This
> > means that all Haskell user threads stop, and instead the kernel is given
> > the CPU time. "
> >
> > Is this right? I thought that when a system call is made by a Haskell
> > thread being run by a particular worker thread on a CPU, other runnable
> > Haskell threads in the run queues of the HECs for other CPUs can continue
> > running concurrently (provided we've run our Haskell program with
> multiple
> > CPUs using the -Nx RTS argument). That's what I understood from the
> > discussion of foreign calls in "Runtime Support for Multicore Haskell".
> >
>
> That's correct. Blocking syscalls will not prevent other Haskell threads
> from running. IIRC it will block the OS thread used to run the Haskell
> thread making the blocking syscall, but the RTS always has one free OS
> thread (i.e. it will allocated more if needed) that it can use to continue
> running other Haskell threads with. Your best reference is probably
> "Extending the Haskell Foreign Function Interface with Concurrency".
>
> -- Johan
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.haskell.org/pipermail/haskell-cafe/attachments/20111103/2e7edb2f/attachment-0001.htm
> >
>
> ------------------------------
>
> Message: 11
> Date: Fri, 4 Nov 2011 00:26:44 +0800
> From: Magicloud Magiclouds <magicloud.magiclouds at gmail.com>
> Subject: [Haskell-cafe] Is generic information dumpable?
> To: haskell-cafe <haskell-cafe at haskell.org>
> Message-ID:
>        <CABErt4e0-XGHYM0-LWOqjao_aMQnuFYbWW+WdSUdC_ys77xuYg at mail.gmail.com
> >
> Content-Type: text/plain; charset=UTF-8
>
> 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.
> --
> ???????
> ???????
>
>
>
> ------------------------------
>
> Message: 12
> Date: Thu, 3 Nov 2011 16:30:09 +0000
> From: Jos? Pedro Magalh?es <jpm at cs.uu.nl>
> Subject: Re: [Haskell-cafe] Is generic information dumpable?
> To: Magicloud Magiclouds <magicloud.magiclouds at gmail.com>
> Cc: haskell-cafe <haskell-cafe at haskell.org>
> Message-ID:
>        <CA+ZFbn_zskdWeBS8u8Up50O0dV-3w1h3z-a7bxz33zAz60XUEA at mail.gmail.com
> >
> Content-Type: text/plain; charset="gb2312"
>
> "-ddump-deriv" will print (most of) it.
>
>
> Cheers,
> Pedro
>
> On Thu, Nov 3, 2011 at 16:26, Magicloud Magiclouds <
> magicloud.magiclouds at gmail.com> wrote:
>
> > 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.
> > --
> > ???????
> > ???????
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.haskell.org/pipermail/haskell-cafe/attachments/20111103/64465706/attachment-0001.htm
> >
>
> ------------------------------
>
> Message: 13
> Date: Thu, 03 Nov 2011 17:38:56 +0100
> From: Twan van Laarhoven <twanvl at gmail.com>
> Subject: Re: [Haskell-cafe] How to speedup generically parsing sum
>        types?
> To: haskell-cafe at haskell.org
> Message-ID: <4EB2C3A0.3010307 at gmail.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 03/11/11 11:16, Bas van Dijk wrote:
> > ...
> > 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 #-}
>
> Perhaps relying on Attoparsec backtracking for picking out the right
> alternative from the sum is the problem. You could try it with Maybe:
>
>
> class GFromSum f where
>     gParseSum :: Pair -> Maybe (Parser (f a))
>
> instance (Constructor c, GFromJSON a, ConsFromJSON a)
>         => GFromSum (C1 c a) where
>     gParseSum (key, value)
>         | key == pack (conName (undefined :: t c a p))
>                     = Just (gParseJSON value)
>         | otherwise = Nothing
>
> instance (GFromSum a, GFromSum b) => GFromSum (a :+: b) where
>     gParseSum keyVal = (fmap L1 <$> gParseSum keyVal)
>                    <|> (fmap R1 <$> gParseSum keyVal)
>     {-# INLINE gParseSum #-}
>
> instance (GFromSum a, GFromSum b) => GFromJSON (a :+: b) where
>     gParseJSON (Object (M.toList -> [keyVal]))
>         | Just p <- gParseSum keyVal -> p
>     gParseJSON v = typeMismatch "sum (:+:)" v
>
>
>
> Twan
>
>
>
> ------------------------------
>
> Message: 14
> Date: Thu, 3 Nov 2011 18:02:32 +0100
> From: Timo von Holtz <timo.v.holtz at googlemail.com>
> Subject: [Haskell-cafe] compiler construction
> To: haskell-cafe <haskell-cafe at haskell.org>
> Message-ID:
>        <CAAsSstvv9eskMhLxo6nMHgWPkQcXT+7PtpYO-jOuKGDiT=aR0A at mail.gmail.com
> >
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi,
>
> I study computer science in Kiel, Germany and I want to study abroad.
> Now I look for Universities, which offer compiler construction, since
> I need that course, preferably in the UK, Ireland, Australia or New
> Zealand.
> Ideally it would be in Haskell of course.
>
> Greetings
> Timo
>
>
>
> ------------------------------
>
> Message: 15
> Date: Thu, 3 Nov 2011 10:22:20 -0700
> From: David Barbour <dmbarbour at gmail.com>
> Subject: Re: [Haskell-cafe] System calls and Haskell threads
> To: Andreas Voellmy <andreas.voellmy at gmail.com>
> Cc: Haskell Cafe <haskell-cafe at haskell.org>
> Message-ID:
>        <CAAOQMSs7LCw1RsAqtpN424nWYTswaZXU-Uau1-d1-e1pKVEaHQ at mail.gmail.com
> >
> Content-Type: text/plain; charset="utf-8"
>
> On Thu, Nov 3, 2011 at 8:35 AM, Andreas Voellmy
> <andreas.voellmy at gmail.com>wrote:
>
> > I just read Kazu Yamamoto's article on a high performance web server in
> > the latest Monad.Reader, and I came across a statement that doesn't sound
> > correct to me. He says:
> >
> > "When a user thread issues a system call, a context switch occurs. This
> > means that all Haskell user threads stop, and instead the kernel is given
> > the CPU time. "
> >
> > Is this right?
> >
>
> It is correct in context. Mighttpd does not use the -Nx argument to create
> multiple OS threads, instead uses a `prefork` model that creates separate
> processes to balance user invocations. Using multiple processes instead of
> multiple Haskell threads avoids issues with garbage collection.
>
> Regards,
>
> Dave
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.haskell.org/pipermail/haskell-cafe/attachments/20111103/e78a2a39/attachment-0001.htm
> >
>
> ------------------------------
>
> Message: 16
> Date: Thu, 3 Nov 2011 10:24:00 -0700
> From: David Barbour <dmbarbour at gmail.com>
> Subject: Re: [Haskell-cafe] System calls and Haskell threads
> To: Andreas Voellmy <andreas.voellmy at gmail.com>
> Cc: Haskell Cafe <haskell-cafe at haskell.org>
> Message-ID:
>        <CAAOQMSuxRRrsqh9qVa-L=paat8ZrwhbVsTdbP_Pw0MfCDJ2-Tw at mail.gmail.com
> >
> Content-Type: text/plain; charset="utf-8"
>
> On Thu, Nov 3, 2011 at 10:22 AM, David Barbour <dmbarbour at gmail.com>
> wrote:
>
> > It is correct in context. Mighttpd does not use the -Nx argument to
> create
> > multiple OS threads, instead uses a `prefork` model that creates separate
> > processes to balance user invocations. Using multiple processes instead
> of
> > multiple Haskell threads avoids issues with garbage collection.
> >
>
> I should rephrase that: using multiple processes in place of -Nx threads
> avoids issues with GC. Mighttpd does use multiple Haskell threads per
> Haskell process.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.haskell.org/pipermail/haskell-cafe/attachments/20111103/322def1e/attachment-0001.htm
> >
>
> ------------------------------
>
> Message: 17
> Date: Thu, 3 Nov 2011 19:44:26 +0100
> From: Bas van Dijk <v.dijk.bas at gmail.com>
> Subject: Re: [Haskell-cafe] How to speedup generically parsing sum
>        types?
> To: Twan van Laarhoven <twanvl at gmail.com>
> Cc: haskell-cafe at haskell.org
> Message-ID:
>        <CADLz5wUHgaH3U_wfkKbJVAa0-skkw-9vqJToUFxa09oxo=bvGg at mail.gmail.com
> >
> Content-Type: text/plain; charset=UTF-8
>
> On 3 November 2011 17:38, Twan van Laarhoven <twanvl at gmail.com> wrote:
> > Perhaps relying on Attoparsec backtracking for picking out the right
> > alternative from the sum is the problem. You could try it with Maybe:
>
> Good idea. I implemented and committed it and the
> BigSum/fromJSON/generic benchmark goes from 13.6 us to 11.3 us. Still
> a lot slower than the 4.1 us of SYB or the 414.9 ns of TH but an
> improvement nonetheless.
>
> Thanks for the idea!
>
> Bas
>
>
>
> ------------------------------
>
> Message: 18
> Date: Thu, 3 Nov 2011 20:26:18 +0100
> From: Sean Leather <leather at cs.uu.nl>
> Subject: Re: [Haskell-cafe] compiler construction
> To: Timo von Holtz <timo.v.holtz at googlemail.com>
> Cc: haskell-cafe <haskell-cafe at haskell.org>
> Message-ID:
>        <CACz_ru1O5A5ASrbYDb-t08TWLx6H5LjVZwjyiZjrYTadNdz3yA at mail.gmail.com
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Timo,
>
>
> > Now I look for Universities, which offer compiler construction, since
> > I need that course, preferably in the UK, Ireland, Australia or New
> > Zealand.
> > Ideally it would be in Haskell of course.
> >
>
> I currently work in a research group that is well known for their compiler
> construction research. You may have heard of UHC, the Utrecht Haskell
> Compiler [1]? If not, you should look into it. We have a master's course on
> compiler construction [2] taught by one of the architects [3] of UHC. There
> is even a second Haskell-ish compiler, Helium [4], that has shone the way
> towards better error messages.
>
> The people [5] in the Software Technology group [6] at Utrecht University
> do a lot of other interesting work, too. The topics include functional
> programming, generic programming, dependently typed programming, parser
> combinators, static analysis, type systems, etc.
>
> UU is based in the Netherlands, not one of the English-speaking locations
> you seem to prefer. But the lingua franca here is English and there are
> students and staff from all over, so it can seem like a "more foreign"
> place at times.
>
> We're happy to have more students interested in pushing the boundaries of
> language research.
>
> Regards,
> Sean
>
> [1] http://www.cs.uu.nl/wiki/UHC
> [2] http://www.cs.uu.nl/wiki/Cco
> [3] http://www.cs.uu.nl/wiki/Atze
> [4] http://www.cs.uu.nl/wiki/Helium
> [5] http://www.cs.uu.nl/wiki/Center/People
> [6] http://www.cs.uu.nl/wiki/Center
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.haskell.org/pipermail/haskell-cafe/attachments/20111103/15b09b42/attachment-0001.htm
> >
>
> ------------------------------
>
> Message: 19
> Date: Thu, 3 Nov 2011 19:53:33 +0000
> From: Thomas Schilling <nominolo at googlemail.com>
> Subject: Re: [Haskell-cafe] compiler construction
> To: Timo von Holtz <timo.v.holtz at googlemail.com>
> Cc: haskell-cafe <haskell-cafe at haskell.org>
> Message-ID:
>        <CAOJG3uDdwGyQLM2DrZKH7NNd6vzAwstVV_mxOiN2dQ7gZxre2g at mail.gmail.com
> >
> Content-Type: text/plain; charset=ISO-8859-1
>
> Chalmers University in Gothenburg, Sweden has a master's programme
> that includes a compiler construction course.  For the lectures from
> last term, see:
> http://www.cse.chalmers.se/edu/course/TDA282/lectures.html
>
> When I took it in 2006 it was a very practical course -- your task was
> to implement a basic compiler and the final grade was based on the
> number of features you implemented.  You could choose to do it in
> Haskell, Java or C++.
>
> The master's course is "Secure and Dependable Computer Systems" and
> takes 2 years. You could also become an exchange student at Chalmers
> via Erasmus, but the course is only given once a year, so if you plan
> to do a 6 month exchange then you have to time it right.
>
> Of course, Chalmers is in Sweden and therefore in none of your
> preferred countries.  However, all MSc courses are taught in English
> and almost everyone in Sweden speaks English very well.  Learning
> Swedish also isn't very difficult if you're (I assume) German.  If you
> stick to it, you can be fluent in 6 months (I didn't, but I can read a
> lot of Swedish).
>
> As an alternative in the UK, you might consider Nottingham University.
>  They too have a strong FP research group and their compiler
> construction course seems to use Haskell as well:
> http://www.cs.nott.ac.uk/~nhn/G53CMP/
>
> Other Universities in your preferred countries you might want to check
> out (though I don't know anything about their taught programs), they
> are known to have FP researchers:
>
>  - UNSW, Sydney
>  - Oxford, England
>  - Edinburgh Univ. or Harriot Watts (though HW is more O'Caml/SML)
>  - Univ. of St. Andrews, Scotland
>  - Univ. of Strathclyde, Glasgow, Scotland
>  - Leicester, England (teaches Haskell to undergrads, not sure about
> compiler constr.)
>  - Imperial College, London
>  - University College London (UCL)
>  - (there're probably more...)
>
> On 3 November 2011 17:02, Timo von Holtz <timo.v.holtz at googlemail.com>
> wrote:
> > Hi,
> >
> > I study computer science in Kiel, Germany and I want to study abroad.
> > Now I look for Universities, which offer compiler construction, since
> > I need that course, preferably in the UK, Ireland, Australia or New
> > Zealand.
> > Ideally it would be in Haskell of course.
> >
> > Greetings
> > Timo
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
>
>
>
> --
> Push the envelope. Watch it bend.
>
>
>
> ------------------------------
>
> Message: 20
> Date: Thu, 3 Nov 2011 20:11:20 -0200
> From: Giovanni Tirloni <gtirloni at sysdroid.com>
> Subject: [Haskell-cafe] Mailing lists at haskell.org
> To: haskell-cafe at haskell.org
> Message-ID:
>        <CAJ9AoK-u2ouffS_yYEC4NLh9GZ7oK0i_q78H9jzpi8Xfdn0DSA at mail.gmail.com
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
>
>  Does anyone know what's the procedure to create a new mailing list at
> haskell.org for a forming user group?
>
> Thank you,
>
> --
> Giovanni
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.haskell.org/pipermail/haskell-cafe/attachments/20111103/20247371/attachment-0001.htm
> >
>
> ------------------------------
>
> Message: 21
> Date: Thu, 3 Nov 2011 23:58:10 +0100
> From: Bas van Dijk <v.dijk.bas at gmail.com>
> Subject: Re: [Haskell-cafe] Mailing lists at haskell.org
> To: Giovanni Tirloni <gtirloni at sysdroid.com>
> Cc: haskell-cafe at haskell.org
> Message-ID:
>        <CADLz5wUp3piCvx-gR8cBoLER0Nfbf+SkD0SPWqshrVOL_aqXZQ at mail.gmail.com
> >
> Content-Type: text/plain; charset=UTF-8
>
> On 3 November 2011 23:11, Giovanni Tirloni <gtirloni at sysdroid.com> wrote:
> > Does anyone know what's the procedure to create a new mailing list at
> > haskell.org for a forming user group?
>
> community.haskell.org provides MailMan mailing lists:
>
> Cheers,
>
> Bas
>
>
>
> ------------------------------
>
> Message: 22
> Date: Fri, 4 Nov 2011 00:26:04 +0100
> From: Bas van Dijk <v.dijk.bas at gmail.com>
> Subject: Re: [Haskell-cafe] Is generic information dumpable?
> To: Jos? Pedro Magalh?es <jpm at cs.uu.nl>
> Cc: haskell-cafe <haskell-cafe at haskell.org>
> Message-ID:
>        <CADLz5wVu0-uH=izRbKZxHg6QuTSQE_ntOcry46Jk-duDsaPKMA at mail.gmail.com
> >
> Content-Type: text/plain; charset=UTF-8
>
> 2011/11/3 Jos? Pedro Magalh?es <jpm at cs.uu.nl>:
> > "-ddump-deriv" will print (most of) it.
>
> But it doesn't print the most useful piece of information: the
> definition of Rep.
>
> It would be great if this could be added.
>
> Currently when I have a type that I want to know the Rep of, say:
>
> data Foo = Bar Int
>         | Boo {hello :: String}
>           deriving Generic
>
> I just convert it to a Rep and show it:
>
> err = show $ from $ Boo "World"
>
> However Reps don't have Show instances so GHC complains:
>
> No instance for
>  (Show (D1 D1Foo (   C1 C1_0Foo (S1 NoSelector (Rec0 Int))
>                  :+: C1 C1_1Foo (S1 S1_1_0Foo (Rec0 String))
>                  )
>         x0
>        )
>  )
>  arising from a use of `show'
>
> And there you go. This is the only time when I'm happy to see an error
> message :-)
>
> Bas
>
>
>
> ------------------------------
>
> Message: 23
> Date: Thu, 3 Nov 2011 23:33:35 +0000
> From: Jos? Pedro Magalh?es <jpm at cs.uu.nl>
> Subject: Re: [Haskell-cafe] Is generic information dumpable?
> To: Bas van Dijk <v.dijk.bas at gmail.com>
> Cc: haskell-cafe <haskell-cafe at haskell.org>
> Message-ID:
>        <CA+ZFbn-gWOF8pcGTX2WnABwHbdAmXkfUAaZAsavQxq6376Ak7Q at mail.gmail.com
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
>
> 2011/11/3 Bas van Dijk <v.dijk.bas at gmail.com>
>
> > 2011/11/3 Jos? Pedro Magalh?es <jpm at cs.uu.nl>:
> > > "-ddump-deriv" will print (most of) it.
> >
> > But it doesn't print the most useful piece of information: the
> > definition of Rep.
> >
>
> Yes... I am aware of this.
>
>
> >
> > It would be great if this could be added.
> >
>
> I'll do it.
>
>
> Cheers,
> Pedro
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.haskell.org/pipermail/haskell-cafe/attachments/20111103/11af8c25/attachment-0001.htm
> >
>
> ------------------------------
>
> Message: 24
> Date: Fri, 4 Nov 2011 01:01:26 +0100
> From: Bas van Dijk <v.dijk.bas at gmail.com>
> Subject: Re: [Haskell-cafe] Is generic information dumpable?
> To: Jos? Pedro Magalh?es <jpm at cs.uu.nl>
> Cc: haskell-cafe <haskell-cafe at haskell.org>
> Message-ID:
>        <CADLz5wXQWgTK3NDMSgCcqiU6zbVSy+PcjvYnxKZRL8kL7_X7Pg at mail.gmail.com
> >
> Content-Type: text/plain; charset=UTF-8
>
> 2011/11/4 Jos? Pedro Magalh?es <jpm at cs.uu.nl>:
> > Hi,
> >
> > 2011/11/3 Bas van Dijk <v.dijk.bas at gmail.com>
> >>
> >> 2011/11/3 Jos? Pedro Magalh?es <jpm at cs.uu.nl>:
> >> > "-ddump-deriv" will print (most of) it.
> >>
> >> But it doesn't print the most useful piece of information: the
> >> definition of Rep.
> >
> > Yes... I am aware of this.
> >
> >>
> >> It would be great if this could be added.
> >
> > I'll do it.
> >
> >
> > Cheers,
> > Pedro
> >
> >
> >
>
> Great, thanks!
>
>
>
> ------------------------------
>
> Message: 25
> Date: Fri, 4 Nov 2011 00:09:59 -0400
> From: Ryan Newton <rrnewton at gmail.com>
> Subject: Re: [Haskell-cafe] Message
> To: David Leimbach <leimy2k at gmail.com>
> Cc: haskell-cafe at haskell.org
> Message-ID:
>        <CACYs5AZxZgNmorMDG3454VDR2ctmH=Ez0rbJGsKr1tzOCdAJ8A at mail.gmail.com
> >
> Content-Type: text/plain; charset=ISO-8859-1
>
> > I have interfaced Erlang and Haskell... And delivered it as a product. ?I
> > just came up with a dead-simple text based communication syntax from
> Erlang
> > to Haskell that was very easily testable. ?It allowed for complete
> isolation
>
> Interesting.  I can't imagine there are too many people who have done
> this.  So I must ask -- given the explicit attempt to imitate Erlang
> in recent CloudHaskell work, does that come close to giving you
> everything you would have wanted in this app?
>
> (Hot code update being the big missing piece.)
>
> Cheers,
>  -Ryan
>
>
>
> ------------------------------
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
> End of Haskell-Cafe Digest, Vol 99, Issue 9
> *******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20111104/5cdcdff2/attachment.htm>


More information about the Haskell-Cafe mailing list