- Haskell-Cafe - Haskell.org

Idea for a tool
by Michael Snoyman 20 Oct '10

20 Oct '10

Hi all, I saw a quote from Eric Kow via Neil Mitchell[1] that we don't spend enough time writing tools. Well, I've decided that the most annoying part of package maintainership right now is staying on top of new versions of dependencies. We essentially have two options right now: * Follow the PVP and put an upper bound on all dependencies, and people will be upset when your package only works with the old version of the dependency. * Skip the upper bound, and risk having your code break when there's a new version. I have an idea for a tool: you give it a list of packages you maintain, or even better yet, you give it your email address and it gets that list automatically. Then is looks through all your dependencies and sees if you have any upper bounds preventing newer versions from being used. Bonus points for making it a web service that just gives you an RSS feed. If anyone's interested in writing a tool like that, let me know. Otherwise, next time I'm twiddling my thumbs I'll try to throw it together. I've never dealt directly with the Cabal library, but there's a first time for everything. If someone else wants to write that tool and wants help sticking a web service on it, let me know. Michael [1] http://neilmitchell.blogspot.com/2010/10/enhanced-cabal-sdist.html

3 4

Re: [Haskell-cafe] Haskellers.com skills list moderation?
by John Lato 20 Oct '10

20 Oct '10

My $.02 follows: > From: Michael Snoyman <michael(a)snoyman.com> > > There's only two skills which I think absolutely must go: > > Other languages I know: C# .NET, XSLT, Microsoft SQL Server, XML, SQL, > CSS, C, C++, Java, HTML, Visual Basic Script, Pascal, Rexx, Basic and > assembler > tool building > Agreed that both should go. > There are 11 skills I'm leaning towards dropping, all because they > fall in the too vague/too general category. Your input is requested on > these. They are: > > Attribute Grammar > Keep as "Attribute Grammars" > Cabal, packaging, build and distribution tools > This should be two categories: "Cabal internals" and "Software packaging/distribution tools". Keep Cabal internals, possibly keep the other > Categorical Programming Denotational design > Digital Forensics > keep > Fault Tolerant Server Software Mathematics > drop (possibly keep FTSS, maybe change the name) > Programming using Arrows > Possibly keep with a different name > Proving observational equivalence between Haskell programs drop > Transactional business applications development > I'm not entirely sure what this means, specifically if it's business transactions or db/software transactions. > UNIX Scripting and Tool Authoring > keep as "UNIX Scripting" > > Of the remaining 32 skills, some of them fall in the "too specific" > range just a bit (software transactional memory, property based > testing), but I'm inclined to let it slide. These 32 are: > > Advanced type-level programming (GADTs, TypeFamilies, proofs, etc.) > Algorithmic Problem Solving > Bioinformatics > Concurrent Haskell > DSL Design > Darcs internals > Foreign Function Interface (FFI) > Formal Verification > Functional graphics programming (2D, 3D, GPU) > GHC internals > Generic Programming > Graphical User Interfaces > Happstack Web Framework > Hardware Acceleration DSLs > Haskell on embedded devices > High Assurance Software Development > High-performance Haskell > Metaprogamming via Template Haskell > Natural Language Processing (tagging, parsing, translation,...) > Physics & Simulation > Programming language translation > Property based testing (QuickCheck) > Purely functional data structures — design and implementation > Reverse Engineering > Robotics and Automation > Signal Processing > Software Transactional Memory > Teaching Haskell > Web development (HTML, CSS and Javascript) > Yesod Web Framework > I would argue for keeping most of these. I do think that skills based on specific packages (Happstack, Yesod, STM?) perhaps should be dropped, except for packages that are integral to the Haskell universe (compilers, Cabal, Darcs?, QuickCheck?). For these packages, I think the "-internals" categories are the most useful. What about rolling Happstack, Yesod, etc. into "Haskell Web Frameworks", and possibly also keeping the "Web Development (HTML, CSS and Javascript)" category? John

4 5

Why isn't there a cheaper "split-in-two" operation for Data.Set?
by Ryan Newton 20 Oct '10

20 Oct '10

Would there be anything wrong with a Data.Set simply chopping off half its (balanced) tree and returning two approximately balanced partitions -- i.e. Data.Set.split without the pivot argument? Even though it can't quite be constant-time (still need rebalancing) it could still be cheaper than Data.Set.split, right? In the context of Set.hs, I'm thinking along the lines of something like the following: cleave :: Set a -> (Set a, Set a) cleave Tip = (Tip, Tip) cleave (Bin _ x l r) | size l > size r = (l, insertMin x r) | otherwise = (insertMax x l, r) For one thing, this seems like the proposed function would be useful for consuming a set in parallel, similar to Guy Steele's arguments in recent talks (see Organizing Functional Code for Parallel Execution; or, foldl and foldr Considered Slightly Harmful<http://research.sun.com/projects/plrg/Publications/ICFPAugust2009Steele.pdf>). That is, one splits a tree and uses "par" to process the left and right half in parallel, enabling Alternatively, it would be simple to provide a parallel version of mapMonotonic that does this internally, i.e.: mapMonotonic _ Tip = Tip mapMonotonic f (Bin sz x l r) = Bin sz (f x) (mapMonotonic f l) (mapMonotonic f r) Becomes something like: parMapMonotonic f (Bin sz x l r) = par left $ seq right $ Bin sz (f x) left right where left = mapMonotonic f l right = mapMonotonic f r Cheers, -Ryan

5 5

HDBC/ODBC/MySQL - working configuration?
by Neil Davies 20 Oct '10

20 Oct '10

Hi I'm having some difficulty getting the above combination to work, I've successfully used ODBC against MS but the MySQL stuff is creating some really interesting error conditions in the HDBC-ODBC module. My first thought is that it must be me, so does anyone out there have this combination working (with or without HaskellDB)? If so, can you tell me which versions of things you are using and which ODBC drivers (and configurations) you are using? Cheers Neil

1 0

HaskellDB/ODBC/MySQL issue
by Neil Davies 19 Oct '10

19 Oct '10

Hi I can't seem to get the combination of HaskellDB/ODBC/MySQL to even get off the ground, example: import OmlqDBConnectData (connect'options) import Database.HaskellDB import Database.HaskellDB.HDBC.ODBC (odbcConnect) import Database.HaskellDB.Sql.MySQL (generator) main = odbcConnect generator connect'options $ \db -> tables db >>= print gives me Prelude.(!!): index too large Suggestions? Cheers Neil

2 1

Happstack, RqData: (How) can I extract multiple data from form?
by Никитин Лев 19 Oct '10

19 Oct '10

-------- Пересылаемое сообщение -------- 20.10.10, 00:22, "Никитин Лев" <leon.v.nikitin(a)pravmail.ru>: >>Are formlets integrated with HSP? > hsp support is in a separate package: > http://hackage.haskell.org/package/formlets-hsp > There is a demo of using HSP+Formlets+Happstack here: > http://src.seereason.com/formlets-hsp/examples/happs-hsp/ > hope this helps! > - jeremy > Thanks! (Sorry for my stuped question) -------- Завершение пересылаемого сообщения --------

1 0

Template Haskell: onward and upward
by Simon Peyton-Jones 19 Oct '10

19 Oct '10

