- Haskell-Cafe - Haskell.org

a library for abstract algebra?
by Petr Pudlák 19 Apr '13

19 Apr '13

Hi, is there a Haskell library for defining and working with algebraic structures such as groups, rings, fields, finite fields, vector spaces or modules? I found only several vector-related libraries, but they were all only over the field of real numbers (Double) and defined only vector spaces, not other algebraic structures. Thanks, Petr

5 4

ANN: Groundhog 0.3 - mysql, schemas and enhanced queries
by Boris Lykah 19 Apr '13

19 Apr '13

I am happy to announce release of Groundhog 0.3! Groundhog is a library for high-level database access. It has support for Sqlite, PostgreSQL, and a new MySQL backend. Advanced migration capabilities allow you to precisely specify the schema description, fitting it to an existing database, or creating a migration script for a new one. Groundhog is not opinionated about schema and can bind your datatypes to a relational model which may have composite keys, references across different schemas, indexes, etc. Changes: * Novel mechanism for defining your own functions, operators, or other expressions and combining them in a type-safe manner. The operators LIKE and IN, which appeared in this version, are one-liners based on it. Now you can write advanced queries compositionally without resorting to raw SQL. For example: project (upper (ZipCodeField `append` AddressField), NumberField * (NumberField + (1 :: Int))) $ lower NameField `like` "jack%" will be transformed into SQL query SELECT upper(zipcode || address), number * (number + ?) FROM tablename WHERE lower(name) like ? * PostgreSQL backend got support for arrays and geometric datatypes. * First release of MySQL backend (influenced by persistent-mysql). * New class ConnectionManager helps to extract connections from pools, application state, or other sources. Now both plain connections and pools can be run with the same function runDbConn. In particular, this class helps with integrating Groundhog into web applications. * Support for savepoints (nested transactions). * Schema qualified tables. The entities can be configured with a schema parameter. It defines schema where the table, its triggers, indexes, and other related database objects are stored. Schemas are respected both during migration and when generating queries. * Custom primary keys. A unique set of fields can be defined as a constraint, index, or primary key. Composite primary keys are supported as well. * Configuration of reference clauses ON DELETE and ON UPDATE. * New class SchemaAnalyzer exposes Groundhog functions for database introspection. In future it can be used to build more powerful migration tools, or generate datatypes from table definitions. The full description of the configuration options is available at http://hackage.haskell.org/packages/archive/groundhog-th/0.3.0/doc/html/Dat… Please see examples at http://github.com/lykahb/groundhog/tree/master/examples. If you want to integrate Groundhog into your application which is based on Snap, Yesod, or just uses another monad to store connections, see this example http://github.com/lykahb/groundhog/blob/master/examples/monadIntegration.hs. Although there are many new features in this release, Groundhog API is mature enough to minimize the breaking changes. To migrate from Groundhog 2.* replace runSqliteConn/runPostgresqlConn/runSqlitePool/runPostgresqlPool with runDbConn. Special thanks to MightyByte who suggested to generalize connections and helped to find the design, and to many others who gave their inspiring feedback. * http://github.com/lykahb/groundhog * http://hackage.haskell.org/package/groundhog * http://hackage.haskell.org/package/groundhog-th * http://hackage.haskell.org/package/groundhog-mysql * http://hackage.haskell.org/package/groundhog-postgresql * http://hackage.haskell.org/package/groundhog-sqlite Enjoy! -- Regards, Boris

2 2

Unit Testing with Control.Proxy
by Dan 19 Apr '13

19 Apr '13

Hi all, I've discovered the excellent proxy library recently and one thing strikes me. How do you unit test a proxy? Are there any specific methods or workflows for doing this cleanly and consistently? Daniel -- ~~ Whatever happens, the sun's still gonna come up tomorrow ~~

2 1

Map Reduce spec in Haskell
by John D. Ramsdell 18 Apr '13

18 Apr '13

I'm learning about the Map Reduce computation frequently used with big data. For the fun of it, I decided to write a very high-level spec of Map Reduce. Here is what I came up with. Enjoy. John > module MapReduce where > import Data.List (nub) A high-level specification of Map Reduce as a Haskell program. The program uses lists to represent multisets. As multisets have no implied ordering, the ordering implied by lists in this specification should be ignored. The database is a multiset of key-value pairs. > type Key = String > type Value = String > type Datum = (Key, Value) > type Data = [Datum] A mapper maps a datum to a finite multiset of key-value pairs. > type Mapper = Datum -> Data A reducer takes a key and a multiset of values and produces a finite multiset of values. > type Reducer = (Key, [Value]) -> [Value] A step is a mapper followed by a reducer > type Step = (Mapper, Reducer) A program is a finite sequence of steps > type Program = [Step] The semantics of a program is provided by the run function. > run :: Program -> Data -> Data > run [] d = d > run (s : p) d = > run p (step s d) The three parts of a step are mapping, shuffling, and reducing. > step :: Step -> Data -> Data > step (m, r) d = > let mapped = transform m d > shuffled = shuffle mapped in > reduce r shuffled The first part of a step is to transform the data by applying the mapper to each datum and collecting the results. > transform :: Mapper -> Data -> Data > transform m d = > [p | u <- d, p <- m u] Next, values with common keys are collected. Keys are unique after shuffling. > shuffle :: Data -> [(Key, [Value])] > shuffle d = > [(k, vs) | k <- nub (map fst d), -- nub eliminates duplicate keys > let vs = [v | (k', v) <- d, k' == k]] A reducer is applied to the data associated with one key, and always produces data with that key. > reduce :: Reducer -> [(Key, [Value])] -> Data > reduce r rs = > [(k, v) | (k, vs) <- rs, v <- r (k, vs)]

