August 2012 - Haskell-Cafe

cabal-dev + haskell mode (vim)
by Benjamin Edwards 04 Aug '12

04 Aug '12

Hello Café, I am struggling to get ctags and / or haskell mode to work with cabal-dev. This is quite annoying. Has anyone worked around this? Ben

2 2

Why is the the transpose function in Data.List more complicated?
by KC 03 Aug '12

03 Aug '12

Transpose in Data.List is the following: transpose :: [[a]] -> [[a]] transpose [] = [] transpose ([] : xss) = transpose xss transpose ((x:xs) : xss) = (x : [h | (h:_) <- xss]) : transpose (xs : [ t | (_:t) <- xss]) Yet this seems to work. transp :: [[b]] -> [[b]] transp ([]:_) = [] transp rows = map head rows : transp (map tail rows) Why is the the transpose function in Data.List more complicated? -- -- Regards, KC

2 1

Re: [Haskell-cafe] What Haskell Records Need
by Andrew Butterfield 03 Aug '12

03 Aug '12

On 2 Aug 2012, at 09:25, Erik Hesselink wrote: > Isn't this exactly the problem solved by all the lens packages? > Current popular ones are fclabels [0] and data-lens [1]. > > [0] http://hackage.haskell.org/package/fclabels > [1] http://hackage.haskell.org/package/data-lens Not sure what all of these do, but I have a simple solution I use in my work: > >> Take the following types from a contrived >> example. >> >>> type Salary = Integer >>> >>> data Job = Job >>> { title :: String >>> , salary :: Salary >>> } Rather than setTitle :: String -> Job -> Job we lift the first argument and define setfTitle :: (String -> String) -> Job -> Job setfTitle f jobrec = jobrec{ title = f $ title jobrec } then setTitle = setfTitle . const This is all just boilerplate, so we continue setfSalary :: (Salary -> Salary) -> Job -> Job setfSalary f jobrec = jobrec{ salary = f $ salary jobrec } >>> >>> data Person = Person >>> { name :: String >>> , job :: Job >>> } >> setfName :: (String -> String) -> Person -> Person setfName f prec = prec{ name = f $ name prec } setfJob :: (Job -> Job) -> Person -> Person setfJob f prec = prec{ job = f $ job prec } Now we can use function composition to do two levels setfTitleInPerson :: (String -> String) -> Person -> Person setfTitleInPerson = setfJob . setfTitle setTitleInPerson :: String -> Person -> Person setTitleInPerson = setfTitleInPerson . const Simple function composition works to put these together... I was frustrated by this problem a while back, and decided to approach it formally (I write literate Haskell/LateX documents), and went to work, doing the math with the intention of writing a suitable combinator, until I discovered I didn't need one .... lifting from X -> R -> R to (X -> X) -> R -> R gave me all I needed... >> Since I've used record syntax, I get >> getter/accessor functions (title, salary, >> name, job) for free. Now suppose I want to >> create an aggregate getter function: return >> the salary of a given person. Piece of cake, >> it's just function composition >> >>> getSalary :: Person -> Salary >>> getSalary = salary . job >> >> Done! Now suppose I want to write a >> setter/mutator function for the same nested >> field >> >>> setSalaryMessy :: Salary -> Person -> Person >>> setSalaryMessy newSalary person = >>> person { >>> job = (job person) { >>> salary = newSalary >>> } >>> } >> >> Ouch! And that's not even very deeply nested. >> Imagine 4 or 5 levels deep. It really makes >> Haskell feel clunky next to `a.b.c.d = val` >> that you see in other languages. Of course >> immutability means that the semantics of >> Haskell are quite different (we're creating >> new values here, not updating old ones) but >> it's still common to model change using these >> kinds of updates. >> >> What if along with the free getters that >> the compiler generates when we use record >> syntax, we also got semantic editor >> combinator (SEC) functions[0] that could be >> used as follows? >> >>> setSalary newSalary = job' $ salary' (const newSalary) >>> >>> giveRaise amount = job' $ salary' (+amount) >>> >>> givePercentRaise percent = job' $ salary' (*(1+percent)) >> >> For each field x, the compiler generates a >> function x' (the tic is mnemonic for change). >> These little functions aren't hard to write, >> but they're classic boilerplate. >> >>> job' :: (Job -> Job) -> Person -> Person >>> job' f person = person {job = f $ job person} >> >>> salary' :: (Salary -> Salary) -> Job -> Job >>> salary' f job = job { salary = f $ salary job} >> >> These type of utility functions are a dream >> when working with any reference type or >> State Monad. >> >>> modify $ givePercentRaise 0.25 >> >> The compiler could also generate polymorphic >> SEC functions for polymorphic fields. >> Further, the compiler could disallow using >> old-style update syntax for fields whose SEC >> update function is not in scope, giving us >> fine-grained control over access and update. >> On the other hand we currently have to create >> new functions to achieve this (exporting the >> getter means exporting the ability to update >> as well, currently). >> >> Of course this doesn't address the >> namespacing issues with records, but it is >> likely nicely orthogonal to other proposals >> which do. >> >> Also note that there's a package on hackage [1] >> that will generate SEC functions using TH. >> It's nice, but I prefer the style of field >> names used above for updaters (field' vs >> editField). >> >> Let me know what you think. I'll write up an >> official proposal if there's a bit of >> general interest around this. >> >> Thanks for reading, >> >> --Jonathan >> >> [0] - http://conal.net/blog/posts/semantic-editor-combinators >> [1] - >> http://hackage.haskell.org/packages/archive/sec/0.0.1/doc/html/Data-Semanti… >> >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -------------------------------------------------------------------- Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 Lero@TCD, Head of Foundations & Methods Research Group Director of Teaching and Learning - Undergraduate, School of Computer Science and Statistics, Room G.39, O'Reilly Institute, Trinity College, University of Dublin http://www.scss.tcd.ie/Andrew.Butterfield/ -------------------------------------------------------------------- -------------------------------------------------------------------- Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 Lero@TCD, Head of Foundations & Methods Research Group Director of Teaching and Learning - Undergraduate, School of Computer Science and Statistics, Room G.39, O'Reilly Institute, Trinity College, University of Dublin http://www.scss.tcd.ie/Andrew.Butterfield/ --------------------------------------------------------------------

