June 2011 - Haskell-Cafe

Cons of -XUndecidableInstances
by Scott Lawrence 07 Jun '11

07 Jun '11

According to the haskell-prime wiki[1], -XUndecidableInstances removes checks on the form of instance declaration, and just impose a depth limit to ensure termination (of compilation, I assume?). The listed Con is that this removes the clear boundary between legal and illegal programs, and behaviour may be implementation-dependent as the edge of that boundary is reached. How can I tell when I'm nearing that boundary? (And where are the sorts of things GHC does with types documented? I can't seem to find any good explanation of these things.) More specifically, I have class Model m a | m -> a where ... class Entropy d where ... instance (Model m a) => Entropy m where ... The first line requires MultiParamTypeClasses and FunctionalDependencies (the two seem to go together) - the third requires UndecidableInstances (since the type variable 'a' appears on the left but not the right). Is this likely to cause a problem? My guess is it shouldn't, since it's equivalent to class Model m a | m -> a where ... class Entropy d a where ... instance (Model m a) => Entropy m a where ... without bothering to actually use 'a' in Entropy - but one never knows... (Actually, a third type variable has to be introduced to Entropy to remove the UndecidableInstances dependency - "Constraint is no smaller than the instance head". This only increases the illogic in my humble eyes. These examples seem simple enough for GHC to handle nicely...) [1] http://hackage.haskell.org/trac/haskell-prime/wiki/UndecidableInstances -- Scott Lawrence

8 18

Attoparsec concatenating combinator
by Yitzchak Gale 07 Jun '11

07 Jun '11

I often find while using attoparsec and attoparsec-text that I need to match a number of text parsers consecutively and concatenate the result. By "text parser" I mean "Parser ByteString" for attoparsec and "Parser Text" for attoparsec-text. It seems the best I can do is to collect them all in a list and then apply concat. But that still copies the text several times. Is there a combinator that does this without all that copying? If not, does the internal representation easily admit such a combinator? Thanks, Yitz

5 13

ANNOUNCE: time-recurrence-0.5.2
by Chris Heller 07 Jun '11

07 Jun '11

I'm happy to announce the first fully functional release of time-recurrence: http://hackage.haskell.org/package/time-recurrence As of version 0.5.2, the library is now powerful enough to express all recurring dates which can be specified via the iCalendar RFC. An example: Generate the 15th and the 30th of the month, but only during the work week: > jan2011 = ptime "Sat, 01 Jan 2011 00:00:00 -0400" > jan2012 = ptime "Sun, 01 Jan 2012 00:00:00 -0400" > takeWhile (<= jan2012) $ recur monthly `starting` jan2011 $ > enumDays [15,30] >=> > filterWeekDays [Monday .. Friday] [2011-02-15 04:00:00 UTC ,2011-03-15 04:00:00 UTC, 2011-03-30 04:00:00 UTC ,2011-04-15 04:00:00 UTC ,2011-05-30 04:00:00 UTC ,2011-06-15 04:00:00 UTC, 2011-06-30 04:00:00 UTC ,2011-07-15 04:00:00 UTC ,2011-08-15 04:00:00 UTC, 2011-08-30 04:00:00 UTC ,2011-09-15 04:00:00 UTC, 2011-09-30 04:00:00 UTC ,2011-11-15 04:00:00 UTC, 2011-11-30 04:00:00 UTC ,2011-12-15 04:00:00 UTC, 2011-12-30 04:00:00 UTC ] As always I encourage feedback, criticism, suggestions and pull requests. -Chris

1 0

Twidge and "lsfollowers --all"
by Keith Edmunds 07 Jun '11

07 Jun '11

