May 2012 - Haskell-Cafe

hackage & hackage accounts
by Dmitry Malikov 16 May '12

16 May '12

Good day. Recently, in irc://#haskell you can see very often replicas of people, who are tired of waiting their hackage accounts. After next release of any package from hackagebot, some depressed people definitely comes out and starts telling to everybody how hard life is without having hackage account. 11:15 * hackagebot shakespeare 1.0.0.2 - A toolkit for making compile-time interpolated templates http://hackage.haskell.org/package/shakespeare-1.0.0.2 (MichaelSnoyman) 11:15 <|> I'm still waiting for my Hackage account... ... 15:12 * hackagebot hspec-discover 0.0.0 - Automatically discover and run Hspec tests http://hackage.haskell.org/package/hspec-discover-0.0.0 (SimonHengel) 15:13 <|> Still haven't got my hackage account And so on and so on. Yes, you can tolerate, that a lot of people considered in the order of things for asking lambdabot in public window every day, every hour. Yes, you can tolerate, that every five minutes some another notification from hackagebot will be be appeared, or maybe two or even three in a time. But how can you tolerate, that adding to all that stuff there is a permanent disturbances from the people, who can't submit their packages to hackage because they have no hackage account (frankly speaking, I'm also do not have one, but I've send 5 letters to Ross)? Previously, #haskell's log was really like something readable and interesting. But now it's a robot-like speeches with 2 bots, minimal slightly mixed with something really meaningfull. This raises some questions: 1) Did anyone successfully get their hackage account in last 2 months? Because it's really strange to see some "still don't have my hackage account"-message and another Ross answer in HC. 2) You should give hackage account for all of ther requiring people or remove hackagebot from #haskell. 3) Could I finally have my hackage account in the amount of all others, please? Dmitry Malikov

3 2

How to use Jacobian from levmar lib?
by Martin Hilbig 15 May '12

15 May '12

hi, i'm using the nice levmar package like this [1]. why is there such a big difference in 'infNorm2E' between using/not using the Jacobian? thanks in advance martin hilbig [1]: http://hpaste.org/68537

1 0

Safe Haskell at the export symbol granularity?
by Ryan Newton 14 May '12

14 May '12