6 8

Re: [Haskell-cafe] [Haskell-beginners] vector indexing time
by KC 03 Aug '12

03 Aug '12

Thank you for that insight. :) On Fri, Aug 3, 2012 at 4:50 AM, Heinrich Apfelmus <apfelmus(a)quantentunnel.de > wrote: > > Creating the vector still takes time proportional to the length of the > vector. In fact, it appears that in your example, the vector packages > optimizes the creation time to create only up to the element that you > actually demand. > > The linear time you're seeing is not the result of an inefficiency of > vector indexing, but the result of an efficiency in vector creation. > > > Best regards, > Heinrich Apfelmus > > -- > http://apfelmus.nfshost.com > > -- -- Regards, KC

1 0

Community-wide RFP
by Black Mephistopheles 03 Aug '12

03 Aug '12

Is there a place - on the Haskell Wiki perhaps - with a list of desired Haskell-related projects? Both for programs written in Haskell, as well as things to help, and enhance the programming experience? Walt "BMeph" Rorie-Baety I am an eyewitness to what you committed in that location.

2 1

ANNOUNCE: time-recurrence-0.9.0
by Chris Heller 02 Aug '12

02 Aug '12

I am happy to announce a new version of time-recurrence, a library of functions for generating recurring sequences of dates: http://hackage.haskell.org/package/time-recurrence New in version 0.9.0 is a redesigned top layer API. Previously recurrences were described by combining generating functions to get the desired effect. This was quite functional but had the drawback that a recurrence was difficult to persist outside of the Haskell run-time. As of version 0.9.0 this limitation is no more. Now the actual recurrence rule is defined by combining types into a data structure which can either be persisted (and later read back) or evaluated into a function to generate dates. This also means that the type system now enforces correct rule creation! Additionally some convenience functions are available to construct the recurrence rule in a format familiar to previous users of this library. Here is a familiar example: Generate the 15th and 30th of the month, but only during the work week: > jan2011 = ptime "Sat, 01 Jan 2012 00:00:00 -0400" > jan2012 = ptime "Sun, 01 Jan 2013 00:00:00 -0400" > takeWhile (<= jan2013) $ starting jan2012 $ > recur monthly > >==> enum (Days [15,30]) > >==> filter (WeekDays [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 ] On the road to version 1.0, I plan to add another type layer which strictly enforces RFC 5545 section 3.3.10. As always I encourage feedback, criticism, suggestions and pull requests. I would especially welcome any type system experts feedback: quite a few GHC extensions needed to be turned on to get this to work. -Chris

