News aggregator

Haskell as a "hobby".

Haskell on Reddit - Mon, 11/24/2014 - 3:09pm

Yesterday I randomly bumped into Haskell and have been intrigued ever since. I’ve looked through introductory/intermediate videos and read into the first chapters of “Real World Haskell” and “Learn You a Haskell for Great Good”. From what I actually HAVE understood, I see that there is a lot of elegance and interesting aspects to the language. And I absolutely understand why Haskell has a reputation for a steep learning curve that can melt your brain. But I think that’s good!

Thing is, I don’t have a background in CS. I’m actually of the design type, just with a strong interest in technical stuff. I know my way around the elementary webtechnologies, have an interest in generative design and dabble with physical computing/Arduino. But all this is for pure fun. I would never call myself a programmer nor do I intend to make a living as one anytime in the future. I just think programming is kinda… relaxing. (After you overcome bouts of laptop-smashing frustration).

My current drug of choice is Processing, since it’s taylor-made for visual output which I aim at with generative design. “Duh!”, I hear you say, “how dare you compare this dumbed-down piece of Java with our excellent Haskell?!”. I know, I know… hear me out. For me programming is not about flexible, maintainable, high-quality software, but rather bringing my visual ideas to fruition. Often times with code so damn fugly, any self-respecting programmer would run to the woods and bite into a tree out of pure rage. But… I find Haskell so very intriguing. And I’d like to try and tackle it. But I don’t know if I should. Because I know I’ve just scratched the very surface of understanding the full power of the language and maybe what I want to do (mainly visual-centric output) is just batshit insane and/or overkill doing with Haskell.

As a reference, I’m currently working my way through Dan Shiffmans’ “Nature of Code”, learning all about physics systems, autonomous agents, fractals, simulation of evolution, etc. All as a means of finding new ways to create generative visuals.

So now I’m asking you, dearest community, if you could help me make a decision. Is it okay/sensible/sane of me to have a go at Haskell as fresh diversion from what I know through Processing? Maybe it can allow me to do things which are difficult/unthinkable with more traditional languages? Or am I on the completely wrong path?

Thanks for any feedback and opinions!

submitted by sevennationsalami
[link] [50 comments]
Categories: Incoming News

Gabriel Gonzalez: How to build library-agnostic streaming sources

Planet Haskell - Mon, 11/24/2014 - 8:56am

The Haskell ecosystem has numerous libraries for effectful stream programming, including, but not limited to:

  • List
  • conduit
  • enumerator
  • io-streams
  • iterIO
  • iteratee
  • list-t
  • logict
  • machines
  • pipes

Unfortunately, this poses a problem for library writers. Which streaming library should they pick when providing effectful streaming components?

Sometimes the correct answer is: none of the above! We can often build streaming and effectful generators using only the base and transformers libraries!

The trick is to build polymorphic generators using only the MonadPlus and MonadTrans type classes. These generators can then be consumed by any library that provides an implementation of ListT that implements MonadPlus and MonadTrans.


I like to think of MonadPlus as the "list building" type class. This is because you can assemble a list using return, mzero, and mplus:

>>> import Control.Monad (MonadPlus(..))
>>> mzero :: [Int]
>>> return 1 :: [Int]
>>> return 1 `mplus` return 2 :: [Int] -- [1] ++ [2]
[1, 2]

In other words, mzero is analogous to [], mplus is analogous to (++), and return builds a singleton list.

However, many things other than lists implement MonadPlus, including every implementation of ListT in the wild. Therefore, if we build collections using MonadPlus operations these collections will type-check as ListT streams as well.

Let's provide the following helper function to convert a list to this more general MonadPlus type:

select :: MonadPlus m => [a] -> m a
select [] = mzero
select (x:xs) = return x `mplus` select xs

-- or: select = foldr (\x m -> return x `mplus` m) mzero

Note that this select function has some nice mathematical properties:

select (xs `mplus` ys) = (select xs) `mplus` (select ys)
select mzero = mzero

-- This assumes the distributivity law for `MonadPlus`
select . (f >=> g) = (select . f) >=> (select . g)
select . return = returnMonadTrans

Using select and lift (from MonadTrans), we can build list comprehensions that interleave effects, like this:

example :: (MonadTrans t, MonadPlus (t IO)) => t IO ()
example = do
x <- select [1, 2, 3]
lift (putStrLn ("x = " ++ show x))
y <- select [4, 5, 6]
lift (putStrLn ("y = " ++ show y))

You can read the above code as saying:

  • Let x range from 1 to 3
  • Print x every time it selects a new value
  • For each value of x, let y range from 4 to 6
  • Print y every time it selects a new value

Notice how example doesn't depend on any particular streaming library, so we can run it with diverse ListT implementations, all of which implement MonadPlus and MonadTrans:

>>> Pipes.runListT example -- This requires `pipes-4.1.4`
x = 1
y = 4
y = 5
y = 6
x = 2
y = 4
y = 5
y = 6
x = 3
y = 4
y = 5
y = 6
>>> _ <- Control.Monad.Logic.observeAllT example
<Exact same output>
>>> _ <- ListT.toList example
<Exact same output>

However, we can use this trick for more than just list comprehensions. We can build arbitrary lazy and effectful streams this way!


Here's an example of a generator that lazily emits lines read from standard input:

import Control.Monad (MonadPlus(..))
import Control.Monad.Trans.Class (MonadTrans(..))
import System.IO (isEOF)

stdinLn :: (MonadTrans t, MonadPlus (t IO)) => t IO String
stdinLn = do
eof <- lift isEOF
if eof
then mzero
else lift getLine `mplus` stdinLn

You can read the above code as saying:

  • Check if we are at the end of the file
  • If we're done, then return an empty list
  • If we're not done, prepend a getLine onto a recursive call to stdinLn

We can prove this works by writing a program that forwards these lines to standard output:

echo :: (MonadTrans t, MonadPlus (t IO)) => t IO ()
echo = do
str <- stdinLn
lift (putStrLn str)

Now we can run echo using any of our favorite ListT implementations and it will do the right thing, streaming lines lazily from standard input to standard output in constant space:

>>> Pipes.runListT echo

The exception is the transformers library, whose ListT implementation does not stream or run in constant space.


We can also implement lazy variations on Control.Monad combinators using this interface.

For example, we can implement a lazy variation on replicateM using just select and replicate:

replicateM' :: MonadPlus m => Int -> m a -> m a
replicateM' n m = do
m' <- select (replicate n m)

-- or: replicateM' n = join . select . replicate n

We can use this lazy replicateM' to lazily echo 10 lines from standard input to standard output:

example :: (MonadTrans t, MonadPlus (t IO)) => t IO ()
example = do
str <- replicateM' 10 (lift getLine)
lift (putStrLn str)

We can also implement a lazy mapM and forM, too, except now their implementations are so trivial that they don't even deserve their own functions:

mapM' :: Monad m => (a -> m b) -> m a -> m b
mapM' = (=<<)

forM' :: MOnad m => m a -> (a -> m b) -> m a
forM' = (>>=)

example :: (MonadTrans t, MonadPlus (t IO)) => t IO ()
example = mapM' (lift . print) (replicateM' 10 (lift getLine))

Similarly, a lazy sequence just becomes join.


The following streaming libraries already provide their own implementation of ListT compatible with the above trick:

  • List
  • list-t
  • LogicT
  • pipes

The other streaming libraries do not currently provide a ListT implementation, but there is no reason why they couldn't! For example, conduit could implement an internal ListT type of its own and use that as an intermediate type for converting the above abstraction to the public Source type:

convert :: Monad m
=> Data.Conduit.Internal.ListT m a -> Source m a

This polymorphic API obviously does not capture all possible streaming patterns. For example, you can not implement something like take using this API. However, I suspect that a significant number of streaming components can be written using this dependency-free interface.

Edit: Twan van Laarhoven pointed out that you can sometimes use MonadIO instead of MonadTrans, which produces nicer constraints

Categories: Offsite Blogs

Ghc 7.8 binary packages for rhel 7 available/recommendation?

Haskell on Reddit - Mon, 11/24/2014 - 7:30am

I built it in 1 hour. But it seems too long for me if I only want to use ghc 7.8.3 on rhel 7. Is there pre-built version?

submitted by eccstartup
[link] [9 comments]
Categories: Incoming News

Philip Wadler: Towards Independence

Planet Haskell - Mon, 11/24/2014 - 4:51am
As an experiment, I have created a separate blog for political posts: Towards Independence.
Categories: Offsite Blogs

ekmett/ad - Mon, 11/24/2014 - 3:58am
Categories: Offsite Blogs

ekmett/ad - Mon, 11/24/2014 - 3:58am
Categories: Offsite Blogs

Manuel M T Chakravarty: Why are playgrounds compelling?

Planet Haskell - Sun, 11/23/2014 - 7:56pm

Hand in hand with Swift, Apple introduced the idea of a programming playground: a text editor with an integrated evaluation engine that facilities the visual inspection of program values and states. It isn’t a new idea. After all, Emacs had lisp interaction buffers since the dawn of modern computing.

However, Emacs buffers do lack the visual component, and Bret Victor discussed in great detail why visualisation and an ability for interactive manipulation of program states is so important. Nevertheless, the mere transition from a REPL to an interaction buffer (that is, text editor with integrated evaluation) is already a big deal.

Why? It makes an interactive session more functional and less stateful. Instead of being faced with the state of the REPL after a particular command, the playground is a buffer with all commands. A REPL state corresponds to a single line in the playground, as the playground reifies the REPL history. In other words, the move from REPL to playground is much like the move from mutable variable to time-varying value — a shift in perspective from an instant to the entire timeline.

Categories: Offsite Blogs - Sun, 11/23/2014 - 10:05am
Categories: Offsite Blogs - Sun, 11/23/2014 - 10:05am
Categories: Offsite Blogs