- Haskell-Cafe - Haskell.org

Haskell meetups near Lund, Sweden?
by Carlo Hamalainen 24 Aug '13

24 Aug '13

Hi, Are there any Haskell or FP meetups near Lund, Sweden? I will be living there from October. Cheers, -- Carlo Hamalainen http://carlo-hamalainen.net

1 0

Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 120, Issue 35
by althainz 23 Aug '13

23 Aug '13

Von Samsung Mobile gesendet -------- Ursprüngliche Nachricht -------- Von: haskell-cafe-request(a)haskell.org Datum: 23.08.2013 11:36 (GMT+01:00) An: haskell-cafe(a)haskell.org Betreff: Haskell-Cafe Digest, Vol 120, Issue 35 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: Yet Another Forkable Class (John ExFalso) 2. Re: Yet Another Forkable Class (suhorng Y) 3. Lifting strictness to types (Thiago Negri) 4. Re: Lifting strictness to types (Tom Ellis) 5. Re: Lifting strictness to types (Thiago Negri) 6. instance Alternative ZipList (Stefan Mehner) 7. Re: Lifting strictness to types (Bardur Arantsson) 8. Hoogle vs Hayoo (jabolopes(a)google.com) 9. Re: Hoogle vs Hayoo (Mateusz Kowalczyk) 10. Re: monoids induced by Applicative/Alternative/Monad/MonadPlus? (Petr Pudl?k) 11. Re: Hoogle vs Hayoo (Johannes Waldmann) 12. Re: Yet Another Forkable Class (oleg(a)okmij.org) 13. Re: Hoogle vs Hayoo (Erik Hesselink) 14. Conduit : is it possible to write this function? (Erik de Castro Lopo) 15. Re: Hoogle vs Hayoo (Daniel Trstenjak) 16. Re: Conduit : is it possible to write this function? (Michael Snoyman) 17. typeclass constraints (TP) 18. Re: typeclass constraints (Adam Gundry) ---------------------------------------------------------------------- Message: 1 Date: Thu, 22 Aug 2013 15:50:23 +0100 From: John ExFalso <0slemi0(a)gmail.com> To: "Alberto G. Corona" <agocorona(a)gmail.com> Cc: "oleg(a)okmij.org" <oleg(a)okmij.org>, haskell-cafe <Haskell-cafe(a)haskell.org> Subject: Re: [Haskell-cafe] Yet Another Forkable Class Message-ID: <CAJEmqMj8Y7KoNVPS7x6zvvtkAmYheax9oigTPLLHDchfHde_pA(a)mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" To be honest I'm not so sure about these "effects"... Simply the fact that the Member class needs -XOverlappingInstances means that we cannot have duplicate or polymorphic effects. It will arbitrarily pick the first match in the former and fail to compile in the latter case. Furthermore I don't really understand the way open sums are implemented. These unions should be disjoint, but the way they're implemented in the paper they try to be "true" unions which cannot be done as that would need type equality (-XOverlappingInstances is a hack around this) A correct disjoint open sum would behave well with duplicate and polymorphic types in the type list. For example we should be able to project the open sum equivalent of Either String String into the second String but we cannot with the implementation in the paper. This means we need to ~index~ the type list instead of picking the result type and "trying for equality" with each entry. Something like this: http://lpaste.net/92069 Of course this is very inconvenient and simply replaces the monad transformers' lifts with a static index into the "effect" list. In general I think there is no convenient way of stacking effects that is also type safe. At some point we have to disambiguate which effect we are trying to use one way or the other. The implementation in the paper simply picks a heuristic and chooses the first effect that seems to match and discards the others. On 22 August 2013 12:15, Alberto G. Corona <agocorona(a)gmail.com> wrote: > The paper is very interesting: > > http://www.cs.indiana.edu/~sabry/papers/exteff.pdf > > It seems that the approach is mature enough and it is better in every way > than monad transformers, while at the same time the syntax may become > almost identical to MTL for many uses. > > I only expect to see the library in Hackage with all the blessings, and > with all the instances of the MTL classes in order to make the transition > form monad transformers to ExtEff as transparent as possible > > > 2013/8/22 <oleg(a)okmij.org> > > >> Perhaps effect libraries (there are several to choose from) could be a >> better answer to Fork effects than monad transformers. One lesson from >> the recent research in effects is that we should start thinking what >> effect we want to achieve rather than which monad transformer to >> use. Using ReaderT or StateT or something else is an implementation >> detail. Once we know what effect to achieve we can write a handler, or >> interpreter, to implement the desired operation on the World, obeying >> the desired equations. And we are done. >> >> For example, with ExtEff library with which I'm more familiar, the >> Fork effect would take as an argument a computation that cannot throw >> any requests. That means that the parent has to provide interpreters >> for all child effects. It becomes trivially to implement: >> >> > Another example would be a child that should not be able to throw >> errors as >> > opposed to the parent thread. >> It is possible to specify which errors will be allowed for the child >> thread (the ones that the parent will be willing to reflect and >> interpret). The rest of errors will be statically prohibited then. >> >> > instance (Protocol p) => Forkable (WebSockets p) (ReaderT (Sink p) IO) >> where >> > fork (ReaderT f) = liftIO . forkIO . f =<< getSink >> >> This is a good illustration of too much implementation detail. Why do we >> need to know of (Sink p) as a Reader layer? Would it be clearer to >> define an Effect of sending to the socket? Computation's type will >> make it patent the computation is sending to the socket. >> The parent thread, before forking, has to provide a handler for that >> effect (and the handler will probably need a socket). >> >> Defining a new class for each effect is possible but not needed at >> all. With monad transformers, a class per effect is meant to hide the >> ordering of transformer layers in a monad transformer stack. Effect >> libraries abstract over the implementation details out of the >> box. Crutches -- extra classes -- are unnecessary. We can start by >> writing handlers on a case-by-case basis. Generalization, if any, >> we'll be easier to see. From my experience, generalizing from concrete >> cases is easier than trying to write a (too) general code at the >> outset. Way too often, as I read and saw, code that is meant to be >> reusable ends up hardly usable. >> >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > > -- > Alberto. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >

