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.

.