Brief review: The Little MLer

Sunday, 31st May, 2015

book details

“The Little MLer”
Matthias Felleisen and Daniel P. Friedman
MIT Press


I had resolved not to learn any new languages in 2015, but: I knew if I were to learn a language it would probably be ML (or some kind of proof assistant type thing); this book was on my Amazon Wish List; and MIT Press had a half price sale.

I’m afraid I was quite underwhelmed by The Little MLer. It brings upon itself comparison with The Little Schemer: the same dialogue format, the same illustrator (with “guest appearances” by the Little Schemer elephants), even occasional “in-jokes” about Lisp. It suffers greatly under this comparison.

Lisp is not a normal programming language. The basic building blocks of Lisp — list; first thing in list; rest of list — are so simple — naively, childishly simple, even romantically simple (steady on — Ed.). So the childish dialogue approach in The Little Schemer, with virtually no presuppositions really is plausible, and even appropriate. I thought the book effectively conveyed the charm and wonder of Lisp.

I’m not qualified to say much sensible about ML, but this book felt contrived — the tried and tested dialogue format forced onto an unsuspecting programming language (in the same style there’s also A Little Java and A Few Patterns). The Little Schemer was full of “stout Cortez” moments; The Little MLer had one: a brief exploration of what might have been lazy evaluation.

I have a gut feeling that ML could be an exciting language, but The Little MLer is a dull exposition following an imported schema.

My plan for this year is to bring in the clients, write the apps, and make some money. Being anything other than ruthlessly pragmatic about learning new programming languages is distinctly not part of the plan. This year is about focussing and consolidating, it is not about wandering about smelling the roses.

However, …

Separate from programming, I am following up some of my reading from last year. In particular, Hegel (I’m finally tackling his Phenomenology of Spirit) and Schrödinger (his book and Weyl’s book both look worth a try; and Schrödinger’s paper on colour looks like it might be a good introduction to some of the geometry).

Learning about the strong link between Schrödinger and Weyl was quite a revelation. Weyl was also associated with Brouwer and the intuitionist/constructivist approach to maths. The ncatlab page on constructive maths mentions Hegel in its prehistory section.

So, sometime later in the year I’ll be reading about Brouwer, his mathematical intuitionism, and constructivism. As part of that, I might be “doing” some maths.

Doing constructive maths seems to involve proofs, verifications of proofs, and even mechanisations of verifications. Things called proof assistants can be used. So quite possibly I’ll be trying out one or more of these proof assistants.

To the untrained eye these proof assistant things look a lot like programming languages.

That Giant’s Causeway puzzle in Prolog

Tuesday, 13th January, 2015

Chris Lamb published a very nice blog post the other day showing a wooden logic puzzle he’d found, and implementing a solver in Python.

It was such a nice post I thought I’d write one in Prolog. Here it is (and in a gist):

% hex tiles puzzle
% -
% -

:- use_module(library(clpfd)).  %% for all_different/1

%% tile(Name, Colours).

% tiles from picture
% tile(11, [red, blue, black, yellow, green, white]).
% tile(22, [white, black, yellow, green, blue, red]).
% tile(33, [green, blue, black, yellow, red, white]).
% tile(44, [white, black, red, green, blue, yellow]).
% tile(55, [white, blue, green, yellow, black, red]).
% tile(66, [white, yellow, red, blue, black, green]).
% tile(77, [red, yellow, green, black, blue, white]).

% re-jigged a bit
tile(11, [white, black, red, green, blue, yellow]).
tile(22, [white, black, yellow, green, blue, red]).
tile(33, [white, blue, green, yellow, black, red]).
tile(44, [white, green, blue, black, yellow, red]).
tile(55, [white, red, blue, black, yellow, green]).
tile(66, [white, red, yellow, green, black, blue]).
tile(77, [white, yellow, red, blue, black, green]).

%% only six rotations allowed


%% rotate(List1, NStepsAntiClockwise, List2). 

rotate(Cs, 0, Cs).
rotate([A,B,C,D,E,F], 1, [B,C,D,E,F,A]).
rotate([A,B,C,D,E,F], 2, [C,D,E,F,A,B]).
rotate([A,B,C,D,E,F], 3, [D,E,F,A,B,C]).
rotate([A,B,C,D,E,F], 4, [E,F,A,B,C,D]).
rotate([A,B,C,D,E,F], 5, [F,A,B,C,D,E]).

%% colour(Name, Rotation, Position, Colour).

colour(N, R, P, C):-
    tile(N, Cs),
    X is (P + R) mod 6,
    nth0(X, Cs, C).

same_colour(N1, R1, P1, N2, R2, P2):-
    colour(N1, R1, P1, C),
    colour(N2, R2, P2, C).

