Re: Operationalize orthogonality

> Why ?

Because at this point you have an incredibly ugly system that is very difficult to use. You can reason about it, but you wouldn't want to try using it productively (in much the same way that you wouldn't want to do a tax return using booleans to describe numbers describing money). You could use it, but you'd go nuts fairly quickly.

> What about the possible representations ?

Do you mean possreps in the Date & Darwen sense ? I'm still not 100% sure I buy into those, although I can see value in them for version control and change management, if nothing else.

> SKI and DEE/DUM trick have the same power ?

That may have been a little oblique. The SKI combinator scheme is a method of implementing the lambda calculus which, at its purest, uses only three instructions (S, K and I - and it later turned out that I is actually redundant so you really only need two). This has some very attractive properties (implement S & K, then a compiler from the language of your choice to S & K and you're off and running) but also some very unattractive properties (like, program size expands quadratically when you compile it to combinations of S, K & I). At least one computer has been built that used the SKI combinators as its machine code (SKIM, I think it was called). See Chapter 16, "SK Combinators" in Simon Peyton-Jones "Implementation of Functional Programming Languages" (Prentice-Hall, 1987) for more info.

In general, the very stripped, ground zero systems are a bit like the North Pole; you're very happy that someone has gone there, thought about it a bit and validated it as a boundary condition.

But you wouldn't want to live there. Received on Wed May 31 2006 - 01:40:44 CEST