Making oor ane Merk

This week two old friends have written to me in apparent distress, concerned about the consequences for Scotland of George Osborne's latest temper tantrum; and so I've had to compose a response to their anxieties.

The real facts are that if 'the United Kingdom' is the 'continuing state', then in international law it is clearly, simply and unequivocally responsible for all the debts - every last penny of them. That's the law as it's been through the independence of Ireland, of the breakup of the British Empire, of Czechoslovakia, right down to Sudan last year.

If there's a 'continuing state', and Westminster has made it very clear it wishes to be a continuing state, then that state takes the debt. That isn't, of course, Scotland's bargaining position. We are willing to take on a population share of debt - but only if we also get a population share of assets, and there's no doubt the Pound Sterling is an asset.

If the rump 'United Kingdom' wants to keep that asset to itself, I would expect that to be negotiable - but it's a big asset, so they must expect to pay heavily. But if they won't negotiate, then the law is it's their debt, not our debt, and we cannot default on it. That's very well understood, long established international law.

I actually agree that in the long term monetary union won't work; our economies are going to diverge pretty sharply. But it's very much in England's interest to allow Scotland to come to that decision in it's own time, rather than have to pay heavily now to bribe us to change.

I really don't see this as being a hard negotiation. It is so manifestly in everyone's best interest to maintain friendly relations. What we're seeing just now is frightened men having tantrums and throwing their toys out of the pram; after the vote, when they actually have to deal with the issues, they'll be much more pragmatic and reasonable.

It's right that the rUK can refuse to set up a currency union, or allow Scotland to share the Bank of England. It's right, too, that sharing the Pound, with or without rUK's agreement, would mean that Scotland would be effectively forced to keep its economy in lockstep with one rapidly heading down a neoliberal cul-de-sac which leads only to extreme social dislocation and the third world. In other words, while easing the transition to independence by keeping the pound in the short term may be a good thing, keeping it in the long term would probably not be.

On the other hand, the Pound Sterling and the Bank of England are both pretty substantial assets, of which Scotland by rights owns a roughly 10% share. If rUK want to keep that asset for themselves, what are they prepared to pay for it?

In the long term it seems to me highly likely that Scotland - like Norway, Sweden, Iceland, Switzerland - will have its own currency. It seems to me that in the long term we'll more or less have to.

But that in turn raises another question: what is the long term future of the pound sterling, floating off into the mid-Atlantic sans Europe, sans industry, sans education, sans oil, sans friends? The rUK really needs to think about what it's doing, here. It does not have a God-given right to the share of the planet's wealth it currently enjoys. This is a time to be building good relationships, not wrecking them.

On Clojure as a multi-user environment

Today, not having really enough to do at work, I was reading a Guy Steele and Richard Gabriel's (highly partisan) paper 'The Evolution of Lisp', and thinking about Post Scarcity Computing and about Clojure.

Lisp has failed to get traction too many times because people insisted on their own idea of what constituted a pure Lisp. Let's be clear about it, if I were designing my perfect Lisp it would be different from Clojure in a number of significant ways. Nevertheless, Clojure is more or less the best Lisp we have now, and furthermore it has traction. Furthermore, it has a number of most excellent features which, had I not been exposed to Clojure, I would not have thought of myself. So if you're going to build a post-scarcity computing environment now, Clojure is not a bad place to start.

But let's think about how Clojure impacts on the ideas I put forward in Post Scarcity Computing. Firstly and most importantly, in Clojure data is (with some special case exceptions which we'll come to) immutable. That has a number of interesting consequences, and one of them is that an older data cannot ever point to newer data.

How does that impact on a multi-user environment? Well, probably no-one's ever thought about that in the context of Clojure, because probably no-one's ever thought about having several people connected into the same Clojure session. But, suppose you connect to a base Clojure environment, and run some computation, and then I connect to the same base environment. I cannot see anything that's going on in your computation, because all the partial results of your computation are newer than the base environment.

You can try this yourself. There's probably simpler ways to do this, but here's mine: first, install emacs 24, and cider. Next, open three terminals, and run

lein repl :headless

in one of them. This starts a headless nrepl, and prints out the port number it's running on:

simon@fletcher:~$ lein repl :headless
nREPL server started on port 48705 on host 127.0.0.1

In the other two, start headless emacs sessions:

simon@fletcher:~$ emacs -nw

In each emacs session, type

escape-X cider

You'll be prompted for a host, with a default of 127.0.0.1 (localhost). Accept this. You're then prompted for a port; type in the port number that the nrepl server printed.

Now, you have two terminals both connected to the same Clojure session. In one, evaluate something:

user> (list 'a 'b)
(a b)

In the other, type *1 to look at the result of the last evaluation:

user> *1
nil

But in the first window, the one where you evaluated something, *1 returns the value you'd expect:

user> *1
(a b)

So, as I said above, two separate sessions whose computations and local environment are invisible to one another. How can they be made visible? It's as easy as defining a var:

user> (def shared (list 'a 'b))
#'user/shared

Now, in your other emacs terminal, the value of shared is what was set in the first:

user> shared
(a b)

So, by default, everything a user does is private. It can be made public by simply defining a variable, in the default (user) package. Again in one terminal:

user> (ns foo (:use clojure.core))
nil
foo> (def hidden (list 'p 'q))
#'foo/hidden

In the other:

user> (ns bar (:use clojure.core))
nil
bar> hidden
CompilerException java.lang.RuntimeException: Unable to resolve symbol: hidden \
in this context, compiling:(/tmp/form-init3330134955068707486.clj:1:691)        

Unless the other user can guess the package name you're working in, they can't see the variables you bind. Of course, in Clojure as it exists now, if you do know the name of the package another user is using, you can see their variable bindings, because Clojure as it exists now isn't designed as a multi-user environment. And security by obscurity isn't really security at all.

But nevertheless you can see that Clojure could easily be made an effective multi-user environment. You can see that it would be easy to write an 'executive' function, which provided its own read-eval-print loop in an environment in which it had a (mutable) Java HashMap bound to a local variable, and could intercept a particular input pattern to store 'user-private' variables into that hashmap.

It's not hard, in fact, to see how a multi-user system could be built on a persistent Clojure session. I'll return to this soon, in further blog posts.