solve(N1, R1, N2, R2, N3, R3, N4, R4, N5, R5, N6, R6, N7, R7):-
    all_different([N1, N2, N3, N4, N5, N6, N7]),

    same_colour(N1, R1, 3, N2, R2, 0),
    same_colour(N1, R1, 4, N4, R4, 1),
    same_colour(N1, R1, 5, N3, R3, 2),
    same_colour(N2, R2, 4, N5, R5, 1),
    same_colour(N2, R2, 5, N4, R4, 2),
    same_colour(N3, R3, 3, N4, R4, 0),
    same_colour(N3, R3, 4, N6, R6, 1),
    same_colour(N4, R4, 3, N5, R5, 0),
    same_colour(N4, R4, 4, N7, R7, 1),
    same_colour(N4, R4, 5, N6, R6, 2),
    same_colour(N5, R5, 5, N7, R7, 2),
    same_colour(N6, R6, 3, N7, R7, 0).

show(N, R):-
    tile(N, Cs),
    rotate(Cs, R, Rs),
    format("~d    ~w~n", [N, Rs]).

    solve(N1, R1, N2, R2, N3, R3, N4, R4, N5, R5, N6, R6, N7, R7),
    show(N1, R1),
    show(N2, R2),
    show(N3, R3),
    show(N4, R4),
    show(N5, R5),
    show(N6, R6),
    show(N7, R7).

Sergii Dymchenko recently posted a blog showing how a “greater than” sudoku can be solved with constraint logic programming and ECLiPSe CLP.

Sergii’s post inspired me to do the same for answer setprogramming, with clasp/gringo. I’ve uploaded the code to github.

Brief notes on ASP (& Sudoku)

I am just getting started with answer set prolog. Here are some first impressions:

Syntactically, it is very similar to Good Old Fashioned Prolog, with one or two additions. For example:

syntactic sugar

There’s a lot of sugar enabling concise code. e.g.,


expands to


headless predicates

A predicate without a head is known as a constraint. The sense is that the specified conjunction is not true.

:- paint(R, C1, N), paint(R, C2, N), C1 != C2.

In the sudoku code, paint/3 is a fact signifying that a cell at Row and Column has Number. The constraint above states that in a given row, a number can be at most one column.

multi-headed predicates

There seem to be various kinds of multi-headed predicates, with accompanying sugar for concise representation. A common construct is

1 { paint(R, C, P) : number(P) } 1 :- square(R, C).

The part of the head inside brackets is like a set comprehension and expands to

paint(R, C, 1) | paint(R, C, 2) | ... | paint(R, C, 8) | paint(R, C, 9).

Having this kind of disjunction in the head gives a kind of indeterminism: this disjunction is true if the body of the predicate is true.

The numbers to either side of the brackets put lower and upper bounds on the number of facts that this disjunction can introduce. So, in plain English, this predicate says something like “every square should be given exactly one number”.


Semantically there is a difference too. We understand an answer set prolog program as representing a set of states of affairs, where a state of affairs is a set of true facts (i.e., including no facts of the form ‘not P’).