3 2

how do i get cabal to reinstall dependencies with profiling enabled?
by Anatoly Yakovenko 18 Apr '13

18 Apr '13

3 2

Contravariant applicatives, monads and arrows (was ANN: rematch, an library for composable assertions with human readable failure messages)
by Alejandro Serrano Mena 18 Apr '13

18 Apr '13

Hi, First of all, let me say that this work on matchers is really useful :) Following Roman advice, I'm trying to find a more principled approach that could be useful for this library. It seems that "Match" could easily be converted to Either and thus made into Functor, Applicative, Alternative and Monad. That would allow to write things like: User <$> runMatch (isNot isEmpty) name <*> runMatch (hasItem (is '@')) email However, I'm also thinking about the correct way to "combine" matchers to get bigger matchers. Basically, if I have matchers on every field of a record, can I get a matcher for the entire one? My first idea was to make Matcher a functor. However, what I come was a contravariant functor: given (a -> b) and Matcher b, I can easily construct a Matcher a by running the one in b over this function. So we have: contramap :: (a -> b) -> Matcher b -> Matcher a My first question is: is there any structure similar to applicative functors or monads which work on these kind of contravariant functors? This also brought into my mind to see Matcher a just as functions a -> Match and derive its properties from there. This may give better results that the above mentioned idea of looking it as a -> Either String a, because in this latter case we have a in covariant and contravariant positions and it's difficult to get anything. On the other hand, it seems very easy, from a Matcher a and a Matcher b, to get a Matcher (a,b). This reminds me a bit about arrows, but without output parameters. Does it make sense? I've always been reluctant to arrows because I don't fully understand them, but maybe this is a good moment to learn. Do any of this make sense? I would really like to contribute to this great library! :) 2013/4/16 Tom Crayford <tcrayford(a)gmail.com>: > Roman, > > Thanks for the feedback! I'd originally left the QuickCheck and HUnit > implementations in this library for convenience, thinking that there aren't > going to be many people who care about the transitive dep. But you care, so > I'm happy moving them out of core. I'll release a 0.2 with both the HUnit > and the QuickCheck runners in separate libraries soonish. > > Thanks for the haddock tip and the implementation tips. > > Re the Control namespace, these matchers aren't exclusively a testing tool. > I've been using the core api for other purposes as well (primarily for > validating forms in user interfaces in conjunction with digestive-functors). > I couldn't figure anything better to put it in apart from Control (I > definitely don't want it in Test, even though that's going to be what most > people use it for). I guess it could be in `Data`, but that doesn't sound > much better to me. > > I'm not amazingly strong at building more principled interfaces right now, > so I guess that's something I'll improve on. Are there any concrete > suggestions you have there? I'd *like* these to have an `Alternative` > instance, but making `Applicative`/`Functor` instances is beyond me right > now (I guess I'd have to change the core API for that to work out). > > Tom > > > ...

3 3

Call for Papers: Workshop on Functional Art, Music, Modeling, and Design (colocated with ICFP)
by Brent Yorgey 18 Apr '13

18 Apr '13

====================================================================== FARM 2013: Call for Papers ACM SIGPLAN Workshop on Functional Art, Music, Modeling and Design Boston, Massachusetts, USA 28th September, 2013 (directly after ICFP) http://www.cis.upenn.edu/~byorgey/farm13/ ====================================================================== Scope ----- The functional programming community is largely interested in writing beautiful programs. This workshop is intended to gather researchers and practitioners interested in writing beautiful programs that generate beautiful artifacts. Such artifacts may include visual art, music, 3D sculptures, animations, GUIs, video games, physical models, architectural models, choreographies for dance, poetry, and even physical objects such as VLSI layouts, GPU configurations, or mechanical engineering designs. The framework used need not be purely functional (“mostly functional” is fine); may be based on abstractions such as higher-order functions, monads, arrows, or streams; and may be manifested as a domain specific language or tool. Theoretical foundations, language design, implementation issues, and applications are all within the scope of the workshop. Important dates --------------- - Submissions due: Friday, 14 June 2013, 23:59 UTC-11 (American Samoa time [1]) - Author notification: Thursday, 11 July 2013 - Final papers due: Thursday, 25 July 2013 - Workshop: Saturday, 28 September 2013 (the day after ICFP) [1] http://www.timeanddate.com/worldclock/fixedtime.html?msg=FARM+submissions+d… Proceedings ----------- There will be a formal proceedings published by ACM Press. Accepted papers will be included in the ACM Digital Library; see http://authors.acm.org/main.cfm for information on the options available to authors. Authors are also encouraged to submit auxiliary material for publication along with their paper (source code, data, videos, images, etc.); authors retain all rights to the auxiliary material. Submission details ------------------ We solicit submissions in two categories: - Full papers. A full paper is limited to 12 pages, and will be evaluated according to its relevance, correctness, significance, originality, and clarity. It should explain its contributions, identify what has been accomplished, explain why it is significant, and compare it with previous work. - "Aesthetic applications". An aesthetic application paper is limited to 6 pages, and will be judged primarily on the effective and elegant use of FP to generate aesthetic artifacts (though the criteria for full papers are still relevant). Submitted papers should be in portable document format (PDF), formatted using the ACM SIGPLAN style guidelines. The text should be in a 9-point font in two columns. Submissions can be made via EasyChair at https://www.easychair.org/conferences/?conf=farm2013 Organizers ---------- Workshop Chair: Paul Hudak Program Chair: Conal Elliott Publicity Chair: Brent Yorgey Program Committee ----------------- Daniel Cukier (AgileAndArt) Conal Elliott (Tabula) (chair) Kathleen Fisher (Tufts University) Richard Gabriel (IBM Research) George Giorgidze (University of Tübingen) Paul Hudak (Yale University) José Pedro Magalhães (University of Oxford) Alex McLean (ICSRiM) John Peterson (Western State Colorado University) Michael Sperber (Active Group) Henning Thielemann (Martin-Luther-Universität Halle-Wittenberg) Brent Yorgey (University of Pennsylvania)