1 0

monoids induced by Applicative/Alternative/Monad/MonadPlus?
by Petr Pudlák 23 Aug '13

23 Aug '13

Dear Haskellers, are these monoids defined somewhere? import Control.Applicativeimport Data.Monoid newtype AppMonoid m a = AppMonoid (m a)instance (Monoid a, Applicative m) => Monoid (AppMonoid m a) where mempty = AppMonoid $ pure mempty mappend (AppMonoid x) (AppMonoid y) = AppMonoid $ mappend <$> x <*> y-- With the () monoid for `a` this becames the monoid of effects. newtype AltMonoid m a = AltMonoid (m a)instance Alternative m => Monoid (AltMonoid m a) where mempty = AltMonoid empty mappend (AltMonoid x) (AltMonoid y) = AltMonoid $ x <|> y (and similarly for Monad/MonadPlus, until they become subclasses of Applicative?) Best regards, Petr

2 3

Munich Haskell Meeting, August 26th
by Christian Neukirchen 23 Aug '13

23 Aug '13

Dear all, our monthly Haskell Meeting will take place next week, Monday the 26th of August, at 19h30 in Munich. Please note that we will meet this time at the Max-Emanuel-Brauerei[1]. Last time, much more people showed up than registered and our table was pretty cramped: thus, if you plan to join, *please* add yourself to the Doodle at http://www.doodle.com/wfgkscwhkakf9uqa We also apologize that our website http://www.haskell-munich.de/ is currently unavailable. Please post to high-order-munich(a)fs.lmu.de or myself directly if you have any questions. Have a nice weekend and see you soon, chris [1] http://www.max-emanuel-brauerei.de/ -- Christian Neukirchen <chneukirchen(a)gmail.com> http://chneukirchen.org

1 0

typeclass constraints
by TP 23 Aug '13

23 Aug '13

Hi everybody, There is something I do not understand in the way typeclass constraints are inferred. 1/ Take the following function definition: sum' [] = [] sum' (x:xs) = x + sum' xs GHCI correctly gives: > :t sum' sum' :: Num [a] => [[a]] -> [a] So it has inferred that the type list has to be an instance of Num for sum' to be able to work. It will give an error if we try to use sum' without implementing the instance. 2/ Now, take the following definition: ------------------------ {-# LANGUAGE TemplateHaskell #-} import Language.Haskell.TH import Language.Haskell.TH.Syntax p :: a -> ExpQ p n = [| show n |] ------------------------ We obtain an error if we try to load it in GHCI: No instance for (Lift a) arising from a use of `n' Possible fix: add (Lift a) to the context of the type signature for p :: a -> ExpQ In the first argument of `show', namely `n' In the Template Haskell quotation [| show n |] In the expression: [| show n |] And indeed, if we use instead: ------------------------ {-# LANGUAGE TemplateHaskell #-} import Language.Haskell.TH import Language.Haskell.TH.Syntax p :: Lift a => a -> ExpQ p n = [| show n |] ------------------------ it works correctly. Why GHC is able to infer the typeclass constraint (Num a) in 1/, but not (Lift a) in 2/? Thanks in advance, TP

3 3

Lifting strictness to types
by Thiago Negri 22 Aug '13

22 Aug '13

