News aggregator

Roman Cheplyaka: Foldable, Traversable, and parametricity

Planet Haskell - Thu, 02/12/2015 - 2:00pm

The Foldable-Traversable proposal (aka FTP) has spawned a lot of debate in the Haskell community.

Here I want to analyze the specific concern which Ben Moseley raised in his post, FTP dangers.

Ben’s general point is that more polymorphic (specifically, ad-hoc polymorphic, i.e. using type classes) functions are less readable and reliable than their monomorphic counterparts.

On the other hand, Tony Morris and Chris Allen argue on twitter that polymorphic functions are more readable due to parametricity.

Is that true, however? Are the ad-hoc generalized functions more parametric than the monomorphic versions?

@shebang @dibblego is (a -> b) -> [a] -> [b] more parametric than Functor f => (a -> b) -> f a -> f b ?

— Je Suis Petit Gâteau (@bitemyapp) February 12, 2015 <script async="async" charset="utf-8" src="http://platform.twitter.com/widgets.js"></script>

Technically, the Functor-based type is more parametric. A function with type (a -> b) -> [a] -> [b] is something like map, except it may drop or duplicate some elements. On the other hand, Functor f => (a -> b) -> f a -> f b has to be fmap.

But this is a trick question! The first thing we see in the code is the function’s name, not its type. What carries more information, map or fmap? (Assuming both come from the current Prelude.) Certainly map. When fmap is instantiated at the list type, it is nothing more than map. When we see fmap, we know that it may or may not be map. When we see map, we know it is map and nothing else.

The paradox is that there are more functions with map’s type than fmap’s, but there are more functions with fmap’s name than map’s. Even though fmap is more parametric, that doesn’t win us much.

Nevertheless, is there a benefit in using more parametric functions in your code? No. If it were true, we’d all be pumping our code with «parametricity» by writing id 3 instead of 3. You can’t get more parametric than id.

Merely using parametric functions doesn’t make code better. Parametricity may pay off when we’re defining polymorphic parametric functions in our code instead of their monomorphic instantiations, since parametric types are more constrained and we’re more likely to get a compile error should we do anything stupid.

(It won’t necessarily pay off; the type variables and constraints do impose a tax on types’ readability.)

But if you have an existing, monomorphic piece of code that works with lists, simply replacing Data.List functions with Data.Foldable ones inside it, ceteris paribus, will not make your code any safer or more readable.

Categories: Offsite Blogs

Leon P Smith: Announcing blaze-builder-0.4

Planet Haskell - Thu, 02/12/2015 - 12:42pm

After a recent chat with Simon Meier, we decided that I would take over the maintenance of the exceedingly popular blaze-builder package.

Of course, this package has been largely superseded by the new builder shipped inside bytestring itself. The point of this new release is to offer a smooth migration path from the old to the new.

If you have a package that only uses the public interface of the old blaze-builder, all you should have to do is compile it against blaze-builder-0.4 and you will in fact be using the new builder. If your program fails to compile against the old public interface, or there’s any change in the semantics of your program, then please file a bug against my blaze-builder repository.

If you are looking for a function to convert Blaze.ByteString.Builder.Builder to Data.ByteString.Builder.Builder or back, it is id. These two types are exactly the same, as the former is just a re-export of the latter. Thus inter-operation between code that uses the old interface and the new should be efficient and painless.

The one caveat is that the old implementation has all but disappeared, and programs and libraries that touch the old internal modules will need to be updated.

This compatibility shim is especially important for those libraries that have the old blaze-builder as part of their public interface, as now you can move to the new builder without breaking your interface.

There are a few things to consider in order to make this transition as painless as possible, however: libraries that touch the old internals should probably move to the new bytestring builder as soon as possible, while those libraries who depend only on the public interface should probably hold off for a bit and continue to use this shim.

For example, blaze-builder is part of the public interface of both the Snap Framework and postgresql-simple. Snap touches the old internals, while postgresql-simple uses only the public interface. Both libraries are commonly used together in the same projects.

There would be some benefit to postgresql-simple to move to the new interface. However, let’s consider the hypothetical situation where postgresql-simple has transitioned, and Snap has not. This would cause problems for any project that 1.) depends on this compatibility shim for interacting with postgresql-simple, and 2.) uses Snap.

Any such project would have to put off upgrading postgresql-simple until Snap is updated, or interact with postgresql-simple through the new bytestring builder interface and continue to use the old blaze-builder interface for Snap. The latter option could range from anywhere from trivial to extremely painful, depending on how entangled the usage of Builders are between postgresql-simple and Snap.

By comparison, as long as postgresql-simple continues to use the public blaze-builder interface, it can easily use either the old or new implementation. If postgresql-simple holds off until after Snap makes the transition, then there’s little opportunity for these sorts of problems to arise.


Categories: Offsite Blogs

Leon P Smith: Announcing snaplet-postgresql-simple-0.6

Planet Haskell - Thu, 02/12/2015 - 11:16am

In the past, I’ve said some negative things1 about Doug Beardsley’s snaplet-postgresql-simple, and in this long overdue post, I retract my criticism.

The issue was that a connection from the pool wasn’t reserved for the duration of the transaction. This meant that the individual queries of a transaction could be issued on different connections, and that queries from other requests could be issued on the connection that’s in a transaction. Setting the maximum size of the pool to a single connection fixes the first problem, but not the second.

At Hac Phi 2014, Doug and I finally sat down and got serious about fixing this issue. The fix did require breaking the interface in a fairly minimal fashion. Snaplet-postgresql-simple now offers the withPG and liftPG operators that will exclusively reserve a single connection for a duration, and in turn uses withPG to implement withTransaction.

We were both amused by the fact that apparently a fair number of people have been using snaplet-postgresql-simple, even transactions in some cases, without obviously noticing the issue. One could speculate the reasons why, but Doug did mention that he pretty much never uses transactions. So in response, I came up with a list of five common use cases, the first three involve changing the database, and last two are useful even in a read-only context.

  1. All-or-nothing changes

    Transactions allow one to make a group of logically connected changes so that they either all reflected in the resulting state of the database, or that none of them are. So if anything fails before the commit, say due to a coding error or even something outside the control of software, the database isn’t polluted with partially applied changes.

  2. Bulk inserts

    Databases that provide durability, like PostgreSQL, are limited in the number of transactions per second by the rotational speed of the disk they are writing to. Thus individual DML statements are rather slow, as each PostgreSQL statement that isn’t run in an explicit transaction is run in its own individual, implicit transaction. Batching multiple insert statements into a single transaction is much faster.

    This use case is relatively less important when writing to a solid state disk, which is becoming increasingly common. Alternatively, postgresql allows a client program to turn synchronous_commit off for the connection or even just a single transaction, if sacrificing a small amount of durability is acceptable for the task at hand.

  3. Avoiding Race Conditions

    Transactional databases, like Software Transactional Memory, do not automatically eliminate all race conditions, they only provide a toolbox for avoiding and managing them. Transactions are the primary tool in both toolboxes, though there are considerable differences around the edges.

  4. Using Cursors

    Cursors are one of several methods to stream data out of PostgreSQL, and you’ll almost always want to use them inside a single transaction.2 One advantage that cursors have over the other streaming methods is that one can interleave the cursor with other queries, updates, and cursors over the same connection, and within the same transaction.

  5. Running multiple queries against a single snapshot

    If you use the REPEATABLE READ or higher isolation level, then every query in the transaction will be executed on a single snapshot of the database.