Things like how many states of affairs, and which facts from each state of affairs, are reported to the user are dealt with by declarations (like #show in the sudoku script) and command line arguments.

In practice, this means that instead of passing round a data structure between predicates (e.g., a list of lists for a sudoku grid), statements inside predicates can be made which directly affect the database (i.e., the state of affairs) — e.g., the paint/3 statements scattered about sudoku.lp.

Describing it just now, that sounds scarily like global variables.

Extras for “Greater Than”

As a “Greater Than” Sudoku is just an ordinary sudoku with an extra constraint, I’ve put the required extra predicate lessEqual/4 in a separate script, sudoku_extra_gt.lp

The question grid is just the set of facts that we have initially. With standard sudoku, it’s the cell that have been given numbers, e.g., puzzle_easy.lp:

paint(1, 1, 7).
paint(1, 3, 3).
paint(1, 5, 8).
paint(1, 8, 1).
paint(2, 5, 6).
paint(3, 1, 6).
% ...

QUESTION FOR ASP EXPERTS: at first I tried “positive” constraints with a greaterThan/4 predicate, like this

% ...

but these seemed to be ignored in the answer set. Why? How should I have phrased it?

Running the solver on this Greater Than sudoku shows the paint predicates which are true given all the constraints:

$ clingo 0 puzzle_gt.lp sudoku.lp sudoku_extra_gt.lp
clingo version 4.4.0
Reading from puzzle_gt.lp ...
Answer: 1
paint(8,1,1) paint(2,2,1) paint(6,3,1) paint(5,4,1) paint(9,5,1) paint(3,6,1)
paint(4,7,1) paint(7,8,1) paint(1,9,1) paint(3,1,2) paint(6,2,2) paint(8,3,2)
paint(2,4,2) paint(4,5,2) paint(7,6,2) paint(1,7,2) paint(5,8,2) paint(9,9,2)
paint(6,1,3) paint(1,2,3) paint(7,3,3) paint(4,4,3) paint(2,5,3) paint(8,6,3)
paint(9,7,3) paint(3,8,3) paint(5,9,3) paint(5,1,4) paint(7,2,4) paint(1,3,4)
paint(3,4,4) paint(6,5,4) paint(9,6,4) paint(8,7,4) paint(4,8,4) paint(2,9,4)
paint(9,1,5) paint(4,2,5) paint(2,3,5) paint(7,4,5) paint(3,5,5) paint(5,6,5)
paint(6,7,5) paint(1,8,5) paint(8,9,5) paint(4,1,6) paint(8,2,6) paint(3,3,6)
paint(9,4,6) paint(1,5,6) paint(6,6,6) paint(5,7,6) paint(2,8,6) paint(7,9,6)
paint(7,1,7) paint(3,2,7) paint(4,3,7) paint(8,4,7) paint(5,5,7) paint(1,6,7)
paint(2,7,7) paint(9,8,7) paint(6,9,7) paint(1,1,8) paint(5,2,8) paint(9,3,8)
paint(6,4,8) paint(7,5,8) paint(2,6,8) paint(3,7,8) paint(8,8,8) paint(4,9,8)
paint(2,1,9) paint(9,2,9) paint(5,3,9) paint(1,4,9) paint(8,5,9) paint(4,6,9)
paint(7,7,9) paint(6,8,9) paint(3,9,9)

Models : 1
Calls : 1
Time : 20.837s (Solving: 17.59s 1st Model: 17.45s Unsat: 0.14s)
CPU Time : 20.836s

Open-Source Speech Recognition Toolkits

Tuesday, 26th August, 2014

Here’s a list of FOSS and FOSS-ish ASR toolkits: url, license and rough activity dates, and maybe the odd comment.

Apart from Sphinx4, which is written in The Java Programming Language, all of these are written in C/C++.

Kaldi looks the most interesting and mature. I’d also like to have more of a look at Bavieca, GMTK and TLK.

Have I missed any?

  • Bavieca
    Apache 2.0

  • GMTK
    Open Software License v. 3.0

  • HTK
    Weird license:

    Latest version is 3.4.1, 2009

  • iAtros

    unclear documentation
    unclear if HTK required
    designed for recognition of speech and handwriting

  • Kaldi
    Apache 2.0
    Current (last sf update 2014-08-11)

  • RASR
    Non-commercial use only

    Non-Commercial Use Only

    Free for non-commercial use only; commercial license request & pay

  • Sphinx
    Sphinx4 (java) is current
    Sphinx3 (C/C++) is unmaintained

  • TLK
    Apache 2.0
    2013 & current

MacOSX: telling tmux where libevent is

Friday, 8th August, 2014

tmux depends on libevent but after installing libevent, tmux still won’t configure:

$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... etc/install-sh -c -d
checking for pkg-config... no
checking for LIBEVENT... no
checking for library containing event_init... no
configure: error: "libevent not found"

You have to tell it where lib event is installed. I did a vanilla configure && make && sudo make install and it seems to have ended up in /usr/local/, so:

$ DIR="/usr/local/"
$ ./configure CFLAGS="-I$DIR/include" LDFLAGS="-L$DIR/lib"
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... etc/install-sh -c -d
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: executing depfiles commands


Thanks to stackexchange.

Dependent Types in Prolog

Wednesday, 7th May, 2014

or, “Had we but world enough, and time …”

** intro

I’ve been occasionally looking into programming languages with dependent types, when a recent tweet gave me pause:


I got interested in dependent types because SO TOLD ME TO^W^W^W^W they seemed necessary to encode some constraints on types for some toy projects I was thinking of, namely:

  • for a Bayesian network: represent probabilities (positive floating point number less than or equal to 1.0) and discrete probability distributions (a {T, Probability} mapping where the sum of probabilities = 1.0);
  • for fast Fourier transformation: respresent a list whose length must be a power of 2.

Naively, I thought I might be able to do this kind of thing in Haskell. I don’t like the cult hype around Idris. I thought I might try it with ATS, which I like the look of a lot, but it’s proving slow getting into.

** prolog

In the meantime, here are the types represented in Prolog:

% some "dependent" types

%%%% X is a power of 2

    Y is X / 2,

%%%% X is a list whose length is a power of 2

    length(X, L),

%%%% X is a probability

    X >= 0,
    X =< 1.

%%%% X is a discrete probability distribution

    maplist(prob, Y),
    sum_list(Y, 1.0).

%%%% helpers

seconds([], []).
seconds([[_, Y] | Z], [Y | Z2]):-
    seconds(Z, Z2).

tuplist([[_X, _Y] | Z]):-

** next


I might yet try this with ATS.

On the other hand, I might try it with Mercury, which seems to be (among other things perhaps) a typed Prolog.

** p.s.

In case the above is a bit downbeat on ATS: I do think ATS is a very interesting language. If any reader can give a quick sketch of one of the simpler types above in ATS, I am definitely up for having a go at the others.