- Haskell-Cafe - Haskell.org

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

Haskell Platform - BSD License?
by Sai Hemanth K 02 Aug '12

02 Aug '12

Hi, I am trying to use haskell for building a tool (in a commercial setting). I am trying to figure out what all licenses are involved here. Is there a single license for the entire haskell platform (and the runtime) or is it that I need to look at the individual licenses of all the libraries and tools that make up the platform and point to them separately? The wikipedia page on haskell platform [0] says Haskell Platform is BSD licensed. But I do not find any such info elsewhere. Any pointers on this would be greatly appreciated, Thanks, Hemanth K [0] Haskell platform on wikipedia : http://en.wikipedia.org/wiki/Haskell_Platform

5 5

What Haskell Records Need
by Jonathan Geddes 02 Aug '12

02 Aug '12

Greetings, tl;dr - What Haskell Records need are semantic editor combinators for free. I know this is yet another Record proposal among many, but none of them out there strike me as being exactly what I want in Haskell. Take the following types from a contrived example. >type Salary = Integer > >data Job = Job > { title :: String > , salary :: Salary > } > >data Person = Person > { name :: String > , job :: Job > } 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…

3 2

Proposal: Technique to handle package dependency gridlock
by Tom Murphy 01 Aug '12

01 Aug '12

We've got a problem with dependencies: http://cdsmith.wordpress.com/2011/01/21/a-recap-about-cabal-and-haskell-lib… http://cdsmith.wordpress.com/2011/01/17/the-butterfly-effect-in-cabal/ http://www.reddit.com/r/haskell/comments/x4knd/what_is_the_reason_for_haske… I'd like to present a proto-proposal for another arrow in our quiver. First, a few... Principles: This problem isn't uniquely Haskell's ...Although it may be uniquely Haskell's to solve. Lots of languages have a problem managing their package dependencies. To quote Chris Smith, "it’s fair to say that perhaps Haskell is one of the few environments where we’ve got a prayer at solving the problem." It's a magnitude problem The trick is to not find one perfect solution; it's to use enough effective solutions that the remaining tricky cases can be swept away individually. Solving the problem will most likely involve several techniques (good versioning policy, a little work on the part of package maintainers, smarter Cabal, new tools, etc.). Once we get the problem down to a manageable level, then it's a problem that can be dealt with package-by-package. Haskell packages are not black boxes Inheriting - from the imperative world - the idea of packages as indivisible units may be a mistake. A language like Ruby may have to import a full library, because it's nearly-impossible to reason about the behavior of part of it in isolation from the rest of it. Haskell's not like that, though! Referential transparency gives us awesome powers to reason about a pure function's behavior in nearly all cases. We could define package dependency in terms of providing functions-that-behave-like-the-ones-we-used. I mean, for god's sake, we can write QuickCheck properties like `quickSort == bubbleSort` and test it with a very high degree of assurance. The ability to pass the same suite of QuickCheck tests, or even the ability to pass a test like `fmap-3.1.2 == fmap 3.1.3`, could be strong enough proof - in the vast majority of cases - of functions' equivalence and therefore interchangeability. This could ease a significant number of package version constraints. Call it Property-Based Versioning - where your packages dependencies are based on which other versions of the package can provide the same functionality *for the functions and types that your package uses*. Programmer time is precious Thus far, the package dependency issue has been more or less a tug-of-war between package maintainers not wanting to do more work, and package users not wanting to do more work. Users just want to use the packages. Maintainers have a potentially-endless list of versions to check compatibility for ("I'm using foo-2.5.3. I assume anything 2.3 or greater is fine. Should I check through and see if 2.4 works? 2.3? 2.2? [...]"). Not to mention they can't know what the future will hold for later versions of the dependent packages, and they have to make a usually-pretty-uneducated guess about the future. Instead of maintainers and users, maybe computers should lift some of the load. Huge swaths of the most-used packages on Hackage are pure functions and data types. These are relatively easy to reason about, and if we could come close to reducing our dependency problem by, say, 30-50%, that would in my view put us within striking distance of having a very smoothly-running package ecosystem. These are decisions the community has to make There are lots of decisions to make and tradeoffs to balance. The main reason that I'm presenting such an embryonic description of this technique is to see what the Haskell community values most. In my view the ideal would be to be able to write a dependency description like "This package needs functions that behave like the ones I used in foo-3.1.2". A potentially less hair-shirty way to get some of the same functionality is for package authors to have a cabal-install or pre-cabal-install tool that determines which functions and data types are used from a package, finds equivalent ones in other packages, and write a dependency spec based on its findings (this wouldn't have anything to say about compatibility of not-yet-written packages, of course). Tom

1 0