My Diversions

September 28, 2007

Simplifying Code

Filed under: Computer Science, Java — Tom Davies @ 2:50 am

In the course of trying to adapt an ANTLR lexer to be used in an Intellij IDEA language plugin, I found that I’d written this:

token = lexer.nextToken();
if (token != null)
{
    tokenStart = findCharPos(token.getLine(), token.getColumn());

    if (token.getText() == null)
    {
        tokenEnd = tokenStart;
    }
    else
    {
        tokenEnd = tokenStart + token.getText().length() - 1;
        state = tokenEnd;
    }
    if (token.getType() == 1)
    {
        state = -1;
    }
}
else
{
    tokenStart = 0;
    tokenEnd = 0;
    state = -1;
}

What a mess! Which parts of the code influence the final value of tokenEnd? Should state be modified in the token.getText() == null case?

The problem with the code above is that it is structured as cases of the state of token, rather than as the functions which determine the values of the three variables.

I changed it to:

token = lexer.nextToken();
tokenStart = calcTokenStart(token);
tokenEnd = calcTokenEnd(tokenStart, token);
state = calcState(tokenEnd, token);
...
private int calcTokenStart(Token token)
{
    return token == null ? 0 : findCharPos(token.getLine(), token.getColumn());
}

private int calcTokenEnd(int tokenStart, Token token)
{
    if (token == null)
    {
        return 0;
    }
    else
    {
        String tokenText = token.getText();
        return tokenText == null ? tokenStart : tokenStart + tokenText.length();
    }
}

private int calcState(int tokenEnd, Token token)
{
    if (token == null || token.getType() == 1)
    {
        return -1;
    }
    else
    {
        return tokenEnd;
    }
}

This shows us each calculation in isolation, and allows us to see its dependencies.Note that this isn’t an ‘extract method’ refactoring — it comes from changing your view of the function from ‘processing a new token’ to ‘calculating the new values of the three state variables’.

Note that the functions above don’t use the state of the object, even though, for instance, this.tokenStart has been assigned when calcTokenEnd is called. That would reduce the clarity of the solution.

In fact, unless this class was specifically designed to be extensible, perhaps making these functions static would be clearer and safer.

September 24, 2007

CAL and the Tapestry 5 Tutorial

Filed under: CAL and Open Quark, Computer Science, Tapestry — Tom Davies @ 10:13 pm

The technique described in my previous post can be used to create Tapestry 5 pages which call CAL functions. Tapestry also uses Javassist to enhance pages, so adding CAL integration requires that Tapestry is reconfigured to apply the CAL transformations in addition to its own — I wasn’t able to find a way to transparently modify the classes before Tapestry sees them.

I’ve modified the Hi/Lo Guessing Game from the Tapestry Tutorial to use CAL implementations for some functions:

(more…)

September 23, 2007

Javassist and Annotations for Interfacing Java to CAL

Filed under: CAL and Open Quark, Computer Science — Tom Davies @ 6:41 am

In order for CAL to interoperate with Java frameworks we need to provide a Java class which delegates method calls to CAL functions. The framework sees only the Java class, and is unaware of the delegation which is taking place.

How we do this depends on a number of factors:

  • How easy it is to hook into the class/object creation process used by the framework.
  • Whether you need a Java class there at compile-time — perhaps you’ll be using a mixture of Java and CAL, so that you need an interface or a class to compile against, or perhaps the only use the framework will make will make of the class is reflectively at runtime, in which case the entire class can be synthesised.

In both cases we want the minimum amount of textual overhead, and the ability to type check our code as early as possible.

The first method I’ll describe uses Javassist:

(more…)

September 17, 2007

Quote of the day, Tyler Cowen on Google

Filed under: Computer Science, Economics, General Interest — Tom Davies @ 5:46 am

“Everyone is smart and beautiful, and I didn’t want to leave.”

Interfacing CAL to Java Frameworks — Part 1

Filed under: CAL and Open Quark, Computer Science — Tom Davies @ 4:14 am

This article discusses the differences between CAL as a client of Java libraries and CAL modules as clients of Java frameworks.

CAL is a functional programming language which runs on the JVM. One of the advantages of a language which compiles to Java bytecode is that it is simple to call any of the many available Java libraries from CAL.

(more…)

September 15, 2007

I’ll miss you, SCO

Filed under: Computer Science — Tom Davies @ 6:20 am

Perhaps not many people will miss SCO, given their desperate intellectual property shenanigans, but I only remember the good times.

My second job out of university was at an investment bank, Dominguez Barry Samuel Montagu, as the co-developer of an equities options trading system. We had a brand new Compaq 80386, running at 16MHz. I don’t recall how much memory or disk that machine had — perhaps 1MB and 40MB, but it was an exciting machine to have at that point in time. Unfortunately the existing system, while well written, ran on Windows 3.11, with 16 bit addressing and the memory and performance problems that entailed. The 386 was actually a very nice processor, as long as you ran it in 32 bit mode, and so I convinced my boss to buy SCO Xenix, newly available for the 386. This made a vast difference to the performance of the application — once we got an 80387 with two sigma signs printed on it (the 80387 was a floating point co-processor — the 80386 not having any floating point hardware. And early versions had a hardware bug which froze the system occasionally.)

SCO made that job much more enjoyable for me, and the success of a Unix based system ensured that future projects were also done on Unix rather than Microsoft platforms (for pedants, of course Xenix is a Microsoft platform).

So I’ll remember SCO for what it was, not what it became, which is the right way to think about any lost love.

September 5, 2007

Not what you expect from Apple

Filed under: Dull Carping, General Interest — Tom Davies @ 3:32 pm

While the new iPods look fine, I was surprised to see the mess that was Apple’s Australian web site at 7:25 AM this morning.

apple.jpg

Broken images everywhere and copy which refers to the old iPod nano. Surely the updates should have been ready for weeks, and deploying them should be a press of a button!

September 2, 2007

Escape from Zurg

Filed under: Computer Science, Mercury — Tom Davies @ 4:05 am

This Lambda the Ultimate post links to a paper which compares writing a search algorithm in Prolog and Haskell, and notes that Haskell’s strong typing makes the task easier. While the paper mentions several embeddings of logic programming into functional languages it doesn’t mention Mercury.

I was able to easily create successor and goal predicates for this problem which work with the breadth first searching predicate I wrote earlier. Note that there is one significant shortcoming in my implementation — because I use lists where I should be using sets in the representation of nodes in my search space, nodes which should be equal are not, so the search takes far longer than it should. But it makes the point that Mercury’s discriminated unions and type system give a Prolog-like language the same benefit which Haskell’s type system gives a functional one.

The code for the solve client follows:

(more…)

Powered by WordPress