I've just read the post "Destroying Performance with Strictness" by Neil Mitchell [1]. One of the comments from an Anonymous says: How hard would it be to lift strictness annotations to type-level? E.g. instead of f :: Int -> Int f !x = x + 1 write f :: !Int -> Int f x = x + 1 which would have the same effect. At least it would be transparent to the developer using a particular function. The problem I see with this approach is on type classes, as it would be impossible to declare a type instance with strict implementation to a type class that used lazy types. Is this a real problem? Is it the only one? [1] http://neilmitchell.blogspot.ru/2013/08/destroying-performance-with-strictn…

3 3

instance Alternative ZipList
by Stefan Mehner 22 Aug '13

22 Aug '13

I had an idea for |instance Alternative ZipList|, which doesn't seem to exist so far. Maybe there just is no need for it. Please tell me what you think. After giving the instance definition I will add some intuition on why this might be useful. Then some words on laws and other conceivable instances. This appeared on stackoverflow before to make sure it is new ( http://stackoverflow.com/questions/18210765/instance-alternative-ziplist-in… ). J. Abrahamson proposed to move this to the list, so here it is. The only thing I found so far is by AndrewC on stackoverflow: There are two sensible choices for Zip [1,3,4] <|> Zip [10,20,30,40]: Zip [1,3,4] because it's first - consistent with Maybe Zip [10,20,30,40] because it's longest - consistent with Zip [] being discarded (Here Zip is basically ZipList with the known Applicative instance.) Proposed instance ================= I think the answer should be Zip [1,3,4,40]. Let's see an instance: > instance Aternative Zip where > empty = Zip [] > Zip xs <|> Zip ys = Zip (go xs ys) where > go [] ys = ys > go xs [] = xs > go (x:xs) (_:ys) = x : go xs ys The only Zip a we can produce without knowing the type argument a is Zip [] :: Zip a, so there is little choice for empty. If the empty list is the neutral element of the monoid, we might be tempted to use list concatenation as the monoid operation. However, go is not (++), since every time we use one entry of the first argument list, we drop one of the second. Thus we have a kind of overlay: The left argument list hides the beginning of the right one (or all of it). [ 1, 3, 4,40] [10,20,30,40] [ 1, 3, 4] [ 1, 3, 4] ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ | | | | | | | | | | | | | | [ 1, 3, 4] | [10,20,30,40] []| | | [ 1, 3, 4] [10,20,30,40] [ 1, 3, 4] [ 1, 3, 4] [] (use monospace for ascii-art) For the some/many methods I'd guess > some (Zip z) = Zip (map repeat z) > many (Zip z) = Zip (map repeat z ++ repeat []) where some takes a ziplist and replaces every entry x by repeat x and many does the same but additionally extends the ziplist with empty lists. Probably not particularly usefull, but that's what the recursive definition of some and many gives. What is it good for? ==================== One intuition behind ziplists is processes: A finite or infinite stream of results. When zipping, we combine streams, which is reflected by the Applicative instance. When the end of the list is reached, the stream doesn't produce further elements. This is where the Alternative instance comes in handy: We can name a replacement, taking over as soon as the default process terminates. For example we could write < fmap Just foo <|> pure Nothing to wrap every element of the ziplist foo into a Just and continue with Nothing afterwards. The resulting ziplist is infinite, reverting to a default value after all (actual) values have been used up. This could of course be done by hand by appending an infinite list inside the Zip constructor. Yet the above is more elegant and does not assume knowledge of constructors, leading to higher code reusability. Another intuition one might have of zipLists is partial functions on naturals. Using this analogy, <|> behaves like the Monoid instance of Map and IntMap. Lawfulness ========== The definition of <|> given above is associative and the empty list really is the empty element. We also have < Zip [] <*> xs = fs <*> Zip [] = Zip [] < (fs <|> gs) <*> xs = fs <*> xs <|> gs <*> xs < fs <*> (xs <|> ys) = fs <*> xs <|> fs <*> ys so all the laws you could ask for are satisfied (which is not true for list concatenation by the way). This instance is consistent with the one for Maybe: Choice is biased to the left, yet when the left argument is unable to produce a value, the right argument takes over. The functions > zipToMaybe :: Zip a -> Maybe a > zipToMaybe (Zip []) = Nothing > zipToMaybe (Zip (x:_)) = Just x > maybeToZip :: Maybe a -> Zip a > maybeToZip Nothing = Zip [] > maybeToZip (Just x) = pure x are morphisms of alternatives (meaning psi x <|> psi y = psi (x <|> y) and psi x <*> psi y = psi (x <*> y)). Other options ============= Before putting this up to discussion I have to say this was conceived in an armchair: Until now I don't really know of any concrete uses for this instance. Might be there are none. Some words on AndrewC's instances (none of which has been put forward as a serious suggestion). Picking the longer list has a number of problems to it. When it comes to infinite lists (which are introduced by pure), we get undefined values. Also it's not very lazy: We have to evaluate both arguments until the shorter list ends just to get the first entry of the result. When both lists are of equal length we probably pick the left one, which defies the laws (distributivity in particular). Finally, you could just write > maximumBy (compare `on` length) [ys,xs] which is surprisingly readable (and biassed to the right). Picking the first nonempty list also feels strange: The 100-th entry of xs <|> ys should only depend on the 100-th entry of xs and ys or their absence. This is reasonable since processes shouldn't care to much about what happend 100 steps earlier. Yet if we only check for empty lists at the very beginning, the choice is permanent. Again, if you insist on doing so, just use > maximumBy (compare `on` not . null) [ys,xs] The overlaying instance given above introduces some non-trivial behaviour by allowing to mix lists together (instead of just returning one of the arguments). I can't think of any way to build this by combining four existing functions (avoiding length and drop). It satisfies all the laws and I can image it might at least be of some use.