Folks Following lots of feedback from users, especially at ICFP, I've evolved some proposals for Template Haskell, that should make it both more expressive, and more secure. http://hackage.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal Do let me know what you think. Discussion by email is fine (cc me if it's on Haskell-cafe), or comments direct on the Trac. (None of this will be in GHC 7.0; it's a proposed plan for post-release improvements.) Thanks Simon

3 2

An interesting paper from Google
by Andrew Coppin 19 Oct '10

19 Oct '10

http://k1024.org/~iusty/papers/icfp10-haskell-reagent.pdf I'm sure some of you have seen this already. For those who lack the time or inclination to read through the (six) pages of this report, here's the summary... We [i.e., the report authors] took a production Python system and rewrote bits of it in Haskell, some of which is now in production use. We conclude the following: - Python lets you just do whatever the hell you want, but Haskell demands that you actually have a *plan* before you start churning out code and running it. The result is generally cleaner and more consistent when you get there. - Haskell's much-criticised immutable data is actually an *advantage* for backtracking search problems. - Haskell wins for thread-safety. - ADTs are nicer than exceptions. - The parts of Haskell stolen by Python aren't as nice in Python as they are in Haskell. [Well, duh.] - We like what GHC provides for profiling. - We are dissappointed by what GHC provides for debugging. - "String" is too slow. None of the alternatives seem to be widely supported. If your library consumes Strings and returns Strings, the fact that ByteString exists doesn't help you. - Recent changes to GHC broke our code. (Specifically, extensible exceptions.) We were quite surprised that such a "stable" and "mature" system as GHC would do this to us. - Haskell has quite a high barrier to entry. [Again, duh.] The paper also contains an interesting section that basically says "we tried porting the Python implementing of XYZ into Haskell, but there wasn't really any advantage because it's all I/O". In my humble opinion, "it's all I/O" is a common beginner's mistake. Reading between the lines, it sounds like they wrote the whole thing in the IO monad, and then decided it looked just like the existing Python code so there wasn't much point in continuing. I guess it's one of the bad habits that imperative programmers get into. With a little more experience, you eventually figure out that you can limit the stuff actually in the IO monad to a surprisingly small section, and so almost everything else in pure code, no matter how much the problem looks like it's "all I/O". But anyway, I'm only guessing from what I can actually see with my own eyes in the report itself. I'm surprised about the profiler. They seem really, really impressed with it. Which is interesting to me, since I can never seen to get anything sensible out of it. It always seems to claim that my program is spending 80% of its runtime executing zipWith or something equally absurd. I'm unsurprised which their dissappointment with debugging. I'm still quite surprised that there's no tool anywhere which will trivially print out the reduction sequence for executing an expression. You'd think this would be laughably easy, and yet nobody has done it yet. Their comments about String are sadly true.

8 11

profiling cabal libraries
by Tom Hawkins 19 Oct '10

19 Oct '10

How do I profile cabal libraries? I "cabal install -p" a local package I am testing, and I compile a test of the library using "-prof -auto-all". But the profiling report only lists a CAF entry for the library, but does not detail any of the library's top level functions. What am I doing wrong? -Tom

3 2

Re: [Haskell-cafe] Haskellers.com skills list moderation?
by Michael Snoyman 19 Oct '10

19 Oct '10

Hey JP, It's a tough question you're asking. I think areas directly applicable with Haskell, such as bioinformatics, games, physics simulations, are a pretty easy yes. Some more complicated things would be "related skills", such as knowing other programming languages, system administration, etc. I would like to hear the cafe's opinion on that; my gut feeling is a "yes is moderation." Having a web programming skill seems OK, but I wouldn't want to put in HTML5, Javascript, CSS 3 and so on as separate skills. Michael On Tue, Oct 19, 2010 at 3:45 PM, JP Moresmau <jpmoresmau(a)gmail.com> wrote: > Are skills only Haskell related? I mean, are they only subcategories of > "haskell programming". Because "bioinformatics" is there, and in that case > it shouldn't be. If skills include any application domain where people might > use Haskell, the list will be much bigger, and surely the Hackage categories > can be of use (for example, for me, I would request Games, Artificial > Intelligence...). > And, thanks for doing haskellers, great work! One day I want to really do a > web application in Haskell and I'll sure give a go to yesod. > JP > > On Tue, Oct 19, 2010 at 3:32 PM, Michael Snoyman <michael(a)snoyman.com> > wrote: >> >> Alright, adding skills is now only possible by an admin. In the place >> where we previously had "add a skill", we now have "request a new >> skill." That's the easy part. Now we need to determine which skills >> stay, and which ones go. I think the vast majority of them are fine, >> so I'll leave them at the end of this email. If anyone thinks I'm >> being to generous by allowing a specific still to say, just say so. >> >> There's only two skills which I think absolutely must go: >> >> Other languages I know: C# .NET, XSLT, Microsoft SQL Server, XML, SQL, >> CSS, C, C++, Java, HTML, Visual Basic Script, Pascal, Rexx, Basic and >> assembler >> tool building >> >> There are 11 skills I'm leaning towards dropping, all because they >> fall in the too vague/too general category. Your input is requested on >> these. They are: >> >> Attribute Grammar >> Cabal, packaging, build and distribution tools >> Categorical Programming >> Denotational design >> Digital Forensics >> Fault Tolerant Server Software >> Mathematics >> Programming using Arrows >> Proving observational equivalence between Haskell programs >> Transactional business applications development >> UNIX Scripting and Tool Authoring >> >> Of the remaining 32 skills, some of them fall in the "too specific" >> range just a bit (software transactional memory, property based >> testing), but I'm inclined to let it slide. These 32 are: >> >> Advanced type-level programming (GADTs, TypeFamilies, proofs, etc.) >> Algorithmic Problem Solving >> Bioinformatics >> Concurrent Haskell >> DSL Design >> Darcs internals >> Foreign Function Interface (FFI) >> Formal Verification >> Functional graphics programming (2D, 3D, GPU) >> GHC internals >> Generic Programming >> Graphical User Interfaces >> Happstack Web Framework >> Hardware Acceleration DSLs >> Haskell on embedded devices >> High Assurance Software Development >> High-performance Haskell >> Metaprogamming via Template Haskell >> Natural Language Processing (tagging, parsing, translation,...) >> Physics & Simulation >> Programming language translation >> Property based testing (QuickCheck) >> Purely functional data structures — design and implementation >> Reverse Engineering >> Robotics and Automation >> Signal Processing >> Software Transactional Memory >> Teaching Haskell >> Web development (HTML, CSS and Javascript) >> Yesod Web Framework >> >> Michael >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe > > > > -- > JP Moresmau > http://jpmoresmau.blogspot.com/ >

1 0