1 0

Re: [Haskell-cafe] CRIP: the Curiously Reoccuring Instance Pattern
by oleg＠okmij.org 02 Aug '12

02 Aug '12

> did you see this, and the discussion around that time? > http://www.haskell.org/pipermail/haskell-prime/2012-May/003688.html > > I implemented hDeleteMany without FunDeps -- and it works in Hugs (using > TypeCast -- but looks prettier in GHC with equality constraints). I'm afraid I didn't see that -- I was on travel during that time. It is nice that hDeleteMany works on Hugs. I forgot if we tried it back in 2004. To be sure some HList code did work on Hugs. We even had a special subset of HList specifically for Hugs (which I removed from the distribution some time ago). The problem was that Hugs inexplicably would fail in some other HList code. Perhaps 2006 version is better in that respect, and more or all of HList would work on it. Thank you.

2 1

Is (==) commutative?
by Christian Sternagel 02 Aug '12

02 Aug '12

Dear all, with respect to formal verification of Haskell code I was wondering whether (==) of the Eq class is intended to be commutative (for many classes such requirements are informally stated in their description, since Eq does not have such a statement, I'm asking here). Or are there any known cases where commutativity of (==) is violated (due to strictness issues)? cheers chris

7 13

Re: [Haskell-cafe] [Haskell] ALife category
by Brent Yorgey 02 Aug '12

02 Aug '12

On Thu, Aug 02, 2012 at 01:50:50PM +0000, Amy de Buitléir wrote: > I'm developing a framework for artificial life experiments that I would like to > make available on Hackage eventually. I've read all the guidance and proposals I > could find for where to place packages in the hierarchy: > > http://www.haskell.org/haskellwiki/Hierarchical_module_names > http://www.cs.york.ac.uk/fp/libraries/layout.html > http://www.cs.york.ac.uk/fp/libraries/layoutSM.html > > I've also examined the current hierarchy of modules: > > http://hackage.haskell.org/packages/archive/pkg-list.html > > The current hierarchy has a top-level AI category, so it would seem logical to > me to add a top-level ALife category and put my package under that. But perhaps > it would be best not to start a new top-level category? I could put my package > under AI, because my framework does support the use of AI, and wouldn't look too > out of place with the other packages there. (Moving the discussion to haskell-cafe; haskell@haskell is generally for announcements and such.) It seems to me that you might be confusing two separate things. Cabal packages may list one or more "categories", which are used to group packages on the main list of packages: http://hackage.haskell.org/package/ . In general, I would say that you should avoid creating a new top-level category. Hierarchical module names are something different. The 'Category' specified in the .cabal file does NOT have to be the same as the first component of your module names (though for many packages it is). For example, it would be perfectly fine to specify 'AI' as the category, and then have module names like ALife.Foo and so on. -Brent

1 0

Key-Parametrized Lookup Table
by Alexander Foremny 02 Aug '12

02 Aug '12

Hello list, I am currently thinking that a problem of mine would best be solved if there was a Map-like data structure in which the value returned is parametrized over the lookup type. I wonder is this makes sense and if such a data structure exists or if it could be created while still being well typed. I essentially want to statically define a scope of Key values and dynamically define a list of keys. > -- Scope of possible keys. > type Label = String > data Key a where > KeyStr :: Label -> Key String > KeyInt :: Label -> Key Int > KeyChoice :: Label -> [a] -> Key a > -- Some key values, to be extended at runtime. > strKey "Some String" > strKey' "Another String" > intKey "Some integer" > choiceKey "Chose one" [ "a", "b", "c" ] :: KeyChoice String Now I need a data structure to possibly associate a value to the key. > data MapG = ... > type Value a = a > insert :: Key a -> Value a -> MapG Key Value -> MapG Key Value > lookup :: Key a -> MapG Key Value -> Maybe (Value a) I tried implementing this with multiple Map k a's. I tried adding a phantom type on some storage type of to implement KeyChoice as of type Key Int, but I ran into troubles with this approach. I wonder if Dynamic or Type Families could achieve this, but I am quite at a loss and would like to hear your opinion. I did try to search for this a bit, but I don't quite know how to phrase my problem. I'd like to apologize in advance if this question has been asked already. Regards, Alexander Foremny

6 9