Separate from whether or not we actually want this -- is it feasible? Here's my situation. When working on parallel programming libraries in Haskell there are very often unsafe operations one wants to do within an otherwise pure model. For example, Accelerate currently violates safe haskell because it trusts the user to provide an associative function to parallel "fold". No associativity, no referential transparency. The solution is to put fold in a separate namespace and mark that module as Unsafe. Likewise for certain monad-par operations that are unsafe. But this factoring can have a serious impact. Not only are extra modules required, but extra type classes as well. For example, if Accelerate is ever refactored for "Safe Haskell" then the following ParAccelerate type class probably should be as well: https://github.com/simonmar/monad-par/blob/5cc656bc45dc473d7a185ec99bb15619… I.e. ParAccelerate & ParAccelerateUnsafe for the "unsafeHybrid" operation. But this starts to be death by a thousand organizational factorings! - The package, abstract-par-accelerate, is already factored out from abstract-par just to avoid an unnecessary Accelerate dependency (which used to mean CUDA errors). (And *another* factoring is possibly warranted for whether or not the module depends on accelerate-io.) - The file would be separate to mark it as Safe Haskell. - The type class ParAccelerateUnsafe would be separate so as to put it in a separate file. What's a possible solution? If, in addition to "Safe" and "Unsafe" modules, there were "Partially Safe" modules, which exported a mix of safe and unsafe identifiers, then this could all be much cleaner. The simple rule is that any reference whatsoever to an unsafe identifier disqualifies the client code. For example, in the above ParAccelerate type class we would mark the unsafeHybrid binding with something like {-# UNSAFE unsafeHybrid #-}. We wouldn't even have to factor it out of the type class. Likewise, Accelerate could mark "fold" as unsafe (providing safe variants as well) without introducing module namespace bloat and confusion. What do you think? -Ryan

1 0

[ANN] Accelerate version 0.12: GPU computing with Haskell
by Manuel M T Chakravarty 14 May '12

14 May '12

We just released version 0.12 of Data.Array.Accelerate, the GPGPU[1] library for Haskell: http://justtesting.org/gpu-accelerated-array-computations-in-haskell This is a beta release. The library is not perfect, but it is definitely usable, and we are looking for early adopters. Manuel [1] Currently only NVIDIA GPUs are supported via NVIDIA's CUDA framework.

1 0

Bug in SYB, SYB-documentation or GHC-API (or I messed up somewhere)
by "Philip K. F. Hölzenspies" 14 May '12

14 May '12

Dear Haskelers, Since I don't quite know whether this is a SYB-thing or a GHC-specific thing, I figured this report should go here. If not, kindly redirect. I am trying to write a program, using the GHC-API to refactor some parts of the GHC-code (initially, I want to add a type variable to the types in the AST to express the representation of types, as noted to be a Good Thing at [1]). To do this, I first search for all definitions of and references to type constructors. I do this using SYB. Consider these functions: type OccurrenceTable = [(RdrName, (SrcSpan,Bool))] locTyNames :: SrcSpan -> Bool -> HsType RdrName -> OccurrenceTable locTyNames l p (HsTyVar n ) = [(n, (l, p))] <… HSType-specific traversal cases omitted for brevity …> extTyNamesDef :: Data a => SrcSpan -> a -> OccurranceTable extTyNamesDef l x = gmapQl (++) [] (extTyNames l) x extTyNamesTy :: SrcSpan -> HsType RdrName -> OccurranceTable extTyNamesTy l x = locTyNames l True x extTyNames l x = (extTyNamesDef l x `mkQ` extTyNamesTy l) x The OccurrenceTable type collects for every type constructor (RdrName) the location of its occurrence (either definition or reference, SrcSpan) and whether adding a type variable (formal or actual) requires parenthesis (Bool). This works fine, although now, we always find the same SrcSpan for everything. When traversing an AST, whenever we find anything that's Located, we want to continue the traversal with this new location information. To this end, we define: extTyNamesLoc :: Data a => Located a -> OccurrenceTable extTyNamesLoc (L l x) = extTyNames l x and modify the universal entry point to: extTyNames l x = (extTyNamesDef l x `mkQ` extTyNamesTy l `ext1Q` extTyNamesLoc) x However, it turns out that this never leads to an evaluation of extTyNamesLoc. I've come as far as to see that, since "Located a" is a synonym for "GenLocated SrcSpan a", the type we're looking for really has a binary constructor, thus we should use ext2Q. This made things work: We first modify the function we apply to Located things: extTyNamesLoc :: (Data loc, Data a) => SrcSpan -> GenLocated loc a -> OccurrenceTable extTyNamesLoc l (L l' x) = case cast l' of Just l'' -> extTyNames l'' x Nothing -> extTyNames l x and define the universal entry point to be: extTyNames l x = (extTyNamesDef l x `mkQ` extTyNamesTy l `ext2Q` extTyNamesLoc l) x Even though I see why this works, I'm not completely sure why the former version does not. Is there no currying with type constructors (for SYB)? The cast I perform always succeeds, because all types that occur in the traversal are "Located x" and never "GenLocated NonSrcSpanType x". The extensions to extX functions (i.e. ext1Q, ext2Q, ext1T, etc.) are not very extensively documented. Their discussion in the ICFP04 paper only discusses their relation to TypeableX classes, but not to the partiality of type constructor application and/or synonyms. (As a side-note on that discussion in ICFP04, the remark that we're generally interested in type constructors with arguments of kind * sounded fine, until I started to try and parameterise the AST in the location-annotation-type as well; it made my brain hurt.) Apologies for the waffling, but comments would be greatly appreciated. Regards, Philip [1] http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/HsSynType

3 2

ANN: Patterns 0.0.3
by Tobias Schoofs 13 May '12

13 May '12

Hi! I am pleased to announce patterns-0.0.3. On Hackage: http://hackage.haskell.org/package/patterns The Patterns package implements communication patterns that are often used in distributed, message-oriented applications. The package implements a set of basic patterns and a device to connect basic patterns through routers, brokers, load balancers, etc. The package is based on the zeromq library, but abstracts from the notion of sockets, on which zeromq is built. Cheers Tobias

1 0

Linear Diaphantine equation solver bug
by John D. Ramsdell 13 May '12

13 May '12

I uploaded a new version of the ACU unifier in package cmu. It includes a Linear Diaphantine equation solver that now handles inhomogeneous equations. What's interesting is the algorithm is based on a paper by Contejean and Devie. That paper includes a proof of correctness of their algorithm. Yet I found an example in which following the steps in the order they gave, the algorithm produces extra answers. I had to switch the order of the steps in the algorithm to get the right answer. I wonder if anyone else knows of this issue. The example is given in the module documentation on Hackage. John http://hackage.haskell.org/packages/archive/cmu/1.6/doc/html/Algebra-Commut…

1 1

Problem with forall type in type declaration
by Magicloud Magiclouds 11 May '12

11 May '12

Hi, Assuming this: run :: Monad IO a -> IO a data Test = Test { f } Here I'd like to set f to run, like "Test run". Then what is the type of f? The confusing (me) part is that, the argument pass to f is not fixed on return type, like "f1 :: Monad IO ()", "f2 :: Monad IO Int". So "data Test a = Test { f :: Monad IO a -> IO a} does not work. -- 竹密岂妨流水过山高哪阻野云飞 And for G+, please use magiclouds#gmail.com.

4 6

Oxford Haskell Users Group
by Nicolas Wu 11 May '12

11 May '12

Dear all, I'd like to announce that the Oxford Haskell User's Group will be meeting up next week at 7pm on Tuesday 15th May. As is our custom, we'll be catching up over a few drinks in a local pub, this time, it's at the Three Goats Heads, St Michael's Street. Discussion is informal, with the occasional presentation about some interesting aspect of Haskell. All are welcome! If you'd like to be kept up to date about future meetings, which are roughly once a week during term time, then do join our mailing list, which can be found under OxHUG at google groups [1]. All the best, Nick [1]: http://groups.google.com/group/oxhug

1 0

ANNOUNCE: haskell-src-exts 1.13.3
by Niklas Broberg 11 May '12

11 May '12

Fellow Haskelleers, I'm pleased to announce the release of haskell-src-exts-1.13.3! * On hackage: http://hackage.haskell.org/package/haskell-src-exts * Via cabal: cabal install haskell-src-exts * Darcs repo: http://code.haskell.org/haskell-src-exts This release attempts to fix a bunch of long-standing (and a few new) bugs, while still avoiding a new major version bump. Changelog: 1.13.2 --> 1.13.3 =============== * Fundep premises are now allowed to be empty. * Fix the bug where the lexer would crash on a LINE pragma that did not include a line number. * Fix the bug where the lexer would require the # of a MagicHash-style type constructor to be succeeded by at least one character in the file. * Fix really long-standing bug where the parser would crash with an ugly "Internal error" error message if encountering an extra }. * Report errors at the right place for function arity mismatches. Earlier they were reported at end of file, now they are reported where the function is declared. * Lexer now properly fails on line-breaks in string literals. * Lexer now handles character escapes up to 0x10FFFF (unicode). Cheers, /Niklas

1 0