The github Twidge page [https://github.com/jgoerzen/twidge/wiki] states that this is the right place for questions about Twidge, so here goes. When running twidge lsfollowers --all $USERNAME my expectation is that all followers of $USERNAME will be listed. However, what appears to happen is that the first 100 followers' names are displayed, then there is a pause, then the same 100 names are displayed again; this cycle repeats (I stopped it after four iterations). Is this the expected behaviour? Thanks, Keith -- "You can have everything in life you want if you help enough other people get what they want" - Zig Ziglar. Who did you help today?

2 1

cap 3: stopping thread 3 (stackoverflow)
by Johannes Waldmann 07 Jun '11

07 Jun '11

I am running a Haskell program with some par/pseq annotations. When I use threadscope to view the eventlog (not "timeline" but "events") I see a lot of stackoverflow messages. What is this? I don't get any RTS errors printed on the console. The program finishes normally (albeit with less speedup than expected) Should I file this as a possible GHC RTS bug? At least the output is confusing. (... and why can't I copy/paste the text from threadscope's output window)

5 7

Library Versioning
by Luis Cabellos 07 Jun '11

07 Jun '11

Hello, I have a question about cabal versioning. It's possible to export in a cabal library a version, so instead of getting version from: import Paths_my_package( version ) I want to get version from my library using: import MyPackage( version ) And then using this from programs. Thanks, Luis

2 4

Re: [Haskell-cafe] Can it be proven there are no intermediate "useful" type classes between Applicative Functors & Monads?
by David Barbour 07 Jun '11

07 Jun '11

On Tue, Jun 7, 2011 at 6:14 AM, Casey McCann <syntaxglitch(a)gmail.com> wrote: > On Mon, Jun 6, 2011 at 7:55 PM, David Barbour <dmbarbour(a)gmail.com> wrote: > > Earlier forms of my reactive demand programming model [1] - before I > > switched to arrows - would qualify. The model has limited side-effects > (e.g. > > power a camera on only when someone is observing it) so we cannot use > > branchApplicative. The reactivity requires continuously weaving the two > > branches over time and recombining the results, which is distinct from > > branchMonad. > > Oh, very nice, thank you. I'd actually suspected that models of > reactive behavior might be a case where the distinction is meaningful. > I do still wonder if there's something roughly equivalent to the > (grossly inefficient and unusable, but producing the same results > otherwise) monad instance for zipping infinite streams, but I don't > have time to work through it right now to be sure... > The main trouble with using monads directly is that they're simply too powerful. Monads allow ad-hoc joins and loops based on data. The number of reactive relationships during any given instant can vary widely and unpredictably based on data. This makes it difficult to maintain stable relationships over continuous time. Looping and Branching must be carefully managed in my reactive model in order to gain stability over time that Monads do not possess.

1 0

Re: [Haskell-cafe] Can it be proven there are no intermediate "useful" type classes between Applicative Functors & Monads?
by David Barbour 07 Jun '11

07 Jun '11

On Mon, Jun 6, 2011 at 4:05 PM, Casey McCann <syntaxglitch(a)gmail.com> wrote: > ArrowChoice and ArrowApply are conceptually distinct and I expect > there are instances of the former that have no possible instance for > the latter. Branching vs. Monad I am much less certain of. > For a real-time or embedded DSL, or hardware modeling, you could easily desire 'Branching' and limited 'Loop' classes while rejecting the full power of Monads. > some type that's not obviously equivalent to one of these definitions: > branchMonad mb t f = do { b <- mb; if b then t else f } > branchApplicative = liftA3 (\b t f -> if b then t else f) > Earlier forms of my reactive demand programming model [1] - before I switched to arrows - would qualify. The model has limited side-effects (e.g. power a camera on only when someone is observing it) so we cannot use branchApplicative. The reactivity requires continuously weaving the two branches over time and recombining the results, which is distinct from branchMonad. [1] http://awelonblue.wordpress.com/2011/05/21/comparing-frp-to-rdp/

1 0

Re: [Haskell-cafe] Can it be proven there are no intermediate "useful" type classes between Applicative Functors & Monads?
by David Barbour 07 Jun '11

07 Jun '11

On Sun, Jun 5, 2011 at 12:51 PM, KC <kc1956(a)gmail.com> wrote: > If new intermediate classes crop up then there would be no point in fixing > > class (Applicative m) => Monad m where > > since it would have to be changed if new intermediate classes are found. > You might check out a few articles regarding Kleisli arrows [1][2] for possibilities that live between applicative and monad. Applicative itself is also a little on the strong side. I had to reject Applicative for one model of signal transformers because 'pure' was not a legal constructor, even though 'fmap . const' and '<*>' were okay. And even Functor is too strong if you want effective linearity. I've found Adam Megacz's Generalized Arrows [3] to be a suitable chassis for weaker models. [1] http://www.haskell.org/haskellwiki/Arrow_tutorial#Kleisli_Arrows [2] http://lambda-the-ultimate.org/node/4273 [3] http://www.cs.berkeley.edu/~megacz/garrows/

1 0

Re: [Haskell-cafe] Cons of -XUndecidableInstances
by oleg＠okmij.org 07 Jun '11

07 Jun '11

It seems that UndercidableInstances keep getting a bad rap. There are legitimate and decidable applications of UndercidableInstances. These applications have nothing to do with OOP, or HList for that matter. This topic is discussed at length in the article http://okmij.org/ftp/Haskell/types.html#undecidable-inst-defense Here are the conclusions: Thus there are patently decidable type programs that require UndecidableInstances. That extension should not be categorically stigmatized. In conclusion, UndecidableInstances is not a dangerous flag. It will never cause the type-checker to accept a program that `goes wrong.' The only bad consequence of using the flag is type checker's might be telling us that it cannot decide if our program is well-typed, given the context-stack--depth limit. We may ask the type-checker to try a bit harder (with a larger depth limit), or look through our program and find the problem. UndecidableInstances are quite like the primitive recursion criterion: all primitive recursion functions surely terminate; non-primitive recursion functions generally don't. Still there are many classes of non-primitive recursive functions that are total. To see their totality, one has to use more complex criteria.

3 2