[Haskell-cafe] haskell platform question
I'd like to build the haskell platform against a recent GHC snapshot, for testing purposes. I see that I can download the source for the platform from: http://lambda.galois.com/hp-tmp/2011.2.0.1/haskell-platform-2011.2.0.1.tar.gz with instructions: http://www.vex.net/~trebla/haskell/haskell-platform.xhtml However when I tried this some months ago, I found that some of the packages in the above source fail to build due to recent ghc changes (eg it's stricter handling of bang patterns). Is there a more recent beta snapshot of the platform? Or a darcs/git repo somewhere? I imagine wanting to build the platform against bleeding edge ghc would be a pretty common desire. Tim ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can it be proven there are no intermediate useful type classes between Applicative Functors Monads?
On 6/6/11 7:05 PM, Casey McCann wrote: On Mon, Jun 6, 2011 at 5:32 PM, Matthew Steelemdste...@alum.mit.edu wrote: branchApplicative = liftA3 (\b t f - if b then t else f) This definition doesn't satisfy the laws given for the Branching class; it will execute the effects of both branches regardless of which is chosen. How would it violate the laws for Identity or Reader? It wouldn't violate the laws for those (or other benign effects, given a suitable definition of benign), but it'd clearly violate the laws for things like Writer, ST, IO,... -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comment Syntax
On 06/06/2011 22:14, Evan Laforge wrote: Back to Haskell: I agree, the choice of the comment delimiter was not the best in light of the possibility to define operators containing it as a substring. But changing it to have --| start a comment too might break too much code (and eliminating -- as a comment starter would certainly break far too much code). I like that you have to put a space in for haddock comments. I originally posted because I found that --| stood out much more clearly as a structured comment than -- |. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comment Syntax
On 7 June 2011 17:41, Guy guytsalmave...@yahoo.com wrote: On 06/06/2011 22:14, Evan Laforge wrote: Back to Haskell: I agree, the choice of the comment delimiter was not the best in light of the possibility to define operators containing it as a substring. But changing it to have --| start a comment too might break too much code (and eliminating -- as a comment starter would certainly break far too much code). I like that you have to put a space in for haddock comments. I originally posted because I found that --| stood out much more clearly as a structured comment than -- |. How does a missing space character make that stand out any more? :/ (Admittedly, I rely more on emacs using a different colour for Haddock comments than non-Haddock comments.) -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comment Syntax
On 07/06/2011 10:45, Ivan Lazar Miljenovic wrote: On 7 June 2011 17:41, Guyguytsalmave...@yahoo.com wrote: On 06/06/2011 22:14, Evan Laforge wrote: Back to Haskell: I agree, the choice of the comment delimiter was not the best in light of the possibility to define operators containing it as a substring. But changing it to have --| start a comment too might break too much code (and eliminating -- as a comment starter would certainly break far too much code). I like that you have to put a space in for haddock comments. I originally posted because I found that --| stood out much more clearly as a structured comment than -- |. How does a missing space character make that stand out any more? :/ (Admittedly, I rely more on emacs using a different colour for Haddock comments than non-Haddock comments.) Try it without emacs :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cons of -XUndecidableInstances
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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comment Syntax
On 7 June 2011 17:50, Guy guytsalmave...@yahoo.com wrote: On 07/06/2011 10:45, Ivan Lazar Miljenovic wrote: On 7 June 2011 17:41, Guyguytsalmave...@yahoo.com wrote: I originally posted because I found that --| stood out much more clearly as a structured comment than -- |. How does a missing space character make that stand out any more? :/ (Admittedly, I rely more on emacs using a different colour for Haddock comments than non-Haddock comments.) Try it without emacs :-) I've also read un-highlighted Haskell code; I don't see --| standing out any more than -- | does. My guess is that you just get used to it... Another argument against special-casing --|: what happens if you want to use a _different_ documentation generator (I don't know why you would, but someone might) than Haddock, which uses a different markup identifier? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] cap 3: stopping thread 3 (stackoverflow)
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) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cap 3: stopping thread 3 (stackoverflow)
I don't think a stack overflow event indicates an RTS bug. Stack overflow events usually result in the RTS trying to adjust the stack size, and only if that fails, the program is halted. (... and why can't I copy/paste the text from threadscope's output window) As a workaround, you can use the show-ghc-events binary that is provided by the ghc-events package. Cheers, Andres ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Attoparsec concatenating combinator
2011/6/6 Bryan O'Sullivan b...@serpentine.com: On Sun, Jun 5, 2011 at 11:00 AM, Yitzchak Gale g...@sefer.org wrote: If behind the scenes the concat is copying directly from slices of the original input, then no, in principle we're not saving much then. I thought there were *two* copies going on. If you're using the specialised functions like attoparsec's takeWhile, then all they do is return a view into the underlying array. No copying occurs until the concat itself. Now that I think of it: in principle, you could write a specialised concat that would check the pointer/offset/length combinations of its arguments and, if they all abutted perfectly, would just return a new view into that same array, sans copying. (You'd have to hide it behind unsafePerformIO, of course.) Why would you need 'unsafePerformIO'. You can scrutinise the 'PS' constructors of the slice without dropping down to IO. The required 'Eq' instance on 'ForeignPtr' is also present. Using a Builder for concatentation makes sense, if you want to exploit that copying a slice of the input array is cheaper right after it has been inspected (its fully cached) than later (as it is done when collecting slices in a list). However, you can only have one Builder at a time and some low-level meddling is probably required to interleave the feeding of the Parser with input arrays with the feeding of the Builder with free buffers. Nevertheless, for something like parsing Chunked HTTP content it would make a lot of sense. I'm inclined look into that once I finished porting the blaze Builder to the 'bytestring' library. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cap 3: stopping thread 3 (stackoverflow)
As a workaround, you can use the show-ghc-events binary that is provided by the ghc-events package. Thanks, I wasn't aware of that. Are the following lines normal for an eventlog? ... 1877298000: cap 1: waking up thread 4 on cap 1 1877299000: cap 1: thread 4 is runnable 1877305000: cap 6: thread 4 is runnable 1877306000: cap 1: migrating thread 4 to cap 6 1877334000: cap 1: running thread 16 1877345000: cap 6: running thread 4 1877348000: cap 6: stopping thread 4 (thread finished) 1877428000: cap 3: stopping thread 14 (stack overflow) 1877428000: cap 3: running thread 14 1877501000: cap 1: stopping thread 16 (stack overflow) 1877503000: cap 1: running thread 16 1877606000: cap 3: stopping thread 14 (stack overflow) 1877607000: cap 3: running thread 14 1877658000: cap 1: stopping thread 16 (stack overflow) 1877659000: cap 1: running thread 16 1877723000: cap 4: stopping thread 10 (stack overflow) 1877724000: cap 4: running thread 10 1877769000: cap 3: stopping thread 14 (stack overflow) 18: cap 3: running thread 14 ... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maybe use advice
Is it necessary (helpful) to use 'rewrite'? Nearly every time I've tried it, in the end 'transform' has been a better choice. Then you wouldn't need the 'Just's at all, and it should work fine. John From: Lyndon Maydwell maydw...@gmail.com (missed including cafe) f :: [Modification] - Maybe [Modification] and f _ = Just $ f ... are incompatible I managed to get the behaviour I'm after with the use of Either, but this really is messy: -- Sets of changes o (Modifier (Changes []) i) = Just $ i o (Modifier (Changes [c]) i) = Just $ Modifier c i o (Modifier (Changes l) i) = g (f (Left l)) where g (Right l) = Just $ Modifier (Changes l) i g (Left l) = Nothing f (Left (Scale x y : Scale x' y' : l)) = f $ Right $ Scale (x*x') (y*y') : h (f $ Left l) f (Left (Translate x y : Translate x' y' : l)) = f $ Right $ Translate (x+x') (y+y') : h (f $ Left l) f (Left (Rotatex : Rotatex': l)) = f $ Right $ Rotate(x+x'): h (f $ Left l) f x = x h (Left l) = l h (Right l) = l On Tue, Jun 7, 2011 at 3:11 AM, Maciej Marcin Piechotka uzytkown...@gmail.com wrote: On Mon, 2011-06-06 at 23:38 +0800, Lyndon Maydwell wrote: I'm writing an optimisation routine using Uniplate. Unfortunately, a sub-function I'm writing is getting caught in an infinite loop because it doesn't return Nothing when there are no optimisations left. I'd like a way to move the last Just into f, but this makes recursion very messy. I was wondering if there was a nice way to use something like the Monad or Applicative instance to help here. -- Sets of changes o (Modifier (Changes []) ?i) = Just $ i o (Modifier (Changes [c]) i) = Just $ Modifier c i o (Modifier (Changes l) ? i) = Just $ Modifier (Changes (f l)) i ? where ? ? f (Scale ? ? x y : Scale ? ? x' y' : l) = f $ Scale ? ? (x*x') (y*y') : f l ? ? f (Translate x y : Translate x' y' : l) = f $ Translate (x+x') (y+y') : f l ? ? f (Rotate ? ?x ? : Rotate ? ?x' ? ?: l) = f $ Rotate ? ?(x+x') ? ? ? ?: f l ? ? f l = l Any ideas? Something like: ... f (Rotate ? ?x ? : Rotate ? ?x' ? ?: l) ? ?= Just $ f (Rotate (x+x') : fromMaybe l (f l)) f l = Nothing -- As far as I understend Regards ___ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maybe use advice
The fixpoint nature of rewrite catches some cases that transform might not if I'm interpreting it correctly. (Changes [Translate 1 1, Scale 1 1, Translate 1 1]) could be rewritten as (Translate 2 2), but I'm not sure that it could be translated as such if it matches against (Changes [Translate _ _, Translate _ _]) first. I have the code on github at https://github.com/sordina/Diagrams-AST/blob/master/src/Graphics/Rendering/Diagrams/AST/Optimize.hs if you're interested. At the moment I'm not worrying about speed as I really just wrote this optimisation function as a demo of why an AST interface to Diagrams might be useful. On Tue, Jun 7, 2011 at 5:06 PM, John Lato jwl...@gmail.com wrote: Is it necessary (helpful) to use 'rewrite'? Nearly every time I've tried it, in the end 'transform' has been a better choice. Then you wouldn't need the 'Just's at all, and it should work fine. John From: Lyndon Maydwell maydw...@gmail.com (missed including cafe) f :: [Modification] - Maybe [Modification] and f _ = Just $ f ... are incompatible I managed to get the behaviour I'm after with the use of Either, but this really is messy: -- Sets of changes o (Modifier (Changes []) i) = Just $ i o (Modifier (Changes [c]) i) = Just $ Modifier c i o (Modifier (Changes l) i) = g (f (Left l)) where g (Right l) = Just $ Modifier (Changes l) i g (Left l) = Nothing f (Left (Scale x y : Scale x' y' : l)) = f $ Right $ Scale (x*x') (y*y') : h (f $ Left l) f (Left (Translate x y : Translate x' y' : l)) = f $ Right $ Translate (x+x') (y+y') : h (f $ Left l) f (Left (Rotate x : Rotate x' : l)) = f $ Right $ Rotate (x+x') : h (f $ Left l) f x = x h (Left l) = l h (Right l) = l On Tue, Jun 7, 2011 at 3:11 AM, Maciej Marcin Piechotka uzytkown...@gmail.com wrote: On Mon, 2011-06-06 at 23:38 +0800, Lyndon Maydwell wrote: I'm writing an optimisation routine using Uniplate. Unfortunately, a sub-function I'm writing is getting caught in an infinite loop because it doesn't return Nothing when there are no optimisations left. I'd like a way to move the last Just into f, but this makes recursion very messy. I was wondering if there was a nice way to use something like the Monad or Applicative instance to help here. -- Sets of changes o (Modifier (Changes []) ?i) = Just $ i o (Modifier (Changes [c]) i) = Just $ Modifier c i o (Modifier (Changes l) ? i) = Just $ Modifier (Changes (f l)) i ? where ? ? f (Scale ? ? x y : Scale ? ? x' y' : l) = f $ Scale ? ? (x*x') (y*y') : f l ? ? f (Translate x y : Translate x' y' : l) = f $ Translate (x+x') (y+y') : f l ? ? f (Rotate ? ?x ? : Rotate ? ?x' ? ?: l) = f $ Rotate ? ?(x+x') ? ? ? ?: f l ? ? f l = l Any ideas? Something like: ... f (Rotate ? ?x ? : Rotate ? ?x' ? ?: l) ? ?= Just $ f (Rotate (x+x') : fromMaybe l (f l)) f l = Nothing -- As far as I understend Regards ___ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comment Syntax
On 07/06/2011 10:55, Ivan Lazar Miljenovic wrote: On 7 June 2011 17:50, Guyguytsalmave...@yahoo.com wrote: On 07/06/2011 10:45, Ivan Lazar Miljenovic wrote: On 7 June 2011 17:41, Guyguytsalmave...@yahoo.comwrote: I originally posted because I found that --| stood out much more clearly as a structured comment than -- |. How does a missing space character make that stand out any more? :/ (Admittedly, I rely more on emacs using a different colour for Haddock comments than non-Haddock comments.) Try it without emacs :-) I've also read un-highlighted Haskell code; I don't see --| standing out any more than -- | does. My guess is that you just get used to it... Another argument against special-casing --|: what happens if you want to use a _different_ documentation generator (I don't know why you would, but someone might) than Haddock, which uses a different markup identifier? Out of interest, is there any other language where the comment delimiter is invalid if immediately followed by a symbol? Haskell seems to be parsing -- as if it was an operator (hence other legal lexemes could mean something else). Other languages say stop parsing here, so the comment delimiter can be followed by anything. (I could, of course, be completely wrong there.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comment Syntax
Guy guytsalmave...@yahoo.com writes: Out of interest, is there any other language where the comment delimiter is invalid if immediately followed by a symbol? Perl has a rather infamous example where the comment syntax may depend on run-time properties - would that count? whatever / 25 ; # / ; die this dies!; Depending on the definition of 'whatever', the # might introduce a comment - or it might not. Anyway, I think very few languages allow definition of new symbolic operators, so it's hard to make a useful comparison. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maybe use advice
If I'm interpreting your code properly, it's not currently catching that case anyway. The problem is that you've got two sets of modifiers that both should be optimized, explicit Modifier constructors in the Image, and a list contained in Changes. Since 'Changes' is just a list of Modifiers, and not an Image, neither rewrite nor transform will descend on it. You get around this by explicitly calling rewrite on the modifiers in 'deBlank', but then the rules from 'optimize' aren't applied. You can't really use the biplate functions either because they only match on a single element at a time. What you really want to do is be able to express each rule exactly once, which isn't possible in the current form of your code. One solution is to move a lot of the reductions of the form 'Modifier x' from 'optimize' into 'deBlank'. Then you would have something like this: deBlank :: [Modifier] - [Modifier] deBlank = db db (Scale 1 1 : l) = db l db (Rotate x : Rotate x' : l) = db (Rotate (x+x') : l) db (Scale x y : Scale x' y' : l) = db (Scale (x*x') (y*y') : l) db (Translate x y : Translate x' y' : l) = db (Translate (x+x') (y+y') : l) db xs = xs I actually don't think uniplate gets you anything in this particular function. Now deBlank will produce a list of modifiers which is as reduced as possible (at least by the rules you've provided), and you can use it within a two-pass optimize: optimize = transform o2 . transform o o (Modifier _ Blank) = Blank o (Modifier (Scale 0 _) _i) = Blank -- similar cases omitted o (Modifier m2 (Modifier m1 i)) = Modifier (m1 `mappend` m2) i o i@(Modifier (Changes _c) _i) = i o (Modifier m i) = Modifier (Changes [m]) i o i = i o2 (Modifier (Changes c) i) = case deBlank c of [] - i [x] - Modifier x i xs - Modifier (Changes c) i o2 i = i Transformations like Scale 0 _ have remained in the Image traversal, however all other modifications are combined into a single Changes list, which is then reduced by deBlank in the second pass. Note that in the first pass, even single modifications are encapsulated in a Changes; this makes the logic of the second pass much simpler because then all the reductions of multiple modifiers are located in the 'deBlank' function instead of split between there and 'o'. This presumes there's an appropriate Monoid instance for Modifiers, but if it doesn't exist it can be written easily enough. On second thought, I think it would be good to break it up even more, and keep the reductions of the form o (Modifier _ Blank) = Blank o (Modifier (Scale 0 _) _i) = Blank as a third pass, because it's possible some of them could get lost in this form. Then the first pass would just combine terms, the second would apply 'deBlank' and reduce, then the third would be as above. There are two alternatives which may be simpler: 1) Expand Changes c into explicit modifications and do all your reductions on the resulting Image. 2) Implement a general matrix transform for Diagrams and rewrite everything in terms of that. This would be useful for shear transforms anyway, which I believe are currently inexpressible in Diagrams. John Lato On Tue, Jun 7, 2011 at 10:12 AM, Lyndon Maydwell maydw...@gmail.com wrote: The fixpoint nature of rewrite catches some cases that transform might not if I'm interpreting it correctly. (Changes [Translate 1 1, Scale 1 1, Translate 1 1]) could be rewritten as (Translate 2 2), but I'm not sure that it could be translated as such if it matches against (Changes [Translate _ _, Translate _ _]) first. I have the code on github at https://github.com/sordina/Diagrams-AST/blob/master/src/Graphics/Rendering/Diagrams/AST/Optimize.hs if you're interested. At the moment I'm not worrying about speed as I really just wrote this optimisation function as a demo of why an AST interface to Diagrams might be useful. On Tue, Jun 7, 2011 at 5:06 PM, John Lato jwl...@gmail.com wrote: Is it necessary (helpful) to use 'rewrite'? Nearly every time I've tried it, in the end 'transform' has been a better choice. Then you wouldn't need the 'Just's at all, and it should work fine. John From: Lyndon Maydwell maydw...@gmail.com (missed including cafe) f :: [Modification] - Maybe [Modification] and f _ = Just $ f ... are incompatible I managed to get the behaviour I'm after with the use of Either, but this really is messy: -- Sets of changes o (Modifier (Changes []) i) = Just $ i o (Modifier (Changes [c]) i) = Just $ Modifier c i o (Modifier (Changes l) i) = g (f (Left l)) where g (Right l) = Just $ Modifier (Changes l) i g (Left l) = Nothing f (Left (Scale x y : Scale x' y' : l)) = f $ Right $ Scale (x*x') (y*y') : h (f $ Left l) f (Left (Translate x y : Translate x' y' : l)) = f $ Right $ Translate (x+x') (y+y') : h (f $ Left l) f (Left (Rotatex : Rotatex': l)) =
Re: [Haskell-cafe] Maybe use advice
I was considering using a matrix optimisation but things are out of control enough already :) Converting all Changes constructors to nested regular constructors may be the easiest approach. It would certainly eliminate the mess of list manipulations. On Tue, Jun 7, 2011 at 6:21 PM, John Lato jwl...@gmail.com wrote: If I'm interpreting your code properly, it's not currently catching that case anyway. The problem is that you've got two sets of modifiers that both should be optimized, explicit Modifier constructors in the Image, and a list contained in Changes. Since 'Changes' is just a list of Modifiers, and not an Image, neither rewrite nor transform will descend on it. You get around this by explicitly calling rewrite on the modifiers in 'deBlank', but then the rules from 'optimize' aren't applied. You can't really use the biplate functions either because they only match on a single element at a time. What you really want to do is be able to express each rule exactly once, which isn't possible in the current form of your code. One solution is to move a lot of the reductions of the form 'Modifier x' from 'optimize' into 'deBlank'. Then you would have something like this: deBlank :: [Modifier] - [Modifier] deBlank = db db (Scale 1 1 : l) = db l db (Rotate x : Rotate x' : l) = db (Rotate (x+x') : l) db (Scale x y : Scale x' y' : l) = db (Scale (x*x') (y*y') : l) db (Translate x y : Translate x' y' : l) = db (Translate (x+x') (y+y') : l) db xs = xs I actually don't think uniplate gets you anything in this particular function. Now deBlank will produce a list of modifiers which is as reduced as possible (at least by the rules you've provided), and you can use it within a two-pass optimize: optimize = transform o2 . transform o o (Modifier _ Blank) = Blank o (Modifier (Scale 0 _) _i) = Blank -- similar cases omitted o (Modifier m2 (Modifier m1 i)) = Modifier (m1 `mappend` m2) i o i@(Modifier (Changes _c) _i) = i o (Modifier m i) = Modifier (Changes [m]) i o i = i o2 (Modifier (Changes c) i) = case deBlank c of [] - i [x] - Modifier x i xs - Modifier (Changes c) i o2 i = i Transformations like Scale 0 _ have remained in the Image traversal, however all other modifications are combined into a single Changes list, which is then reduced by deBlank in the second pass. Note that in the first pass, even single modifications are encapsulated in a Changes; this makes the logic of the second pass much simpler because then all the reductions of multiple modifiers are located in the 'deBlank' function instead of split between there and 'o'. This presumes there's an appropriate Monoid instance for Modifiers, but if it doesn't exist it can be written easily enough. On second thought, I think it would be good to break it up even more, and keep the reductions of the form o (Modifier _ Blank) = Blank o (Modifier (Scale 0 _) _i) = Blank as a third pass, because it's possible some of them could get lost in this form. Then the first pass would just combine terms, the second would apply 'deBlank' and reduce, then the third would be as above. There are two alternatives which may be simpler: 1) Expand Changes c into explicit modifications and do all your reductions on the resulting Image. 2) Implement a general matrix transform for Diagrams and rewrite everything in terms of that. This would be useful for shear transforms anyway, which I believe are currently inexpressible in Diagrams. John Lato On Tue, Jun 7, 2011 at 10:12 AM, Lyndon Maydwell maydw...@gmail.com wrote: The fixpoint nature of rewrite catches some cases that transform might not if I'm interpreting it correctly. (Changes [Translate 1 1, Scale 1 1, Translate 1 1]) could be rewritten as (Translate 2 2), but I'm not sure that it could be translated as such if it matches against (Changes [Translate _ _, Translate _ _]) first. I have the code on github at https://github.com/sordina/Diagrams-AST/blob/master/src/Graphics/Rendering/Diagrams/AST/Optimize.hs if you're interested. At the moment I'm not worrying about speed as I really just wrote this optimisation function as a demo of why an AST interface to Diagrams might be useful. On Tue, Jun 7, 2011 at 5:06 PM, John Lato jwl...@gmail.com wrote: Is it necessary (helpful) to use 'rewrite'? Nearly every time I've tried it, in the end 'transform' has been a better choice. Then you wouldn't need the 'Just's at all, and it should work fine. John From: Lyndon Maydwell maydw...@gmail.com (missed including cafe) f :: [Modification] - Maybe [Modification] and f _ = Just $ f ... are incompatible I managed to get the behaviour I'm after with the use of Either, but this really is messy: -- Sets of changes o (Modifier (Changes []) i) = Just $ i o (Modifier (Changes [c]) i) = Just $ Modifier c i o (Modifier (Changes l) i) = g (f (Left l)) where g (Right l) = Just
Re: [Haskell-cafe] haskell platform question
It should build. If it doesn't, please report a bug. On Tue, Jun 7, 2011 at 8:53 AM, Tim Docker t...@dockerz.net wrote: I'd like to build the haskell platform against a recent GHC snapshot, for testing purposes. I see that I can download the source for the platform from: http://lambda.galois.com/hp-tmp/2011.2.0.1/haskell-platform-2011.2.0.1.tar.gz with instructions: http://www.vex.net/~trebla/haskell/haskell-platform.xhtml However when I tried this some months ago, I found that some of the packages in the above source fail to build due to recent ghc changes (eg it's stricter handling of bang patterns). Is there a more recent beta snapshot of the platform? Or a darcs/git repo somewhere? I imagine wanting to build the platform against bleeding edge ghc would be a pretty common desire. Tim ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell platform question
Oh, sorry, missed the first line. Building against GHC snapshots isn't supported. On Tue, Jun 7, 2011 at 6:48 AM, Don Stewart don...@gmail.com wrote: It should build. If it doesn't, please report a bug. On Tue, Jun 7, 2011 at 8:53 AM, Tim Docker t...@dockerz.net wrote: I'd like to build the haskell platform against a recent GHC snapshot, for testing purposes. I see that I can download the source for the platform from: http://lambda.galois.com/hp-tmp/2011.2.0.1/haskell-platform-2011.2.0.1.tar.gz with instructions: http://www.vex.net/~trebla/haskell/haskell-platform.xhtml However when I tried this some months ago, I found that some of the packages in the above source fail to build due to recent ghc changes (eg it's stricter handling of bang patterns). Is there a more recent beta snapshot of the platform? Or a darcs/git repo somewhere? I imagine wanting to build the platform against bleeding edge ghc would be a pretty common desire. Tim ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Twidge and lsfollowers --all
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? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Distributing Haskell GUI apps for Windows/MacOS?
Hello, I've implemented a Haskell program to play a modern board game. I've put it on Hackage (http://hackage.haskell.org/package/hstzaar) but would also like to distribute to people without the Haskell development tools. Are there any easy ways of making installers for Windows/MacOS (preferably using free or open source tools)? Best regards, Pedro ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Distributing Haskell GUI apps for Windows/MacOS?
There is bamse [1], but it's last been updated in 2009, and has build-failures for 6.10, 6.12 and 7.0. It has some dependency weirdness, like wanting both base = 4 and 4. I don't know how difficult it would be to upgrade it to modern haskell, but I'm sure the changes would be appreciated. [1] http://hackage.haskell.org/package/bamse -- Mats Rauhala MasseR pgpbVRfuirO3s.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Distributing Haskell GUI apps for Windows/MacOS?
On Tue, Jun 07, 2011 at 11:58:52 +0100, Pedro Vasconcelos wrote: Are there any easy ways of making installers for Windows/MacOS (preferably using free or open source tools)? On MacOS X, applications typically do not come with installers. Instead you have some kind of disk image (a tarball will do, but it's customary to create .dmg files) containing an application bundle (ie. directory) which users mv to a directory of their choice. In GUI terms, this consists in dragging and dropping the icon into your Applications folder. To create an application bundle, try Andy Gimblett's cabal-macosx https://github.com/gimbo/cabal-macosx Maybe cabal-macosx could come with a dmg helper. I just use a shell script which I can fish out later if you want. Note that this was originally created for wxhaskell projects [1], but I believe it should also be applicable to other GUI libraries. Hope this helps, Eric [1] http://sourceforge.net/mailarchive/message.php?msg_id=24625975 -- Eric Kow http://erickow.com signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell platform question
On 7 June 2011 21:34, Tim Docker t...@dockerz.net wrote: Surely wanting to test against a ghc snapshot isn't that odd? How do others go about testing their code with many hackage dependencies against a new ghc? I would have expected that the first thing to do would be get the platform up and running. Since the platform never uses the fist in a new major series of GHC, for non-boot libraries the process is that the first new major release of GHC comes out, code gets developed against that, then it's ready for the next release of the Platform. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Attoparsec concatenating combinator
Bryan O'Sullivan wrote: Now that I think of it: in principle, you could write a specialised concat that would check the pointer/offset/length combinations of its arguments and, if they all abutted perfectly, would just return a new view into that same array, sans copying. Gregory Collins wrote: The blaze-builder might work for this also, this is exactly the problem it's designed for. Simon Meier wrote: Using a Builder for concatentation makes sense... However, ...some low-level meddling is probably required... I'm inclined look into that... These are great ideas for further exploiting the bytestring/text specialization of this parser library for super speed. Thanks! Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: remove Stability from haddock documentation on hackage
On Jun 6, 2011, at 10:57 PM, Chris Smith wrote: I got asked a question today about why Control.Applicative is labeled as experimental on Hackage. Perhaps that field is something of a failed experiment, and it remaining there is likely to confuse people. Just a thought... not sure of the best place to mention it. As far as Control.Applicative, I'm not sure to what package you're referring. That label doesn't apply to modules, it applies to packages, and Control.Applicative is a part of the base package (which is not labeled experimental). Regarding the Stability field itself, I strongly believe in it. I like to know whether code I'm thinking about using is likely to have 15 new versions in the next month or whether its interface is likely to change drastically with the next release. When releasing packages I also like to be able to state that it's a work in progress and that I decline to promise forward compatibility. If I release a package labeled experimental, I don't feel nearly as bad making major API changes because any users that might have picked it up have had fair warning. On the other hand, if I've marked it stable or even provisional, I know I need to make a stronger effort to preserve source-level compatibility. It's good, in my opinion, to be able to state succinctly in a standardized way that, although it does something now, what the code does and how it does it are probably going to change in the future. The name of the field could be better, though. On first exposure, people tend to think stability: experimental or stability: unstable means the package is likely to crash (For those who don't know, it means the API is likely to change in future releases). -- James ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cap 3: stopping thread 3 (stackoverflow)
Here's source and logs: http://www.imn.htwk-leipzig.de/~waldmann/draft/skpp11/subseqsum/Subseqsum.hs The program is meant to show an application of the third homomorphism theorem approach (hom-based structural parallel programming). My observation (for this program) is that there is little speedup, indeed the threadscope picture shows a peak only at the very end, but the eventlog contains surprising (for me) stack and heap overflows. Would this work better with Data.Sequence instead of List? (Is there a really cheap way (O(1)) to split some Data.Sequence roughly in half?) PS: I keep telling my students that structural parallel programming is the right thing to do, but I find it surprisingly difficult to exhibit clear-cut examples that support the claim (and work with standard ghc, so students can reproduce it). I appreciate any comments. - J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: remove Stability from haddock documentation on hackage
Hi, James Cook wrote: As far as Control.Applicative, I'm not sure to what package you're referring. That label doesn't apply to modules, it applies to packages, and Control.Applicative is a part of the base package (which is not labeled experimental). On http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Applicative.html, in the upper right corner, the module is marked as experimental. I think this is a Haddock feature, not a Hackage feature. Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: remove Stability from haddock documentation on hackage
On Jun 7, 2011, at 9:22 AM, Tillmann Rendel wrote: Hi, James Cook wrote: As far as Control.Applicative, I'm not sure to what package you're referring. That label doesn't apply to modules, it applies to packages, and Control.Applicative is a part of the base package (which is not labeled experimental). On http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Applicative.html , in the upper right corner, the module is marked as experimental. I think this is a Haddock feature, not a Hackage feature. Ah, I did not realize it did that. Looking at the source I see that it is indeed in a haddock comment. In that case, I'll go back and respond to the original question. I do not know why it's labeled experimental, but would hazard a wild guess that it's because the relation of Applicative to Monad is still an open question. -- James ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: remove Stability from haddock documentation on hackage
On Tue, Jun 7, 2011 at 9:22 AM, Tillmann Rendel ren...@informatik.uni-marburg.de wrote: On http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Applicative.html, in the upper right corner, the module is marked as experimental. I think this is a Haddock feature, not a Hackage feature. Oddly, I couldn't find any of the fields in the haddock module header documented anywhere, though I didn't perform a very thorough search. I also observe that, in base, Data.Bool is apparently experimental, whereas Control.Monad is merely provisional. Prelude, at least, is reassuringly stable. - C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: remove Stability from haddock documentation on hackage
On Tue, Jun 7, 2011 at 3:05 PM, James Cook mo...@deepbondi.net wrote: On Jun 6, 2011, at 10:57 PM, Chris Smith wrote: I got asked a question today about why Control.Applicative is labeled as experimental on Hackage. Perhaps that field is something of a failed experiment, and it remaining there is likely to confuse people. Just a thought... not sure of the best place to mention it. As far as Control.Applicative, I'm not sure to what package you're referring. That label doesn't apply to modules, it applies to packages, and Control.Applicative is a part of the base package (which is not labeled experimental). Regarding the Stability field itself, I strongly believe in it. I like to know whether code I'm thinking about using is likely to have 15 new versions in the next month or whether its interface is likely to change drastically with the next release. When releasing packages I also like to be able to state that it's a work in progress and that I decline to promise forward compatibility. If I release a package labeled experimental, I don't feel nearly as bad making major API changes because any users that might have picked it up have had fair warning. On the other hand, if I've marked it stable or even provisional, I know I need to make a stronger effort to preserve source-level compatibility. It's good, in my opinion, to be able to state succinctly in a standardized way that, although it does something now, what the code does and how it does it are probably going to change in the future. The name of the field could be better, though. On first exposure, people tend to think stability: experimental or stability: unstable means the package is likely to crash (For those who don't know, it means the API is likely to change in future releases). A straightforward option then would be API stability. -- James ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Work is punishment for failing to procrastinate effectively. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: remove Stability from haddock documentation on hackage
On 7 June 2011 15:05, James Cook mo...@deepbondi.net wrote: It's good, in my opinion, to be able to state succinctly in a standardized way that, although it does something now, what the code does and how it does it are probably going to change in the future. I think no one really updates this field and it's a human factor that could otherwise be generated by Hackage reliably. I'm using many packages that are experimental or unstable that've been stable for a year or more. The field is mostly useless to me. The stability of a package can be judged based on how often the versions bump up based on the PVP and/or the exports of the package change, that is something Hackage could trivially do. Agreed, the naming is also ambiguous, “API stability” seems more straight-forward. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cap 3: stopping thread 3 (stackoverflow)
- Original Message - From: Johannes Waldmann waldm...@imn.htwk-leipzig.de Sent: Tuesday, June 7, 2011 8:22 AM Here's source and logs: http://www.imn.htwk-leipzig.de/~waldmann/draft/skpp11/subseqsum/Subseqsum.hs The program is meant to show an application of the third homomorphism theorem approach (hom-based structural parallel programming). My observation (for this program) is that there is little speedup, indeed the threadscope picture shows a peak only at the very end, but the eventlog contains surprising (for me) stack and heap overflows. Would this work better with Data.Sequence instead of List? (Is there a really cheap way (O(1)) to split some Data.Sequence roughly in half?) You can split a Sequence in O(log n) time, or a bit cheaper near the ends. I'd be surprised if you see any speedup with this code. The serial algorithm is already O(n), maintaining two counters, and with a lazily generated list it probably runs in constant memory. length and splitAt are already O(n), make two separate traversals, and require allocating memory for the entire list. Even if you have an efficiently splittable data structure, the parallel version of the code needs to keep four counts for each chunk, and do more on each update. Have you tried a version that splits the list into larger chunks, and uses the serial algorithm for computing the left, right, overall, and maximum sums of each chunk, before summing them together? PS: I keep telling my students that structural parallel programming is the right thing to do, but I find it surprisingly difficult to exhibit clear-cut examples that support the claim (and work with standard ghc, so students can reproduce it). I appreciate any comments. - J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: remove Stability from haddock documentation on hackage
On Jun 7, 2011, at 10:17 AM, Christopher Done wrote: On 7 June 2011 15:05, James Cook mo...@deepbondi.net wrote: It's good, in my opinion, to be able to state succinctly in a standardized way that, although it does something now, what the code does and how it does it are probably going to change in the future. I think no one really updates this field and it's a human factor that could otherwise be generated by Hackage reliably. I'm using many packages that are experimental or unstable that've been stable for a year or more. The field is mostly useless to me. The stability of a package can be judged based on how often the versions bump up based on the PVP and/or the exports of the package change, that is something Hackage could trivially do. Agreed, the naming is also ambiguous, “API stability” seems more straight-forward. I can't speak for anyone besides myself, but I do update it and its value is determined, for me, in a way that could never be automated. When I mark a package provisional or experimental, I am saying that I am not convinced that the API I've created is the best one I can come up with, and often I have specific plans to (when I get around to it) change it. It is an indication of intent for, not history of, change. Similarly, when I do reach a design that I'm satisfied with, I change the stability field. But an automated decision system has no conceivable way of knowing that the major change I just made will be the last major change. -- James ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Attoparsec concatenating combinator
On Tue, Jun 7, 2011 at 1:40 AM, Simon Meier iridc...@gmail.com wrote: Why would you need 'unsafePerformIO'. You can scrutinise the 'PS' constructors of the slice without dropping down to IO. True. Oops :-) Using a Builder for concatentation makes sense, if you want to exploit that copying a slice of the input array is cheaper right after it has been inspected (its fully cached) than later (as it is done when collecting slices in a list). When I've measured this in the past, I've found that it's often faster to accumulate a list and then run concat at the end than to use blaze-builder directly. That was certainly the case wit GHC 6.12; I haven't remeasured with 7.0. That's why you'll see that some places in the aeson JSON library use blaze-builder, while others manipulate bytestrings directly. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Library Versioning
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cons of -XUndecidableInstances
I wrote: You almost never want to use UndecidableInstances when writing practical programs in Haskell. When GHC tells you that you need them, it almost always means that your types are poorly designed, usually due to influence from previous experience with OOP. wren ng thornton wrote: That's a bit unfair. There are many kinds of type-level hackery which require UndecidableInstances but are (a) perfectly safe for practical use, and (b) have nothing to do with OOP. One particularly trivial example that comes to mind is: newtype Mu f = Mu (f (Mu f)) I agree. I've even used that one (well, something similar anyway). Oleg wrote: 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... That extension should not be categorically stigmatized. I'm sorry if I came across as giving it a bad rap, or stigmatizing it. That was certainly not my intention. There are plenty of excellent techniques that use this and other GHC extensions; accomplished Haskellers should have them in their toolbox. But I stand by my statement, which is coming from my perspective as a professional Haskell software developer, not a PL researcher. Perhaps I should clarify it though. I am making two claims: 1. In everyday practical Haskell programming, it is very unusual that a technique requiring direct use of UndecidableInstances is the right tool for the job. Of course, that observation is colored by my own experience, but I believe that it is generally true. 2. If a person is surprised by the GHC error suggesting that UndecidableInstances is needed and is struggling with understanding it, then it is almost certain that person has inappropriately used OOP thinking in trying to design a Haskell program. Experienced Haskellers familiar with those techniques do not get the error. Or they get it and say, Oops, forgot the UndecidableInstances. Whereas most programmers coming to Haskell have had OOP experience. The first thing that happens when they try to write a program in Haskell of any significant complexity is the UndecidableInstances error. It happened to me, too. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Library Versioning
On Jun 7, 2011, at 11:10 AM, Luis Cabellos wrote: 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 You can export things from one module that are defined in other modules. For example: module MyPackage ( version, ... ) import Paths_my_package( version ) ... -- James ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Mysterious complaint about .hi files
Hi cafe!
I'm hitting a very strange problem when using haskell-src-exts and
haskell-src-exts-qq. Consider the following module:
\begin{code}
{-# Language QuasiQuotes #-}
module TestBug where
import Language.Haskell.Exts
import Language.Haskell.Exts.QQ
unit = TyTuple Boxed []
ty = [dec| quux :: (a,b) |]
\end{code}
This module doesn't load for me using ghc 7.0.3. I've pasted the full error
message at the end of this email but the error message begins with the
following lines:
TestBug.hs:11:11:
Can't find interface-file declaration for variable
Language.Haskell.Exts.Syntax.Boxed
Probable cause: bug in .hi-boot file, or inconsistent .hi file
Use -ddump-if-trace to get an idea of which file caused the error
Using -ddump-if-trace didn't help me much.
The funny thing is that if I comment out the last line (the definition of
'ty') then the module loads just fine even though it uses the Boxed type in
the definition of 'unit'. So the problem only manifests itself when I use
tuples from haskell-src-exts-qq. Everything else that I've used from
haskell-src-exts-qq works fine, it's just when I try to use tuples that
things go haywire.
I've tried to remove the packages and reinstall them but it didn't help.
Any clues?
Josef
TestBug.hs:11:11:
Can't find interface-file declaration for variable
Language.Haskell.Exts.Syntax.Boxed
Probable cause: bug in .hi-boot file, or inconsistent .hi file
Use -ddump-if-trace to get an idea of which file caused the error
In the first argument of `Language.Haskell.Exts.Syntax.TyTuple', namely
`Language.Haskell.Exts.Syntax.Boxed'
In the third argument of `Language.Haskell.Exts.Syntax.TypeSig', namely
`Language.Haskell.Exts.Syntax.TyTuple
Language.Haskell.Exts.Syntax.Boxed
((:)
(Language.Haskell.Exts.Syntax.TyVar
(Language.Haskell.Exts.Syntax.Ident ((:) 'a' [])))
((:)
(Language.Haskell.Exts.Syntax.TyVar
(Language.Haskell.Exts.Syntax.Ident ((:) 'b' [])))
[]))'
In the expression:
Language.Haskell.Exts.Syntax.TypeSig
(SrcLoc
((:)
''
((:)
'u'
((:)
'n'
((:)
'k'
((:)
'n'
((:)
'o'
((:)
'w' ((:) 'n' ((:) '' ((:) '.' ((:) 'h' ((:)
's' []
1
2)
((:)
(Language.Haskell.Exts.Syntax.Ident
((:) 'q' ((:) 'u' ((:) 'u' ((:) 'x' [])
[])
(Language.Haskell.Exts.Syntax.TyTuple
Language.Haskell.Exts.Syntax.Boxed
((:)
(Language.Haskell.Exts.Syntax.TyVar
(Language.Haskell.Exts.Syntax.Ident ((:) 'a' [])))
((:)
(Language.Haskell.Exts.Syntax.TyVar
(Language.Haskell.Exts.Syntax.Ident ((:) 'b' [])))
[])))
Failed, modules loaded: none.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cons of -XUndecidableInstances
Personally, I came much less against UndecidableInstances when I was trying to do OOP in Haskell than when I was trying do Prolog-like things at the type level. Things like transitive relations: (If a type B contains an A, and if C contains B, then C contains A, and so on). I kind of abandonned quickly that way of reasoning ^^. 2011/6/7 Yitzchak Gale g...@sefer.org I wrote: You almost never want to use UndecidableInstances when writing practical programs in Haskell. When GHC tells you that you need them, it almost always means that your types are poorly designed, usually due to influence from previous experience with OOP. wren ng thornton wrote: That's a bit unfair. There are many kinds of type-level hackery which require UndecidableInstances but are (a) perfectly safe for practical use, and (b) have nothing to do with OOP. One particularly trivial example that comes to mind is: newtype Mu f = Mu (f (Mu f)) I agree. I've even used that one (well, something similar anyway). Oleg wrote: 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... That extension should not be categorically stigmatized. I'm sorry if I came across as giving it a bad rap, or stigmatizing it. That was certainly not my intention. There are plenty of excellent techniques that use this and other GHC extensions; accomplished Haskellers should have them in their toolbox. But I stand by my statement, which is coming from my perspective as a professional Haskell software developer, not a PL researcher. Perhaps I should clarify it though. I am making two claims: 1. In everyday practical Haskell programming, it is very unusual that a technique requiring direct use of UndecidableInstances is the right tool for the job. Of course, that observation is colored by my own experience, but I believe that it is generally true. 2. If a person is surprised by the GHC error suggesting that UndecidableInstances is needed and is struggling with understanding it, then it is almost certain that person has inappropriately used OOP thinking in trying to design a Haskell program. Experienced Haskellers familiar with those techniques do not get the error. Or they get it and say, Oops, forgot the UndecidableInstances. Whereas most programmers coming to Haskell have had OOP experience. The first thing that happens when they try to write a program in Haskell of any significant complexity is the UndecidableInstances error. It happened to me, too. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cap 3: stopping thread 3 (stackoverflow)
Hi,
On 07/06/11 14:22, Johannes Waldmann wrote:
Would this work better with Data.Sequence instead of List?
(Is there a really cheap way (O(1)) to split some Data.Sequence roughly in
half?)
I came up with this using immutable unboxed arrays, which gives a nice
parallel speedup (and somehow avoids the stack overflows, I didn't work
out where they were coming from unfortunately):
SPARKS: 1000268 (102821 converted, 0 pruned)
INIT time0.02s ( 0.02s elapsed)
MUT time0.90s ( 0.46s elapsed)
GCtime0.03s ( 0.03s elapsed)
EXIT time0.01s ( 0.04s elapsed)
Total time0.97s ( 0.53s elapsed)
%GC time 3.1% (5.8% elapsed)
Alloc rate586,961,335 bytes per MUT second
Productivity 94.4% of total user, 173.5% of total elapsed
on my dual-core laptop until around 1e6 elements when I compile with:
ghc -O2 -Wall --make -threaded -rtsopts -fforce-recomp Subseqsum.hs
and run with:
./Subseqsum 1e6 +RTS -N -s -M1G -A512M
but after that (eg: 1e7) the GC time dominates and it slows right down.
Note that I haven't tested it for correctness! So there may be bugs:
8
import Data.List (unfoldr)
import Control.Parallel (par, pseq)
import Data.Monoid (Monoid, mempty, mappend)
import Data.Array.Unboxed (UArray, listArray, (!))
import System.Environment (getArgs)
main :: IO ()
main = do
[ nn ] - getArgs
let n = read nn
xs = stuff
a = listArray (0, n - 1) xs
print . t $ sss 0 n a
stuff :: [Int]
stuff = unfoldr ( \ x - seq x $ Just ( x, mod (113 * x + 558) 335 - 167
) ) 0
data O = O { s :: ! Int, l :: !Int, r :: !Int , t :: !Int }
instance Monoid O where
mempty = O { s = 0, r = 0, l = 0, t = 0 }
o1 `mappend` o2 =
let s' = s o1 + s o2
r' = max (r o2) ( s o2 + r o1 )
l' = max (l o1) ( s o1 + l o2 )
t' = max (r o1 + l o2)
$ max ( t o1 ) ( t o2 )
in O { s = s', r = r', l = l', t = t' }
msingle :: Int - O
msingle x = O { s = x, r = max x 0, l = max x 0, t = max x 0}
sss :: Int - Int - UArray Int Int - O
sss lo hi a
| lo == hi = mempty
| lo + 1 == hi = msingle (a ! lo)
| otherwise =
let mid = (lo + hi) `div` 2
x = sss lo mid a
y = sss mid hi a
in x `par` y `pseq` (x `mappend` y)
8
PS: I keep telling my students that structural parallel programming
I don't know that term, so I might be missing the point. Sorry if so.
Thanks,
Claude
--
http://claudiusmaximus.goto10.org
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comment Syntax
On 07/06/2011 10:55, Ivan Lazar Miljenovic wrote: Another argument against special-casing --|: what happens if you want to use a _different_ documentation generator (I don't know why you would, but someone might) than Haddock, which uses a different markup identifier? We can declare new operators - why not new comment delimiters? That way Haddock could define --| and --^, other generators could declare whatever they wanted. The downside of this is that Haddock would have to be imported into every file which uses the markup. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cap 3: stopping thread 3 (stackoverflow)
GHC starts threads with a small stack size to efficiently support lightweight concurrency. As a thread uses more stack space, it will be expanded as needed up to some maximum fixed size. I think these stack overflow events you see are the runtime expanding the thread stacks. You can adjust the initial and maximum stack sizes using the -k (initial) and -K (max) RTS options. Quoting from the GHC users guide (http://www.haskell.org/ghc/docs/7.0-latest/html/users_guide/runtime-control.html#setting-rts-options): -ksize [Default: 1k] Set the initial stack size for new threads. Thread stacks (including the main thread's stack) live on the heap, and grow as required. The default value is good for concurrent applications with lots of small threads; if your program doesn't fit this model then increasing this option may help performance. The main thread is normally started with a slightly larger heap to cut down on unnecessary stack growth while the program is starting up. -Ksize [Default: 8M] Set the maximum stack size for an individual thread to size bytes. This option is there purely to stop the program eating up all the available memory in the machine if it gets into an infinite loop. On Jun 7, 2011, at 3:55 AM, Johannes Waldmann wrote: As a workaround, you can use the show-ghc-events binary that is provided by the ghc-events package. Thanks, I wasn't aware of that. Are the following lines normal for an eventlog? ... 1877298000: cap 1: waking up thread 4 on cap 1 1877299000: cap 1: thread 4 is runnable 1877305000: cap 6: thread 4 is runnable 1877306000: cap 1: migrating thread 4 to cap 6 1877334000: cap 1: running thread 16 1877345000: cap 6: running thread 4 1877348000: cap 6: stopping thread 4 (thread finished) 1877428000: cap 3: stopping thread 14 (stack overflow) 1877428000: cap 3: running thread 14 1877501000: cap 1: stopping thread 16 (stack overflow) 1877503000: cap 1: running thread 16 1877606000: cap 3: stopping thread 14 (stack overflow) 1877607000: cap 3: running thread 14 1877658000: cap 1: stopping thread 16 (stack overflow) 1877659000: cap 1: running thread 16 1877723000: cap 4: stopping thread 10 (stack overflow) 1877724000: cap 4: running thread 10 1877769000: cap 3: stopping thread 14 (stack overflow) 18: cap 3: running thread 14 ... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can it be proven there are no intermediate useful type classes between Applicative Functors Monads?
On Sun, Jun 5, 2011 at 12:51 PM, KC kc1...@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/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can it be proven there are no intermediate useful type classes between Applicative Functors Monads?
On Mon, Jun 6, 2011 at 4:05 PM, Casey McCann syntaxgli...@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/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Library Versioning
You can export things from one module that are defined in other modules. For example: module MyPackage ( version, ... ) import Paths_my_package( version ) ... Yes indeed, but I getting ugly errors (undefined references to version I think) when use Paths_my_package from library, and i don't know a better fix: /home/cabellos/.cabal/lib/skema-server-0.1.0/ghc-6.12.3/libHSskema-server-0.1.0.a(Main.o): In function `r4HU_info': (.text+0x3ef9): undefined reference to `skemazmserverzm0zi1zi0_Pathszuskemazuserver_version1_closure' /home/cabellos/.cabal/lib/skema-server-0.1.0/ghc-6.12.3/libHSskema-server-0.1.0.a(Main.o): In function `s5TE_info': (.text+0x8e03): undefined reference to `__stginit_skemazmserverzm0zi1zi0_Pathszuskemazuserver_' Also, I'm using Dyre, It's possible that recompile proccess of dyre cause the error. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cons of -XUndecidableInstances
I wrote: type Model a = (Ord a) = Set a -- the set of lexemes - [a] -- the original text to model - [a] -- list of previous lexemes - ProbDist a -- the next lexeme and then entropy :: Model a - Set a - [a] - Double On Mon, Jun 6, 2011 at 03:56, Yitzchak Gale g...@sefer.org wrote: If further down the line you need to write a function that is independent of the model, the types of its arguments will show you what you need to do. Is there a trick that I'm missing? If I want (as a horribly constructed hypothetical example) to write a function later on with type (Model a - Model b) that calls 'entropy' (no idea why), but I want to use the specialized version of 'entropy' for 'Markov' (which requires data that isn't even contained in the first argument, which is really just a function), I don't see any way to do it, without having two entirely different code paths for 'Markov' and other models, starting from the point of decision (user input or some other factor) - an unwieldy solution in case of more than 2 different models (each, presumably, with their own subset of specializations). -- Scott Lawrence ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cons of -XUndecidableInstances
One particularly trivial example that comes to mind is:
newtype Mu f = Mu (f (Mu f))
instance Show (f (Mu f)) = Show (Mu f) where
show (Mu x) = Mu ( ++ show x ++ )
-- Or however you'd like to show it
Ehm, that does look like poor design.
Sure you don't mean Mu f can be printed if and only if f (Mu f) can be
printed. What you probably mean is if f transforms printable things to
printable things, then Mu f is a printable thing. And you CAN express just
that:
type ShowD a = forall p. (forall x. Show x = p x) - p a
showD :: Show a = ShowD a
showD px = px
class ShowF f where showF :: Show a = ShowD (f a)
instance Show a = Show (F a) where... -- here goes your f
instance ShowF F where showF = showD -- and that is the only line of boilerplate
instance ShowF f = Show (Mu f) where
show (Mu fm) = Mu ( ++ runShowHelper (showF (ShowHelper show)) fm ++ )
newtype ShowHelper x = ShowHelper {runShowHelper :: x - String}
Sorry for possible bugs — I don't have ghc anywhere near me at the moment, but
the idea is clear, I guess.
Отправлено с iPhone
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Library Versioning
On Jun 7, 2011, at 12:28 PM, Luis Cabellos wrote: You can export things from one module that are defined in other modules. For example: module MyPackage ( version, ... ) import Paths_my_package( version ) ... Yes indeed, but I getting ugly errors (undefined references to version I think) when use Paths_my_package from library, and i don't know a better fix: /home/cabellos/.cabal/lib/skema-server-0.1.0/ghc-6.12.3/libHSskema- server-0.1.0.a(Main.o): In function `r4HU_info': (.text+0x3ef9): undefined reference to `skemazmserverzm0zi1zi0_Pathszuskemazuserver_version1_closure' /home/cabellos/.cabal/lib/skema-server-0.1.0/ghc-6.12.3/libHSskema- server-0.1.0.a(Main.o): In function `s5TE_info': (.text+0x8e03): undefined reference to `__stginit_skemazmserverzm0zi1zi0_Pathszuskemazuserver_' Also, I'm using Dyre, It's possible that recompile proccess of dyre cause the error. Did you tell cabal that Paths_my_package is a part of your library? If it is referenced by your code, then it should be listed in either exposed-modules or other-modules, otherwise it won't be installed. I've never used dyre so I don't know whether it would cause any issues, but I suspect not. -- James ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can it be proven there are no intermediate useful type classes between Applicative Functors Monads?
On Tue, Jun 7, 2011 at 6:14 AM, Casey McCann syntaxgli...@gmail.com wrote: On Mon, Jun 6, 2011 at 7:55 PM, David Barbour dmbarb...@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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Library Versioning
Did you tell cabal that Paths_my_package is a part of your library? If it is referenced by your code, then it should be listed in either exposed-modules or other-modules, otherwise it won't be installed. I've never used dyre so I don't know whether it would cause any issues, but I suspect not. Thank's a lot, the use of other-models fix my problem! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cons of -XUndecidableInstances
On Jun 7, 2011, at 12:43 PM, MigMit wrote:
One particularly trivial example that comes to mind is:
newtype Mu f = Mu (f (Mu f))
instance Show (f (Mu f)) = Show (Mu f) where
show (Mu x) = Mu ( ++ show x ++ )
-- Or however you'd like to show it
Ehm, that does look like poor design.
Sure you don't mean Mu f can be printed if and only if f (Mu f) can
be printed. What you probably mean is if f transforms printable
things to printable things, then Mu f is a printable thing. And you
CAN express just that:
Actually, I would argue that the former _is_ what is meant. It's a
weaker condition than the latter and it is the necessary and
sufficient condition to define the instance - one of the steps
involved in formatting a value of type Mu f is to format a value of
type f (Mu f). It doesn't actually matter whether forall x. Show x
= Show (f x) holds in general.
type ShowD a = forall p. (forall x. Show x = p x) - p a
showD :: Show a = ShowD a
showD px = px
class ShowF f where showF :: Show a = ShowD (f a)
instance Show a = Show (F a) where... -- here goes your f
instance ShowF F where showF = showD -- and that is the only line of
boilerplate
instance ShowF f = Show (Mu f) where
show (Mu fm) = Mu ( ++ runShowHelper (showF (ShowHelper show)) fm
++ )
newtype ShowHelper x = ShowHelper {runShowHelper :: x - String}
Sorry for possible bugs — I don't have ghc anywhere near me at the
moment, but the idea is clear, I guess.
I don't really see how this is preferable when the compiler can solve
the equation automatically. All that is needed is to tell it to try.
If portability is a concern then I could see going through the
gymnastics (and also eliminating the use of higher-rank types), but
that's the only case in which I would consider it the preferred option.
-- James
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: remove Stability from haddock documentation on hackage
I like the goal of the stability field, but I don't know how to use it. Is it intended to track a package's overall maturity ? Eg: experimental - alpha - beta - almost ready - stable - mature - obsolete Or, since many packages have multiple major and minor releases, to track the current release status ? Eg: experimental - alpha - beta - stable - alpha - beta - ... Currently, I expect every package author follows their own wording and usage, or ignores it, so it's hard to rely on. So good idea to discuss it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cap 3: stopping thread 3 (stackoverflow)
I came up with this using immutable unboxed arrays [...]
sss :: Int - Int - UArray Int Int - O
Nice. - Although what you do here is actually C programming:
you have a global array, and work on its indices.
Actually you always have a pair of indices, denoting a subsequence.
It would be nice if the program text showed this directly, using
data Seq a = Seq
{ contents :: ! ( Array Int a )
, lo :: ! Int, hi :: ! Int
}
and then all (well, most) of the methods in Data.Sequence,
implemented in such a way that the contents is just copied around, e.g.,
splitAt :: Int - Seq a - ( Seq a, Seq a )
splitAt k s = ( s { hi = lo s + k - 1 } , s { lo = lo s + k } )
and then a Foldable instance,
and then ... specializations for the types that
are allowed as elements of an unboxed array.
(and that's the part that does not seem to be working easily.
Can this be done by some specialize/rules magic in GHC?)
PS: I keep telling my students that structural parallel programming
I don't know that term, so I might be missing the point. Sorry if so.
Your code is fine. - Some pointers are here:
http://www.iis.sinica.edu.tw/~scm/2008/constructing-list-homomorphism/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Haskell Platform natively for 64bit Windows
On 06/06/2011 09:34 PM, Nicu Ionita wrote: Hi, Just to double check: that means, today it's not possible to generate 64 bit operations under Windows, including bit level .., .|. a.s.o. (from Data.Bits), and this situation will stay like this for a while. I'm asking this because I'm currently writing a pure Haskell chess engine based on bitboards. The bitboards are 64 bit wide and the basic operations are critical for speed, which is always critical in chess engines. Then it looks I'll have to implement these operations in C and use FFI to link them. No, 64-bit integer operations will /work/ just fine, regardless of what platform you're on. Whether it will take advantage of 64-bit operations at the machine-code level is another matter entirely. I'm not especially sure, but I think even in 32-bit mode, the x86 line of processors supports performing 64-bit operations via MMX, SSE or similar. Whether GHC is using that, I couldn't tell you. I suppose the ultimate answer is: Benchmark it, and see how fast it is. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] SIGPLAN Programming Languages Software Award
I'm pleased to be able to relay the following announcement from ACM SIGPLAN: The SIGPLAN Programming Languages Software Award is awarded to an institution or individual(s) to recognize the development a software system that has had a significant impact on programming language research, implementations, and tools. The impact may be reflected in the wide-spread adoption of the system or its underlying concepts by the wider programming language community either in research projects, in the open-source community, or commercially. The award includes a prize of $2,500. For 2011, the winners of the award are Simon Peyton Jones and Simon Marlow of Microsoft Research, Cambridge, for GHC The award winners are donating the entirety of the prize money to haskell.org. Citation: Simon Peyton Jones and Simon Marlow receive the SIGPLAN Software Award as the authors of the Glasgow Haskell Compiler (GHC), which is the preeminent lazy functional programming system for industry, teaching, and research. GHC has not only provided a language implementation, but also established the whole paradigm of lazy functional programming and formed the foundation of a large and enthusiastic user community. GHC's flexibility has supported experimental research on programming language design in areas as diverse as monads, generalized algebraic data types, rank-N polymorphism, and software transactional memory. Indeed, a large share of the research on lazy functional programming in the last 5–10 years has been carried out with GHC. Simultaneously, GHC's reliability and efficiency has encouraged commercial adoption, in the financial sector in institutions like Credit Suisse and Standard Chartered Bank, and for high assurance software in companies like Amgen, Eaton, and Galois. A measure of GHC's influence is the way that many of the ideas of purely functional, typeful programming have been carried into newer languages and language features. including C#, F#, Java Generics, LINQ, Perl 6, Python, and Visual Basic 9.0. Peyton Jones and Marlow have been visionary in the way that they have transitioned research into practice. They have been role models and leaders in creating the large and diverse Haskell community, and have made GHC an industrial-strength platform for commercial development as well as for research. Links: http://www.sigplan.org/award-software.htm http://corp.galois.com/blog/2011/6/7/sigplan-programming-languages-software-award.html smime.p7s Description: S/MIME Cryptographic Signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Haskell Platform natively for 64bit Windows
Am 07.06.2011 19:37, schrieb Andrew Coppin: On 06/06/2011 09:34 PM, Nicu Ionita wrote: Hi, Just to double check: that means, today it's not possible to generate 64 bit operations under Windows, including bit level .., .|. a.s.o. (from Data.Bits), and this situation will stay like this for a while. I'm asking this because I'm currently writing a pure Haskell chess engine based on bitboards. The bitboards are 64 bit wide and the basic operations are critical for speed, which is always critical in chess engines. Then it looks I'll have to implement these operations in C and use FFI to link them. No, 64-bit integer operations will /work/ just fine, regardless of what platform you're on. Whether it will take advantage of 64-bit operations at the machine-code level is another matter entirely. I'm not especially sure, but I think even in 32-bit mode, the x86 line of processors supports performing 64-bit operations via MMX, SSE or similar. Whether GHC is using that, I couldn't tell you. I suppose the ultimate answer is: Benchmark it, and see how fast it is. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Yes, I was a little bit unclear, I wanted to say: the generated code does not use the 64 bit instructions (i.e. 1 instruction for .., for example). Of course, it works, but I suppose, much slower then it could (3-4 times, for that part?) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell platform question
On Tue, Jun 7, 2011 at 07:34, Tim Docker t...@dockerz.net wrote: On 07/06/2011, at 8:48 PM, Don Stewart wrote: Oh, sorry, missed the first line. Building against GHC snapshots isn't supported. Surely wanting to test against a ghc snapshot isn't that odd? How The point of the Haskell Platform is to provide a tested, stable configuration. While testing against newer versions is in some sense good, it is fully expected to require tweaking. The HP *is* the box; change anything and you are outside the box and nothing is guaranteed. do others go about testing their code with many hackage dependencies against a new ghc? I would have expected that the first thing to do would be get the We don't, for the most part; ghc is a quickly moving target and usually has multiple type theory experiments going on in its code, and it's best to avoid new versions until they stabilize and any core dependents are updated. GHC announcements will often mention how usable the release is expected to be for us non-type theorists. Unless you're a ghc hacker, you shouldn't in general rush into a new ghc version. (This isn't Linux. The bleeding edge is for type theory, not geeks.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Twidge and lsfollowers --all
On Tue, Jun 7, 2011 at 06:57, Keith Edmunds k...@midnighthax.com wrote: 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). Sounds like a bug based on a misunderstanding of the twitter protocol: the 100 is the limit per API call, then I suspect twidge is treating the limit as an error and retrying the command, when it should be repeating with an offset to get the next group (possibly with rate limiting). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: time-recurrence-0.5.2
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Attoparsec concatenating combinator
2011/6/7 Bryan O'Sullivan b...@serpentine.com: On Tue, Jun 7, 2011 at 1:40 AM, Simon Meier iridc...@gmail.com wrote: Why would you need 'unsafePerformIO'. You can scrutinise the 'PS' constructors of the slice without dropping down to IO. True. Oops :-) Using a Builder for concatentation makes sense, if you want to exploit that copying a slice of the input array is cheaper right after it has been inspected (its fully cached) than later (as it is done when collecting slices in a list). When I've measured this in the past, I've found that it's often faster to accumulate a list and then run concat at the end than to use blaze-builder directly. That was certainly the case wit GHC 6.12; I haven't remeasured with 7.0. That's why you'll see that some places in the aeson JSON library use blaze-builder, while others manipulate bytestrings directly. When creating a Builder that you run afterwards, then you essentially create a list of bytestring concatenations as a closure. It makes sense that you don't win with such an approach, as the concatenation still only happens after then end of this list is reached. What you'd need is to nest attoparsec's Parser monad with the 'Put' monad provided in the blaze-builder internals [1]. However, I'm not yet sure how to achieve this in a modular fashion. Perhaps, using iteratee's the right way might provide a good answer, but that's just guesswork. The performance characteristics of blaze-builder are such that for short output sequences working with bytestrings directly is sometimes favorable, as the setup overhead before the Builder can be executed needs to be amortized. However, Builders work with a single pass through the input data, while many bytestring operations require two passes. For example, 'Data.ByteString.pack' first determines the length of the input and only afterwards writes the data to memory. Using blaze-builder's 'fromWord8s' requires only a single traversal and is faster for lists of length 64 on my 32-bit Core 2 Duo machine. I expect a similar effect for concatenating lists of strict bytestrings. [1] http://hackage.haskell.org/packages/archive/blaze-builder/0.3.0.1/doc/html/Blaze-ByteString-Builder-Internal.html#g:3 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Non-advanced usage of Type classes
Hello, In a recent thread, it has been asserted that defining type class is something you seldom need when programming in Haskell. There is one thing that as non-professional Haskell programmer I found type-classes useful for: Testing. This is probably very OO and is pretty much influenced by what I read in RWH but I find useful to define TC that abstract away from low-level interactions with other code, possibly IO related, in such a way that I can have one implementation for testing and one implementation for real work that is wired in caller context. This is what is called mockist TDD in some circles: Write code that expresses what it needs in its own terms, then implement glue to the code that provide the concrete behaviour. For example, while designing some program (a game...) I defined a type class thus: class (Monad io) = CommandIO io where readCommand :: io Command writeResult :: CommandResult - io () Then I defined in a module Commands.IO : instance CommandIO IO where readCommand = do input - getLine ... writeResult r = putStrLn $ show r and for the purpose of testing I defined in some test module: instance CommandIO (S.State ([Command],[CommandResult])) where readCommand = do ((c:cs),rs) - S.get writeResult r = do (cs,rs) - S.get ... Is this badly designed code that tries to mimic OO in a functional setting? If the answer is yes, how could I achieve same result (eg. testing the code that does command REPL) without defining type classes? Regards, Arnaud ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Non-advanced usage of Type classes
Is this badly designed code that tries to mimic OO in a functional setting?
If the answer is yes, how could I achieve same result (eg. testing the code
that does command REPL) without defining type classes?
Here's how I do it:
data InteractiveState = InteractiveState {
state_read :: IO Command
, state_write :: Result - IO ()
}
Now when I run it for real, I pass 'InteractiveState getLine putStrLn'
and when I run it for testing, I pass 'InteractiveState (getChan
in_chan) (putChan out_chan)'.
Of course, you have to pass this InteractiveState around, but
hopefully your IO using section is restricted to a small event loop
and threading it through is not a burden. And there's always StateT.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Non-advanced usage of Type classes
On Tue, Jun 7, 2011 at 10:32 PM, Evan Laforge qdun...@gmail.com wrote:
Is this badly designed code that tries to mimic OO in a functional
setting?
If the answer is yes, how could I achieve same result (eg. testing the
code
that does command REPL) without defining type classes?
Here's how I do it:
data InteractiveState = InteractiveState {
state_read :: IO Command
, state_write :: Result - IO ()
}
How about :
data InteractiveState io = InteractiveState {
state_read :: io Command
, state_write :: Result - io ()
}
Then you don't even depend on some specific monad. I understand you can
always (always?) encapsulate what is done through a type class by using a
data containing functions. But then, is this not even closer to OO
programming, an object that carries its own methods with itself, possibly
with the additional overhead that *each* instance would have its own private
references to possibly identical functions.
Thanks,
Arnaud
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cons of -XUndecidableInstances
On 6/7/11 1:01 PM, James Cook wrote: On Jun 7, 2011, at 12:43 PM, MigMit wrote: wren ng thornton wrote: One particularly trivial example that comes to mind is: newtype Mu f = Mu (f (Mu f)) instance Show (f (Mu f)) = Show (Mu f) where show (Mu x) = Mu ( ++ show x ++ ) -- Or however you'd like to show it Ehm, that does look like poor design. Sure you don't mean Mu f can be printed if and only if f (Mu f) can be printed. What you probably mean is if f transforms printable things to printable things, then Mu f is a printable thing. And you CAN express just that: Actually, I would argue that the former _is_ what is meant. It's a weaker condition than the latter and it is the necessary and sufficient condition to define the instance - one of the steps involved in formatting a value of type Mu f is to format a value of type f (Mu f). It doesn't actually matter whether forall x. Show x = Show (f x) holds in general. Indeed. Often the fact that (forall x. Show x = Show (f x)) holds will serve to prove that Show (f (Mu f)), but there's no reason why the more stringent proof is a requirement. The necessary and sufficient condition is: instance forall f. ( Show (Mu f) = Show (f (Mu f)) ) = Show (Mu f) where... Which isn't directly expressible in Haskell. And even if we could write it, it wouldn't mean what it ought to mean; because the typeclass resolution system commits to an instance once the head matches, rather than viewing the context as preconditions for matching the head. Thus, there's no way to pass in an implication like that; it's equivalent to requiring both Show (Mu f) and Show (f (Mu f)). And since the former is trivially satisfied, we only need to specify the need for Show (f (Mu f)). type ShowD a = forall p. (forall x. Show x = p x) - p a While I don't shy away from RankNTypes, I don't see that this really buys us anything. UndecidableInstances is easily supportable, higher rank polymorphism takes a bit of work and therefore reduces portability. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Distributing Haskell GUI apps for Windows/MacOS?
On Tue, 07 Jun 2011 12:58:52 +0200, Pedro Vasconcelos p...@dcc.fc.up.pt wrote: Hello, I've implemented a Haskell program to play a modern board game. I've put it on Hackage (http://hackage.haskell.org/package/hstzaar) but would also like to distribute to people without the Haskell development tools. Are there any easy ways of making installers for Windows/MacOS (preferably using free or open source tools)? I use Inno Setup, it works quite well. Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Non-advanced usage of Type classes
Here's how I do it:
data InteractiveState = InteractiveState {
state_read :: IO Command
, state_write :: Result - IO ()
}
How about :
data InteractiveState io = InteractiveState {
state_read :: io Command
, state_write :: Result - io ()
}
I guess you could, but I like it concrete.
Then you don't even depend on some specific monad. I understand you can
always (always?) encapsulate what is done through a type class by using a
data containing functions. But then, is this not even closer to OO
programming, an object that carries its own methods with itself, possibly
with the additional overhead that *each* instance would have its own private
references to possibly identical functions.
No, because I don't think there are any objects? In fact, I'm not
even sure what you mean. I'm assuming you have an event loop like:
event_loop st = do
cmd - state_read st
state_write st (calculate_response cmd)
event_loop st
calculate_response :: Command - Result
Since 'st' never changes (in my case it does have some changing
values), you can just write:
event_loop st = forever $ state_write st = calculate_response $
state_read st
There are no objects or private references here, and I'm not even sure
what they mean in this context.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Non-advanced usage of Type classes
On Tue, Jun 7, 2011 at 16:16, Arnaud Bailly arnaud.oq...@gmail.com wrote: For example, while designing some program (a game...) I defined a type class thus: class (Monad io) = CommandIO io where readCommand :: io Command writeResult :: CommandResult - io () This is in fact one of the reasons to use type classes. In fact, you'll find a somewhat more general variety of it on Hackage in a couple of forms, the one I'm most familiar with being MonadPrompt. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Non-advanced usage of Type classes
Is this badly designed code that tries to mimic OO in a functional
setting? If the answer is yes, how could I achieve same result (eg. testing
the code that does command REPL) without defining type classes?
Why would that be badly designed? And why would that be more OO? IMO it is a
perfectly suited usage of type classes.
Here's how I do it:
data InteractiveState = InteractiveState {
state_read :: IO Command
, state_write :: Result - IO ()
}
Well, it's pretty much the same thing, except you explicitely carry a value
containing your methods instead of simply carrying a type. Plus it delays
the resolution of which function will be called to the execution.
With typeclasses, it will be determined statically, no need to carry the
functions.
2011/6/7 Arnaud Bailly arnaud.oq...@gmail.com
Hello,
In a recent thread, it has been asserted that defining type class is
something you seldom need when programming in Haskell.
There is one thing that as non-professional Haskell programmer I found
type-classes useful for: Testing. This is probably very OO and is pretty
much influenced by what I read in RWH but I find useful to define TC that
abstract away from low-level interactions with other code, possibly IO
related, in such a way that I can have one implementation for testing and
one implementation for real work that is wired in caller context. This is
what is called mockist TDD in some circles: Write code that expresses what
it needs in its own terms, then implement glue to the code that provide
the concrete behaviour.
For example, while designing some program (a game...) I defined a type
class thus:
class (Monad io) = CommandIO io where
readCommand :: io Command
writeResult :: CommandResult - io ()
Then I defined in a module Commands.IO :
instance CommandIO IO where
readCommand = do input - getLine
...
writeResult r = putStrLn $ show r
and for the purpose of testing I defined in some test module:
instance CommandIO (S.State ([Command],[CommandResult])) where
readCommand = do ((c:cs),rs) - S.get
writeResult r = do (cs,rs) - S.get
...
Is this badly designed code that tries to mimic OO in a functional
setting? If the answer is yes, how could I achieve same result (eg. testing
the code that does command REPL) without defining type classes?
Regards,
Arnaud
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Non-advanced usage of Type classes
...and the other one being operational (which I find simpler). 2011/6/8 Brandon Allbery allber...@gmail.com On Tue, Jun 7, 2011 at 16:16, Arnaud Bailly arnaud.oq...@gmail.com wrote: For example, while designing some program (a game...) I defined a type class thus: class (Monad io) = CommandIO io where readCommand :: io Command writeResult :: CommandResult - io () This is in fact one of the reasons to use type classes. In fact, you'll find a somewhat more general variety of it on Hackage in a couple of forms, the one I'm most familiar with being MonadPrompt. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell platform question
On 07/06/11 14:03, Brandon Allbery wrote: On Tue, Jun 7, 2011 at 07:34, Tim Dockert...@dockerz.net wrote: do others go about testing their code with many hackage dependencies against a new ghc? I would have expected that the first thing to do would be get the We don't, for the most part; ghc is a quickly moving target and usually has multiple type theory experiments going on in its code, and it's best to avoid new versions until they stabilize and any core dependents are updated. GHC announcements will often mention how usable the release is expected to be for us non-type theorists. Unless you're a ghc hacker, you shouldn't in general rush into a new ghc version. (This isn't Linux. The bleeding edge is for type theory, not geeks.) I get your point, but it's not only type theory breakthroughs that are in the bleeding edge. There's significant runtime improvements also: http://www.mail-archive.com/glasgow-haskell-users@haskell.org/msg19780.html (for certain bytestring usage patterns: 10x improvement in gc time, and a third as much memory used!). I was keen to try this out, but underestimated the effort in how much manual tweaking I'd have to do to get all the dependencies of my code working. Perhaps it's best for me to take Simon's advice and wait for the 7.2 release. Tim ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HUnit false-positive stumper
Didn't get to this last night but I've just now confirmed this. With a normal build (defaulting to -O) the test code below generates only 3 failures (MacOS Leopard w/GHC 6.12.3 and HUnit 1.2.2.3). When using -O0 or by changing assertFailure in Test.HUnit.Lang (line 81) to use E.throwIO instead of E.throw I get the expected 6 failures. This is very reproducible for me. I can use -O0 for my tests, but it would be great if HUnit were updated to use the throwIO call (cc'ing Richard Giraud accordingly). Thanks! -KQ module Main where import Control.Monad (unless) import Test.HUnit main = runTestTT $ TestList [ True ~=? True , False ~=? True , TestCase $ assertEqual both true True True , TestCase $ assertEqual false true False True , TestCase $ assertEqual fa False True , TestCase $ assertEqual f False True , TestCase $ (False @?= True) , TestCase $ unless (False == True) (assertFailure f) ] On Mon, 06 Jun 2011 09:00:07 -0700, qu...@sparq.org wrote: That sounds very applicable to my issue (and unfortunately my googling missed this, ergo my consult of haskell-cafe uberwissenmensch). When I again have access to the aforementioned Mac this evening I'll try both disabling optimizations and a tweaked HUnit to see if that resolves the problem and report back then. -KQ Quoting Max Bolingbroke batterseapo...@hotmail.com: On 6 June 2011 16:18, Jimbo Massive jimbo.massive-hask...@xyxyx.org wrote: Or is this bad behaviour due to HUnit doing something unsafe? I think it may be related to this bug: http://hackage.haskell.org/trac/ghc/ticket/5129 The suggested fix is to change HUnit to define assertFailure with throwIO, but the latest source code still uses throw: http://hackage.haskell.org/trac/ghc/ticket/5129 So this could very well be a HUnit bug. Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe - This mail sent through IMP: http://horde.org/imp/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- -KQ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Comment Syntax
On 7/06/2011, at 9:36 PM, Guy wrote: Out of interest, is there any other language where the comment delimiter is invalid if immediately followed by a symbol? Not exactly what you asked, but in some implementations of Algol, comment This is a comment; commentThis is a syntax error; And in the documentation of the M4 macro processor, where changecom(L,R) sets left and right delimiters for comments and changequote(L,R) sets left and right delimiters for quoting, the effect of having one of these left delimiters a prefix of the other is undefined. When it happens by accident the results are, well, confusing. But after doing changecom(dnlx) you find that dnl xyz is a call to the built in macro Discard until New Line, while dnlx yz is a comment. There have been Prolog systems on IBM machines where the set of legal tokens depended on which operators had been declared. For example, if you had declared -- as an operator, then was two -- tokens, but otherwise four - tokens. What they did with comments I shudder to think. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
