Archive for January, 2010

Higher-order Polymorphism for pseudo-Java

Thursday, January 28th, 2010
// Simulate Higher-Order Functions.
// A lambda function is any implementation of this interface.
interface Lambda<X, Y> {
  Y apply(X x);
}
 
// What is a covariant functor?
// It is any implementation of this interface.
// All implementations must also satisfy:
//   * The law of identity
//   * The law of composition
// (but let's brush that to the side)
interface Functor<F> {
  <A, B> F<B> fmap(F<A> a, Lambda<A, B> f);
}
 
import java.util.LinkedList;
 
// Here is the functor for Java's LinkedList.
// It maps a function across each element of the list and returns a new one.
// (trust me, it satisfies the two laws).
class LinkedListFunctor implements Functor<LinkedList> {
  public <A, B> LinkedList<B> fmap(final LinkedList<A> a, final Lambda<A, B> f) {
    final LinkedList<B> r = new LinkedList<B>();
    for(final A x : a)
      r.append(f.apply(x));
    return r;
  }
}
 
// Here is a trivial Java data type.
// It happens to be a covariant functor.
// Let's witness its instance...
interface IntConverter<A> {
  A convert(int i);
}
 
// The Functor instance for the IntConverter.
class IntConverterFunctor implements Functor<IntConverter> {
  public <A, B> IntConverter<B> fmap(final IntConverter<A> a, final Lambda<A, B> f) {
    return new IntConverter<B>() {
      public B convert(final int i) {
        return f.apply(a.convert(i));
      }
    };
  }
}
 
// So why do we care?
// Because it prevents an enormous (*enormous*, *ENORMOUS!*)
// amount of otherwise needless repetition.
 
class FunctorX {
  // Gives rise to:
  // LinkedList<Lambda<A, B>> => A => LinkedList<B>
  // IntConverter<Lambda<A, B>> => A => IntConverter<B>
  // ...
  // F<Lambda<A, B>> => A => F<B> (for many values of F)
  public static <A, B, F> F<B> fapply(final Functor<F> f, final F<Lambda<A, B>> lam, final A a) {
    return f.fmap(lam, new Lambda<Lambda<A, B>, B>() {
      public B apply(final Lambda<A, B> z) {
        return z.apply(a);
      }
    });
  }
 
  // ... etcetra.
}
 
// It turns a linear amount of code into a constant amount of code.
// Similarly a sort function that runs on lists of
// any type (provided a comparator) alleviates the need for linear
// amounts of code (a sort function for each possible list element type).

MSN/Yahoo! web spiders blocked

Sunday, January 24th, 2010

I have blocked the msnbot and yahoo! web spiders from indexing this site (and all others at this IP address). They choke up the network with distributed multiple connections. Pretty silly/primitive technique of indexing a web site.

What is Haskell’s primary feature?

Friday, January 22nd, 2010

Today I was asked what Haskell’s main feature is. The answer is its non-strict evaluation.

Java is a strictly evaluated language. Consider this Java program:

class C {
  static String i() {
    throw new Error("boo!");
  }
 
  static <A> int f(A a) {
    return 3;
  }
 
  public static void main(String[] args) {
    int k = f(i());
    System.out.println(k);
  }
}

The program fails with a runtime error.

Consider this (otherwise equivalent) Haskell program:

i = error "boo!"
 
f a = 3
 
main = let k = f i
       in print k

The program prints 3 and does not fail like the Java program. This is a key property of Haskell with very far reaching implications. One of those implications is that Haskell is a pure language. There are many more implications, particularly with respect to the compositional properties of programs.

Haskell’s evaluation model and its implications is perhaps its most widely misunderstood feature. While the benefits are (enormously) enormous, they are far too deep to consider writing a short article about.

Dear Java guy, State is a monad

Tuesday, January 19th, 2010
interface Pair<A, B> {
  A first();
  B second();
}
 
class Pairs {
  public static <A, B> Pair<A, B> pair(final A a, final B b) {
    return new Pair<A, B>() {
      public A first() { return a; }
      public B second() { return b; }
    };
  }
}
 
interface State<S, A> {
  Pair<S, A> run(S s);
}
 
interface Function<X, Y> {
  Y apply(X x);
}
 
class States {
  // State<S, _> is a covariant functor
  public static <S, A, B> State<S, B> map(final State<S, A> s, final Function<A, B> f) {
    return new State<S, B>() {
      public Pair<S, B> run(final S k) {
        final Pair<S, A> p = s.run(k);
        return Pairs.pair(p.first(), f.apply(p.second()));
      }
    };
  }
 
  // // State<S, _> is a monad
  public static <S, A, B> State<S, B> bind(final State<S, A> s, final Function<A, State<S, B>> f) {
    return new State<S, B>() {
      public Pair<S, B> run(final S k) {
        final Pair<S, A> p = s.run(k);
        return f.apply(p.second()).run(p.first());
      }
    };
  }
}

What Does Monad Mean?

Thursday, January 14th, 2010

Slides
http://projects.tmorris.net/public/what-does-monad-mean/artifacts/1.1/chunk-html/index.html

Video
http://vimeo.com/8729673

Parsing map data using a lazy language

Sunday, January 10th, 2010

Haskell is a pure lazy programming language. The laziness of Haskell allows certain performance improvements without sacrificing compositional program properties. I have recently written parsers for XML map data formats that allow a user to “read a data file into a collection of immutable objects.” If I told you I used the parser library to “read in” a 140GB map data file and you’re not familiar with a lazy language, you might have asked how I did this within the constraints of memory requirements. Easy of course; I used a lazy language. The implications of a lazy (and therefore, pure) language are widely misunderstood, so I say “easy” wishing it really was easy for all people, but I know it isn’t (keep practicing!).

HXT is a parsing library for XML that is based on Hughes’ arrows and allows a user to piece together their own specific XML parser. I used it to parse the GPS Exchange (GPX) and OpenStreetMap (OSM) data formats.

Here are some example uses of parsing GPX files and here are examples parsing OSM files. My favourite is a very simple example (there are more complex ones) that removes waypoints from a GPX file. This question (how to remove waypoints from gpx?) was asked on the OSM mailing list quite a while ago; questions like these partially inspired me to write these libraries.

import Data.Geo.GPX
 
removeWpts :: FilePath -> FilePath -> IO ()
removeWpts = flip interactGpx (usingWpts (const []))

The implementation is very simple. The interactGpx function takes two file names and a function that transforms a Gpx data structure to a new Gpx. The interactGpx function reads in the first given file name to a Gpx, executes the given function to produce a new Gpx, then writes the result to the other given file name.

interactGpx :: FilePath -> (Gpx -> Gpx) -> FilePath -> IO ()

The usingWpts function takes a function that transforms a list of waypoints to a new list of waypoints and a Gpx value and returns a new Gpx value with the waypoints transformed.

usingWpts :: ([WptType] -> [WptType]) -> Gpx -> Gpx

Of course, since we want to remove all waypoints, we ignore the given list of waypoints and return an empty list (const []). Pretty neat I reckon!

You can get either of these libraries from hackage:

Here is each of their home page: