Archive for the 'Programming' Category

What Really Happened

Tuesday, March 9th, 2010
  • 28 July 2007 Ankle inversion sprain resulting in entrapment neuropathy of the superficial peroneal nerve 10 cm proximal to lateral malleolus. Continued athletic activity causes minor avulsions at the nerve root (L5/S1).
  • 15 September 2008 Surgical ligament repair, inadvertently putting further traction on the trapped superficial peroneal nerve. Avulsion of the nerve root completed. CSF leaks from the spinal cord into surrounding tissues. Psychiatric symptoms develop.
  • 04 November 2009 Surgical decompression of superficial peroneal nerve provides relief.
  • Today spinal injury. Lumbosacral Nerve Root Avulsion.

I have a spinal injury as a result of an otherwise innocent ankle sprain. This is due to the extreme negligence of medical practitioners. Dr Michael McEniery and Dr Rupert Leigh Atkinson are extremely dangerous people who should not be practicing medicine in any form. These people, who hold medical treatment hostage behind a barrier of extreme incompetence of the highest order, are the biggest threat to the safety of the general public that I have ever encountered (and I’ve visited a maximum security prison).

Next time I scream, please listen. You all heard me didn’t you?

Why are there no big applications written using functional languages?

Wednesday, February 24th, 2010

Because there is no such thing as a big application. There is only bigger or smaller. This is a central tenet of functional programming. “Big application” is a euphemism for “My idea of programming does not scale beyond this point.” You don’t realise how much information you give away when you ask this question.

So can we can stop with the piffle and get on with the interesting and important stuff? Ta.

Understanding Haskell interact

Wednesday, February 24th, 2010

There is a function in Haskell’s standard library called interact. It has this type interact :: (String -> String) -> IO ().

Here is the same function in Java:

import java.io.Console;
 
interface Stringer {
  String convertString(String s);
}
 
class Interact {
  // interact :: (String -> String) -> IO ()
  static void interact(Stringer s) {
    final String line = System.console().readLine();
    final String c = s.convertString(line);
    System.out.println(c);
    interact(s);
  }
}

There are some slight differences between the two:

  • In Java, we have had to give a name to the higher-order function (Stringer) with a single method which we have also named (convertString).
  • In Java, we have no guarantee that the implementation of Stringer that is passed to interact is deterministic. In other words, it might perform side-effects and we have no machine-checked guarantee that it will not.

The other major difference is with respect to the evaluation of the arguments. Haskell is call-by-need by default while Java is eagerly evaluated by force. This doesn’t have an impact on understanding the general purpose of Haskell’s interact function by looking at the same function in Java.

That is all. Hope it helps.

Linq has nothing to do with SQL or enumerable lists

Friday, February 19th, 2010

There seems to be quite a lot of misunderstanding of Linq. I am not sure how widespread this misunderstanding is, but if I can be persuaded that my selection sample extrapolates accurately, I might consider expanding on this fact:

Linq has nothing to do with SQL or enumerable lists. Nothing and also, not a single thing.

If this is contentious, please let me know and I will endeavour to do something about it (I already have, so I’ll just refer on to begin with).

SKI combinator calculus in Java

Monday, February 8th, 2010
interface Lam<X, Y> {
  Y apply(X x);
}
 
// http://en.wikipedia.org/wiki/SKI_combinator_calculus
class SKI {
  public static <A, B, C> Lam<Lam<A, Lam<B, C>>, Lam<Lam<A, B>, Lam<A, C>>> s() {
    return new Lam<Lam<A, Lam<B, C>>, Lam<Lam<A, B>, Lam<A, C>>>() {
      public Lam<Lam<A, B>, Lam<A, C>> apply(final Lam<A, Lam<B, C>> f) {
        return new Lam<Lam<A, B>, Lam<A, C>>() {
          public Lam<A, C> apply(final Lam<A, B> g) {
            return new Lam<A, C>() {
              public C apply(final A a) {
                return f.apply(a).apply(g.apply(a));
              }
            };
          }
        };
      }
    };
  }
 
  public static <A, B> Lam<A, Lam<B, A>> k() {
    return new Lam<A, Lam<B, A>>() {
      public Lam<B, A> apply(final A a) {
        return new Lam<B, A>() {
          public A apply(final B b) {
            return a;
          }
        };
      }
    };
  }
 
  public static <A> Lam<A, A> i() {
    return SKI.<A, Lam<A, A>, A>s().apply(SKI.<A, Lam<A, A>>k()).apply(SKI.<A, A>k());
  }
}

Functional Java 2.21

Friday, February 5th, 2010

Includes a number of bug fixes and an immutable 2-3 finger tree for sequences supporting access to the ends in amortized O(1) time.

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).

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