[Haskell-cafe] flatten a nested list

[Conor McBride]

Hi

pphetra wrote:

> Compare to a Lisp solution, It 's not looking good.
> Any suggestion.


I'm trying to understand what your issue is here. What's not looking
good?

> I would like to write a program that can do something like this.
 
> ;; lisp syntax

I suppose, if it were the implementation of flattening that was the issue,
you'd have shown us the Lisp version.

> I end up like this.
>
> data Store a = E a | S [Store a]
>              deriving (Show)
> 
> flat :: [Store a] -> [a]
> flat [] = []
> flat ((E x):xs) = [x] ++ flat xs
> flat ((S x):xs) = flat x ++ flat xs

That's a reasonable datatype to pick for finitely-branching trees. You're
working a little hard on the function. Here's mine

flat1 :: Store a -> [a]
flat1 (E a)   = return a
flat1 (S xs)  = xs >>= flat1

Your (flat xs) on a list of stores becomes my (xs >>= flat1), systematically
lifting the operation on a single store to lists of them and concatenating the
results. The return operation makes a singleton from an element. This way of
working with lists by singleton and concatenation is exactly the monadic
structure which goes with the list type, so you get it from the library by
choosing to work with list types. In Haskell, when you choose a typed
representation for data, you are not only choosing a way of containing the data
but also a way to structure the computations you can express on that data.

Or is your issue more superficial? Is it just that

> * (my-flatten '(1 (2 (3 4) 5)))
> (1 2 3 4 5)

looks shorter than

> so
> *Main> flat [E 1, S[E 2, S[E 3, E 4], E 5]]
> [1,2,3,4,5]

because finitely branching trees of atoms is more-or-less the native data
structure of Lisp? Is it the Es and Ss which offend? No big deal, surely.
It just makes test input a little more tedious to type.

I'm guessing your Lisp implementation of my-flatten is using some sort of atom
test to distinguish between elements and sequences, where the Haskell version
explicitly codes the result of that test, together with its meaning: pattern
matching combines discrimination with selection. The payoff for explicitly
separating E from S is that the program becomes abstract with respect to elements.
What if you wanted to flatten a nested list of expressions where the expressions
did not have an atomic representation?

The point, I guess, is that type system carries the structure of the computation.
If you start from less structured Lisp data, you need to dig out more of the
structure by ad hoc methods. There's more structure hiding in this example, which
would make it even neater, hence the exercises at the end...

But I hope this helps to make the trade-offs clearer.

All the best

Conor

PS exercises for the over-enthusiastic

  import Data.Foldable
  import Data.Traversable
  import Control.Applicative
  import Data.Monoid

Now consider (or discover!) the 'free monad' construction:

  data Free sig a = Var a | Op (sig (Free sig a))

(1) Show that if sig is a Functor then Free sig is a Monad, with (>>=) behaving
like substitution for terms built over the signature sig.

(2) Show that if sig is Traversable then Free sig is Traversable.

(3) Replace the above 'Store' with a type synonym by substituting other characters
for ? in

  type Store = Free ??

(4) Replace the ?s with other characters to complete the following definition
  
  splat :: (Traversable f, Applicative a, Monoid (a x)) => f x -> a x
  splat = ????????????

in such a way that the special case

  splat :: Store a -> [a]

behaves like flat1 above.