So I no longer have any reservations about using snaplet-postgresql-simple if it is a good fit for your application, and I do recommend that you learn to use transactions effectively if you are using Postgres. Perhaps in a future post, I’ll write a bit about picking an isolation level for your postgres transactions.

  1. See for example, some of my comments in the github issue thread on this topic, and the reddit thread which is referenced in the issue.

  2. There is the WITH HOLD option for keeping a cursor open after a transaction commits, but this just runs the cursor to completion, storing the data in a temporary table. Which might occasionally be acceptable in some contexts, but is definitely not streaming.


Categories: Offsite Blogs

Is there any fast, industrial strength lambda calculator, that reduces a LC term to its normal form, even inside abstractions?

Haskell on Reddit - Thu, 02/12/2015 - 10:42am

I'm interested in a programming language that allows me to write a lambda term such as:

(λ k → ((λ a → k a) (λ x → x)))

And get, as result, its normal form:

(λ k → k (λ x → x))

I want the interpreter to normalize even inside abstractions. This is obviously impossible in Haskell itself since, as a practical (and lazy) language, it uses closures and doesn't allow for function inspection. So, if you write:

f k = (\ a -> k a) (\ x -> x)

There isn't really any way to ask GHC for f's normal form. I could easily write a lambda calculus DSL on Haskell, yes, but, as any DSL, it wouldn't be as efficient as I want. I'm looking for an industrial strength, fast lambda calculator. There are many toy/educational lambda calculators around, but I'm looking for something that can normalize large scale programs efficiently. Any idea?

submitted by SrPeixinho
[link] [6 comments]
Categories: Incoming News

Refactoring question

Haskell on Reddit - Thu, 02/12/2015 - 4:47am

Hello all

I'm working with some code that is basically building up commands to be processed. The idea would be that you can say something like:

fetch $ Field `eq` 10 -- NOTE: which type we're filtering on is inferred from context

as well as:

fetch $ ParentField `j` ChildField `j` ChildChildField `eq` 10

So I ended up with:

fetch :: (a -> commands) -> m [a] j :: (cl, commands) -> cr -> (clr, commands) eq :: (c, commands) -> cval -> ct -> commands -- NOTE: ct here is just used to force eq to match fetch's return context

But this leaves me having to provide a special function for making the first column suitable to compose with the rest of them.

j' :: c -> (c, commands) j' c = (c, []) -- Just an example, not actual implementation

So I didn't like a few things about this. I didn't like that the initial commands had to be done on the first column instead of fed in by fetch. So I factored the tuple of column + commands to be a function that takes commands and returns the column + commands tuple. This puts me at:

fetch :: (a -> commands -> commands) -> m [a] j :: (commands -> (cl, commands)) -> cr -> commands -> (clr, commands) eq :: (commands -> (c, commands)) -> cval -> ct -> commands -> commands

Which composes as before, but now instead of having to supply an empty commands for the first column, I have to "lift" it like this

fetch $ (\x -> (ParentField, x)) `j` ChildField `j` ChildChildField `eq` 10

or in the case of a single column

fetch $ (\x -> (Field, x)) `eq` 10

I think what is throwing me off here is that I'm working with functions that need two arguments, where as a straight implementation of State monad would take one argument [1].

There must be a way to clean up this interface though. I looked into arrows to see if they could help me, but so far I haven't come up with anything. Anyone have any ideas?

[1] What I mean here is that the "lift" function obviously looks like State return/pure and the j function looks like >>= for state except for that extra cr parameter.

submitted by nicheComicsProject
[link] [1 comment]
Categories: Incoming News

Composing arguments

Haskell on Reddit - Thu, 02/12/2015 - 4:09am

While developing a visual representation for Haskell I noticed again the similarity between applying a function to several arguments and applying a composition of functions to a single argument. This lead me to thinking about composing arguments. Here's the code:

{-# LANGUAGE RankNTypes #-} type WFull a b = (a -> b) -> b type WSame a = WFull a a type W a = forall b . (a -> b) -> b wrap :: a -> WFull a b wrap x = ($ x) unwrap :: WSame a -> a unwrap x = x id apply :: WSame a -> (a -> b) -> WFull b c apply f x = wrap $ x (unwrap f) composeArgs :: (a -> b) -> (b -> c) -> a -> c x `composeArgs` y = (y.x) composeFunc :: WSame (b -> c) -> WSame (a -> b) -> WFull (a -> c) d composeFunc f g = wrap $ (unwrap f).(unwrap g)

To use it:

> ((*).(+2)) 3 4 > 20 > unwrap $ apply (wrap (*) `composeFunc` wrap (+2)) (wrap 3 `composeArgs` wrap 4) > 20

A version of this code that uses an abstract data type is on Github here. My conclusion is that a visual language that has argument composition would still represent valid Haskell programs.

Edit: Removed "realized" since the focus of this post is composing arguments.

submitted by RobbieGleichman
[link] [22 comments]
Categories: Incoming News

FTP dangers

Haskell on Reddit - Thu, 02/12/2015 - 3:44am
Categories: Incoming News

Discussion: Add unboxed mutable references somewhere sensible

libraries list - Thu, 02/12/2015 - 2:03am
The problem they solve is perhaps not as well known as it should be: Code that frequently modifies an `STRef Int`, for example, will typically surprise the programmer by allocating a ton of memory. This happens because the reference holds a *boxed* Int. Code like modifySTRef ref (+1) will allocate a new Int box every time. To the best of my knowledge, GHC makes no attempt to figure out if this is actually necessary and do something about it. The Data.Ref.Unboxed module in the ArrayRef package attempts to address this, but it doesn't seem to get much visibility, and its code hasn't been touched since 2009. What can we do about this?
Categories: Offsite Discussion

Does Haskell have any use in real world? That can not be acomplished by traditional sequential programming (iterative, I believe it's called).

Haskell on Reddit - Wed, 02/11/2015 - 11:43pm

Most of the applications I've seen are just remakes of some other ones but in Haskell. Based on this, why should I give up a good chunk of my time to learn Haskell than giving up a good chunk of my time to learn more about say C++ (OpenGL, Unreal etc) or C# (QT, Unity).

submitted by Zyborg23
[link] [12 comments]
Categories: Incoming News

GHC Hackaton (GHC internals) slides

haskell-cafe - Wed, 02/11/2015 - 10:55pm
Anybody knows if the slides (or higher quality video) for the GHC Hackaton are available? I'm not sure which year, this video has been posted in 2012: https://www.youtube.com/watch?v=lw7kbUvAmK4&list=PLBkRCigjPwyeCSD_DFxpd246YIF7_RDDI Thanks! Maurizio _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Categories: Offsite Discussion

Applying for Haskell opportunities at Facebook

haskell-cafe - Wed, 02/11/2015 - 10:24pm
Hi I am a student in the University of Nottingham in year 2 and I am quite interested in Haskell. May I apply for the summer internship in this summer in London? I have learnt Haskell during the module Introduction to Functional Programming last Year and have the highest mark among the student from Ningbo campus. I could solve countdown problem and sudoku right now. I know Monad and know the basic idea about that. This semester I take the module Advanced Functional Programming taught by professor Graham Hutton. By the end of this semester, i will be good at monad using and learn more about the efficiency about the programming. Apart from Haskell, I also good at algorithm and Java programming. I deal the entire image processing procedure algorithm with a candy detect application. https://github.com/ZongzheYuan/ImageProcessing.git Here is my code and i am improving it continuously. I really looking forward to working at FaceBook and especially with Haskell. If i could have this opportunity, it will become m
Categories: Offsite Discussion

Applying for Haskell opportunities at Facebook

haskell-cafe - Wed, 02/11/2015 - 10:15pm
Hi I am a student in the University of Nottingham in year 2 and I am quite interested in Haskell. May I apply for the summer internship in this summer in London? I have learnt Haskell during the module Introduction to Functional Programming last Year and have the highest mark among the student from Ningbo campus. I could solve countdown problem and sudoku right now. I know Monad and know the basic idea about that. This semester I take the module Advanced Functional Programming taught by professor Graham Hutton. By the end of this semester, i will be good at monad using and learn more about the efficiency about the programming. Apart from Haskell, I also good at algorithm and Java programming. I deal the entire image processing procedure algorithm with a candy detect application. https://github.com/ZongzheYuan/ImageProcessing.git Here is my code and i am improving it continuously. I really looking forward to working at FaceBook and especially with Haskell. If i could have this opportunity, it will become m
Categories: Offsite Discussion

Applying for Haskell opportunities at Facebook

haskell-cafe - Wed, 02/11/2015 - 10:15pm
Hi I am a student in the University of Nottingham in year 2 and I am quite interested in Haskell. May I apply for the summer internship in this summer in London? I have learnt Haskell during the module Introduction to Functional Programming last Year and have the highest mark among the student from Ningbo campus. I could solve countdown problem and sudoku right now. I know Monad and know the basic idea about that. This semester I take the module Advanced Functional Programming taught by professor Graham Hutton. By the end of this semester, i will be good at monad using and learn more about the efficiency about the programming. Apart from Haskell, I also good at algorithm and Java programming. I deal the entire image processing procedure algorithm with a candy detect application. https://github.com/ZongzheYuan/ImageProcessing.git Here is my code and i am improving it continuously. I really looking forward to working at FaceBook and especially with Haskell. If i could have this opportunity, it will become m
Categories: Offsite Discussion

Rationale for two separate map functions inClassyPrelude

haskell-cafe - Wed, 02/11/2015 - 9:00pm
ClassyPrelude has two map functions, namely: 1. "map" 2. "omap" "map" works on any Functor. However, things like "Text" are not functors as they aren't generic containers. As can be seen in the following code: module Main where import Prelude () import ClassyPrelude import qualified Data.Text as T import Data.Char as C main = do let l = [1,2,3] :: [Int] let t = (T.pack "Hello") let m = Just 5 print $ map (*2) l print $ map (*2) m print $ omap C.toUpper t return () Notice one has to use "omap" to deal with the Text. The thing is, I found it trivially easy to get "map" to work for both calls. Here's the code: {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeFamilies #-} module Main where import Prelude hiding (map) import qualified Data.Text as T import Data.Char as C import Control.Monad (Functor) class CanMap a b where type Element a :: * type Container a b :: * map :: (Element a -> b) -> a -> Container a b instance (Functor f) =>
Categories: Offsite Discussion

Is there a good, succinct, metaphor-free Monad tutorial?

Haskell on Reddit - Wed, 02/11/2015 - 8:56pm

A couple months ago, after finally "getting" Monads and do-notation, I was hit with a sense that the answer was very anti-climactic. I was also kind of annoyed, because it felt like this allegedly-complicated thing could be explained much more succinctly, without any cute language, without any metaphors, without allusions to any other programming languages, and in a way that really sticks.

Basically, start by assuming a competent reader.

Then demonstrate data types, and then pattern-based overloading.

Don't say things like, "Haskell is about composability". (That meant nothing for a few chapters.)

Instead, talk about:

  • function-composition operators like the '.' in "f . g x" (and '.' is a great starting point, because most people remember it from math class);
  • the fact that such operators allow chaining as in "f3 . f2 . f1 x" (again, easy-to-grasp);
  • if they know any POSIX shell scripting (or even scripting with cmd.exe), talk about the shell pipe operator as another kind of function-composition operator that allows chaining with "command1 <x | command2 | command3" (ok, so there's one metaphor, except that it's not that far off);
  • the fact that Haskell encourages the use of many different kinds of function-composition operators;
  • the fact that >>= is one such operator, which naturally leads into
  • the fact that >>= allows operations on x to be chained as in "x >>= f1 >>= f2 >>= f3"; and
  • the fact that >>= is defined using the same pattern-based overloading mentioned earlier (so that the >>= evaluated at run-time depends on the left-side operand).

Then talk about do-notation de-sugaring, monad laws to show when the nesting lambdas are equivalent to the above chaining... and then you're pretty much done.

(And if they're confused in any particular part of that, they can ask, and we can answer with a couple of simple examples.)

Then you can talk about composability.

For someone with experience in C, C++, Python, or Java, that should be doable in a very short time.

And then the reader (or viewer---maybe it should be a Khan Academy-style video) can understand simple programs that use IO inside do-notation in main, and then they can understand why such programs can behave correctly even though, at first glance, they don't seem to check e.g. for EOF or the absence of IO errors.

Wouldn't it have been nice if all that had been laid out for you on day one so that you could actually make sense of small, practical programs?

But then, maybe I just didn't look in the right place. Does a tutorial like that exist already?

[EDIT] /u/bss03 was one of several to give me a good reason why I don't want to try writing any such tutorial at this time.

False alarm, everyone! (:

Thanks to everyone who posted a link, especially Dan Burton, who just re-posted his Zero-Analogy blog entry in response to this thread.

[EDIT 2] Do any of these links belong in the sidebar?

submitted by 0wx
[link] [101 comments]
Categories: Incoming News

Regex-applicative and Data.Text

haskell-cafe - Wed, 02/11/2015 - 1:07pm
I just tried some regex-applicative and it's amazing! Very nice library, thanks Roman! However, I can't figure out the best way to work with Data.Text.Text instead of String. The token would be Text, I guess, but then it breaks in composition, since type of `few anySym` would now return `[Text]`, not `Text`. Am I understanding this correctly that intention is to in issue #8? [0] Or is there a clever way to work with them today? Example code: {-# LANGUAGE OverloadedStrings #-} import qualified Data.Text as T import Data.Text (Text) import Text.Regex.Applicative main = do let input = "foo:\n--- blablabla\ttheend" let r1 = sym "foo:\n" *> sym "--- " *> few anySym <* sym "\t" <* few anySym :: RE Text Text putStrLn (show (input =~ r1)) Error is something like (this is an error for a bit different code, but should be very similar): Main.hs:14:40: Couldn't match type ‘[Text]’ with ‘Text’ Expected type: RE Text Text Actual type: RE Text [Text]
Categories: Offsite Discussion

Anonymous FFI calls

haskell-cafe - Wed, 02/11/2015 - 12:26pm
Hi, I am in a situation where it would be very useful to call C functions without an explicit FFI import. For example, I'd like to be able to do (foreign import ccall "cadd" :: CInt -> CInt -> CInt) 1 2 instead of declaring the foreign import explicitely at the top level. Is there a way to do this or to achieve similar results in some other way? If not, I imagine it would be easy to implement such a facility in GHC, given that the code implementing calling to C functions must already be present to implement "proper" FFI imports. I think such an addition would be useful in many cases. Thanks, Francesco
Categories: Offsite Discussion

svgcairo/ghc vis cabal install error..

haskell-cafe - Wed, 02/11/2015 - 5:57am
Hi !, I tried installing svgcairo ( for installing ghc vis ). I am getting following error. Could you please help me out install ghc vis. Thanks in advance Madhu — environment details. I am on mac yosomite with gcc provided by OS X. Following is the gcc —version 22:54:34:~$ gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/opt/X11/lib/pkgconfig export LDFLAGS=-L/usr/local/lib export CFLAGS=-I/usr/local/include export LIBS=-L/usr/local/lib svgcairo error =============== Configuring svgcairo-0.13.0.1... Building svgcairo-0.13.0.1... Preprocessing library svgcairo-0.13.0.1... gtk2hsC2hs: Error in C header file. /usr/include/sys/qos.h:124: (column 34) [FATAL] >>> Syntax error! The symbol `__attribute__' does not fit here. cabal: Error: some package
Categories: Offsite Discussion