1 0

Re: [Haskell-cafe] haskore -> lilypond -> typesetting?
by Stephen Tetley 22 Aug '13

22 Aug '13

"Here's one I did earlier..." http://www.flickr.com/photos/44929957@N03/4459628487/lightbox/ This is Haskore implementation of Chick Corea's "Child Song 6" rendered to LilyPond - I don't imagine Mr. Corea's publishers will be sending me a takedown request any time soon. There's a lot missing from Haskore that is needed to make good scores - the renderer of the above took a lot of effort with metrical grouping but the result is still abysmal. I doubt mathematics can help (common practice) music typesetting much - Western notation has had a thousand years to develop without the constraint of a regular syntax; so if Lilypond is horrible it is mostly the fault of what it tries to typeset (it does make some unwarranted mistakes like over-restricting the characters it can use for "variable" names and its parenthesizing is horrible). On 21 August 2013 14:05, Johannes Waldmann <waldmann(a)imn.htwk-leipzig.de>wrote: > I tried using lilypond ( http://www.lilypond.org/ ) > for typesetting of sheet music. > > While the output looks nice, the input language IMHO is quite horrible, > because the underlying data/execution model is underspecified. > For some parts, it tries to describe the logical structure of the score; > but for others, the layout; and in addition it has several non-obvious > context-dependencies (but see below), preventing modularity. > > Is there a better option? E.g., starting from a clear mathematical model, > as in Haskore, and use lilypond only as a PDF rendering engine? > > Do I want hly / hts perhaps? http://rd.slavepianos.org/?t=hly > > > As I see it, the main high-level design problem > is that the source language needs partial evaluation annotations > for abstractions applications: sometimes they should be expanded > (for MIDI rendering, always) and sometimes not (in typesetting, > to create repetition marks instead of actually repeating notes). > > > PS: I agree that some of lilypond's context dependencies > (relative pitch, implicit note length) do really save > large amounts of tedious typing: "c4 e g a c1" is much more economical > than "[c 1 qn, e 1 qn, g 1 qn , a 1 qn, c 2 fn]" > which I guess is the Haskore equivalent. > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

2 1

A question about laziness and performance in document serialization.
by Kyle Hanson 22 Aug '13

22 Aug '13

So I am not entirely clear on how to optimize for performance for lazy bytestrings. Currently I have a (Lazy) Map that contains large BSON values (more than 1mb when serialized each). I can serialize BSON documents to Lazy ByteStrings using Data.Binary.runPut. I then write this bytestring to a socket using Network.Socket.ByteString.Lazy. My question is this, if the Map object doesn't change (no updates) when it serializes the same document to the socket 2x in a row, does it re-evaluate the whole BSON value and convert it to a bytestring each time? Lets say I wanted to have a cache of bytestings so I have another Map object that has the serialized bytestrings that I populate it with every time the original BSON Map changes. Should the map be strict or lazy? Should the bytestrings it stores be strict or lazy? Any help in understanding laziness would be appreciated. -- Kyle Hanson

2 1

Retrieving Haddock comments with haskell-src-exts
by Mateusz Kowalczyk 22 Aug '13

22 Aug '13

I'm writing a small tool to help to analyse Haddock comments in Haskell source files to help me to indicate any potential breakage to documentation in existing source files. Currently I'm doing the parsing with the GHC's ‘parser’ function with Opt_Haddock set and I filter out everything I don't need. There are problems with this approach: determining any extensions and options used is vital for valid parsing of the files and a large amount of source files outright fails to parse without this information. Fortunately, haskell-src-exts exists and it can deal with all (or most) of this for me. Unfortunately, there doesn't seem to be any way to get it to recognise Haddock comments and the only option available is all comments or no comments at all. It's not easily possible to stitch these together without analysing the whole parse result. Currently I'm thinking of parsing out extensions and pragmas used using haskell-src-exts and then feeding those to GHC, effectively parsing the second time. Is there a way to avoid this? There's ‘lexTokenStream’ but I believe it has similar problems to ‘parser’, that is, needing to know the extensions beforehand. -- Mateusz K.

3 4