- Haskell-Cafe - Haskell.org

reasons why Template Haskell does not propose something similar to Python exec() or eval()
by TP 25 Aug '13

25 Aug '13

Hi everybody, I continue to learn and test Template Haskell (one more time thanks to John Lato for his post at: http://www.mail-archive.com/haskell-cafe@haskell.org/msg106696.html that made me understand a lot of things). I have a question about the way Template Haskell is working. Why Template Haskell does not propose something similar to Python (or bash) exec() or eval(), i.e. does not offer the possibility to take a (quoted) string in input, to make abstract syntax in output (to be executed later in a splice $()). For example, in Python, to make an affectation 'a="a"' programatically, I can simply do (at runtime; even if I am here only concerned with what Template Haskell could do, i.e. at compile time): > def f(s): return '%s = \'%s\'' % (s,s) > exec(f("a")) > a 'a' With Template Haskell, I am compelled to make a function returning the abstract syntax corresponding to variable declaration: ValD (VarP $ mkName s) (NormalB $ LitE $ StringL s) (see complete example in Post Scriptum). This works fine, but it is less direct. I am sure that the Template Haskell approach has many advantages, but I am unable to list them. I think it is important to have the reasons in mind. Could you help me? Thanks in advance, TP PS: the complete Haskell example: ----------------------------------- module MakeVard where import Language.Haskell.TH makeVard :: Monad m => String -> m [Dec] -- Equivalent to "%s = \"%s\"" makeVard s = return [ ValD (VarP $ mkName s) (NormalB $ LitE $ StringL s) [] ] ----------------------------------- tested by ----------------------------------- {-# LANGUAGE TemplateHaskell #-} import MakeVard $(makeVard "a") main = do print a ----------------------------------- resulting in $ runghc -ddump-splices test.hs test_makeVar.hs:1:1: Splicing declarations makeVard "a" ======> test_makeVar.hs:4:3-14 a = "a" "a"

5 5

GHC flags: optghc
by jabolopes＠google.com 24 Aug '13

24 Aug '13

Hi, I am using GHC version 6.12.1. What is optghc ? I can't find that information anywhere... Thanks, Jose -- Jose Antonio Lopes Ganeti Engineering Google Germany GmbH Dienerstr. 12, 80331, München Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores Steuernummer: 48/725/00206 Umsatzsteueridentifikationsnummer: DE813741370

2 1

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