I noticed that in the previous version, the function foldThrist was essentially a foldr with a type signature that was overly restrictive.

For instance, one could not define an identity function on Thrists in terms of the foldThrist function, the way one can with regular lists, e.g.:

foldr (:) [] [1..4] == [1,2,3,4]

Other additions followed as I tried to define the Thrist equivalent of many useful list functions. For example I wanted to define a foldl-like function that we could use to reverse a Thrist.

Check out the release announcement on Gabor’s blog, along with his draft paper on Thrists.

A Brief Thrist Primer

A Thrist is a type-threaded list. This is easiest explained with an example:


*Data.Thrist> :t Cons (True,'z')$ Cons ('a',"bar")$ Cons ("foo",3.14) Nil
Cons (True,'z')$ Cons ('a',"bar")$ Cons ("foo",3.14) Nil
:: (Fractional c) => Thrist (,) Bool c


As you can see, unlike the regular haskell list type which takes a single type for each element, the Thrist takes a single binary type (in the case above we have the tuple type: (,)) for each element, whose type arguments are chained together. So the second type argument of one cell must be the same type as the first type argument of the following cell, and so on.

The two arguments that are visible in the outer Thrist type itself are the first argument of the first cell, and the second argument of the last cell. In the example above those would be Bool (taken from the True value fst of the head of our Thrist), and some as-yet-undetermined Fractional type (our 3.14 value).

This type of cool data structure is only possible because of GADTs which let us enforce the type-threading and allow us to have all these types inside the Thrist without having them show up in the type signature.

Here is how the Thrist GADT is defined:

data Thrist :: (* -> * -> *) -> * -> * -> * where
  Nil :: Thrist (~>) a a
  Cons :: (a ~> b) -> Thrist (~>) b c -> Thrist (~>) a c

Here is another example of a Thrist in which the binary type element is a function:

*Data.Thrist> :t Cons head $ Cons fst $ Cons not Nil
Cons head $ Cons fst $ Cons not Nil
    :: Thrist (->) [(Bool, b)] Bool

It might look odd to see (->) used by itself as an argument to a type signature, but a Thrist of functions is actually pretty cool. We can actual fold the Thrist using function composition:

*Data.Thrist> :t foldl1Thrist (flip (.)) $ Cons head $ Cons fst $ Cons not Nil
foldl1Thrist (flip (.))$ Cons head $ Cons fst $ Cons not Nil
:: [(Bool, b)] -> Bool

Notice how similar the Thrist definition is to the composed function. You can see how the Thrist generalizes function composition to a certain extent.

$> cabal install Befunge93

If you want to read about how I designed it you can check out the source above, or take a look at my previous blog post.

Please report any bugs to me, and I’m also very interested in patches or suggestions for performance improvements if anyone ends up being interested in this program.

EDIT: Here is the package page: http://hackage.haskell.org/package/Befunge93

We will be using Lennart Augustsson’s numbers library which can be installed from hackage with cabal-install:

$> cabal install numbers

Consider two functions: the Prelude function sum and genericLength from the List library:

 genericLength :: (Num i) => [b] -> i
 sum :: (Num a) => [a] -> a

…two simple functions that have the potential to be very expensive, depending on the length of the list and the values of the elements.

Say for instance that all we want is to use:

The checkLengths function above has to count every element of every element of every sub-list in order to return a Bool value, and if any of those lists are infinite our program will never terminate:

…or so we might think!

Lazy Natural Numbers

It turns out we can solve our seemingly hopeless situation with a type signature:

And suddenly, as if by magic:

*LazyArithmetic> hopeless
True

What’s going on here? Well it turns out the problem is that Haskell’s built-in numeric types are boring, old-fashioned and (in some cases) just plain wrong. But let’s step behind the curtain and look at how the Data.Numbers library defines the Natural type internally:

 data Natural = Z | S Natural

We see that we’re using an abstract data type to represent non-negative integers, and it looks nearly identical to our list type []. The upshot of that is we gain, in our numeric type and arithmetic operations, the same type of laziness that lists afford us!

So in the above example, hopeless, we need only carry out the operations far enough to see that the result is > 2.

The numeric type in Data.List.Natural are actually known as Peano numbers. They are essentially just lists of units and, as you might imagine, are not the most efficient way to represent an integer.

But they are exactly what we want for this application. If we failed to realize that we could solve our problem with an appropriate numeric representation, we might try to rig up something like this:

…which works identically to checkLengths with Peano Numbers, but completely obfuscates the intention of the function. As usual laziness gives us expressive power rather than an efficiency boost.

Limitations, Haskell’s Numeric Type Classes, and the Numeric Prelude

The Data.Number.Natural library is convenient because it provides Num and Integral instances so we can use the the Natural type with any function that is polymorphic on those classes.

The problem is the Num instance is incomplete and error-prone: and that’s because a natural number type shouldn’t be an instance of Num! We can’t negate a Natural, which in turn makes subtraction dangerous, etc.

*LazyArithmetic> let x = 1 :: Natural; y = 2 in x - y
*** Exception: Natural: (-)

We might wish that haskell’s Numeric type classes were more expressive, allowing for more abstract numeric types. For example it might be more “haskelly” for the length function to be defined with the type:

 length :: Natural n => [a] -> n

After all we don’t use integers for boolean values as in C; we have the abstract type Bool. So why return an Int when a Natural type (or class) might be more expressive? The answer of course is that that gets really complicated really fast.

For one approach at making haskell’s numeric class hierarchy more expressive and flexible, check out the Numeric Prelude. It’s haddock documentation is very thorough and an interesting read, and you can see the sheer number of design decisions necessary for such an undertaking.

For some other approaches and links, see here.

It’s very likely there are some bugs, especially related to cross platform issues with file names and paths. The module is also fairly bare, so please send me any requests for functionality that I haven’t thought of, as well as any bugs you might find.

You can install it with:

$ cabal install directory-tree

And get the source with:

$ darcs get http://coder.bsimmons.name/code/DirectoryTree/

I hope this is useful to someone!

UPDATE: I’ve just released v0.9.0 of this package which has a number of sneaky changes and additions, most notably the inclusion of a readDirectoryWithL function that allows for lazy directory reading IO. This will let users work with a DirTree read from disk just as if it was a pure lazy data structure, while IO is done in the background as needed. No more exploding code! (hopefully)