1 0

Re: [Haskell-cafe] Contravariant applicatives, monads and arrows (was ANN: rematch, an library for composable assertions with human readable failure messages)
by Stephen Tetley 17 Apr '13

17 Apr '13

On 16 April 2013 16:12, Alejandro Serrano Mena <trupill(a)gmail.com> wrote: > Hi, > First of all, let me say that this work on matchers is really useful :) > > Following Roman advice, I'm trying to find a more principled approach > that could be useful for this library. It seems that "Match" could > easily be converted to Either and thus made into Functor, Applicative, > Alternative and Monad. That would allow to write things like: > Have you seen Ralf Hinze, Johan Jeuring and Andreas Loeh's paper on Contracts? The found their Contract datatype formed a comonad - at the time this seemed to be one of the few (non-synthetic) uses of comonads.

2 1

ANN: algebraic-classes, conversions between algebraic classes and F-algebras
by Sjoerd Visscher 17 Apr '13

17 Apr '13

Hi all, I'd like to announce a hopefully useful new package: algebraic-classes. In short it provides conversions between algebraic classes and F-algebras, which should make generating instances of certain classes easier. Algebraic classes are classes where every method has the same result type, which is the class parameter. Examples are Num and Monoid. F-algebras are functions of the form f a -> a, with f a functor, which can be called the signature of the algebra. They are equivalent as follows: Algebraic classes are signatures, and the instances of algebraic classes are specific algebras. Take for example the Monoid class: class Monoid a where mempty :: a mappend :: a -> a -> a The equivalent signature would be: data MonoidSignature a = Op_mempty | Op_mappend a a And the list instance instance Monoid [a] where mempty = [] mappend = (++) would be equivalent to the algebra: listAlgebra :: MonoidSignature [a] -> [a] listAlgebra Op_mempty = [] listAlgebra (Op_mappend a b) = a ++ b And there is an obvious monoid algebra for any Monoid instance: evaluate :: Monoid a => MonoidSignature a -> a evaluate Op_mempty = mempty evaluate (Op_mappend a b) = mappend a b Using Template Haskell, the algebraic-classes library can generate signatures and evaluation functions from algebraic classes, and class instances from algebras. Also, for the signatures Functor and Traversable are derived using the DeriveFunctor and DeriveTraversable. That makes it possible to create algebras generically for any signature in certain cases, which together with the conversions means you can generate instances generically. Take tuples for example: if given that both components are instances of a class, then we can create the algebra as follows: algebra :: (Functor f, Class f m, Class f n) => f (m, n) -> (m, n) algebra fmn = (evaluate (fmap fst fmn), evaluate (fmap snd fmn)) And for any applicative functor we can do the same: algebra :: (Traversable f, Applicative g, Class f a) => f (g a) -> g a algebra = fmap evaluate . sequenceA Taken all together, all you have to do to get for example the Monoid instance for Either a b (based on its applicative instance) is: deriveInstance [t| Monoid b => Monoid (Either a b) |] The package lives on Hackage here: http://hackage.haskell.org/package/algebraic-classes And if you have suggestions, issues (the Template Haskell code is far from perfect at the moment) or pull-request, it is also on Github: https://github.com/sjoerdvisscher/algebraic-classes greetings, Sjoerd Visscher

1 0

Haskell missing in web benchmark
by Jeffrey Shaw 17 Apr '13

17 Apr '13

I was excited to see if Warp or Snap was included, but I was sad to see they weren't. If I find time someday, I'll add benchmarks for them, but it will be a long time. If anyone else wants to take a stab at it, that'd be awesome! http://www.techempower.com/blog/2013/03/28/framework-benchmarks/ Jeff

3 2