I want to explain what I intend to do further in the program of “computing with space”, seen in the restricted sense of making sense of space in graphic lambda calculus. The explanation itself, if well done, would amount to achieving the program, therefore, at this stage, it can’t be too exact.

________________________

I think that a good definition of space is relational, based on it’s computational content, and not on “points” or other geometric objects and axioms over those. Obviously, a good definition of space should not be “spatial” itself, otherwise would be self-referential.

My belief, expressed mathematically, is that space (places) and types are simply just decorations over graphs in graphic lambda calculus, following the rules from the post Types and places .

If is a place and is a type, then means “there is a at the place “, for example means there is a car at . (This interpretation is what I use to make sense in my mind, beyond the mathematical formalism, therefore subject to changing). The name is just a name (of a variable or term), it does not have any other meaning than the one which can be grasped in relation with the other names for variables and terms. Recall that in graphic lambda calculus there are no names for variables and terms.

In the post Better than extended beta move I introduced two macros which I think they are better than the application and abstraction gates. Here they are again, for an arbitrary “scale parameter” , where is a commutative group (think, for example, about the free abelian group over an alphabet, if you don’t like to think about as the group of reals):

Graphic lambda calculus can be reformulated by using these “scaled” application and abstraction gates as fundamental gates. This has as effects:

- elimination of the move ext2, replaced by the definition of application and abstraction gates as the “scaled” gates at scale
- condensation of the graphic beta move and the move R2 into one scaled version of the graphic beta move, which is better than extended beta move .

The subtle part is that, if we look at the decorations, then the types decoration is left unchanged by the moves, but the place decoration is globally affected by the moves (i.e. “logical” moves, like the graphic beta move, change the space).

The other subtle part consists into extending the

- Dictionary from emergent algebra to graphic lambda calculus (I)
- Dictionary from emergent algebra to graphic lambda calculus (II)
- Dictionary from emergent algebra to graphic lambda calculus (III)

to these scaled application and abstraction gates. You shall see that rather amazing things happen, when we look at decorations with places.

I am going to use lessons learned from the Chemical concrete machine. If we use the scaled application and abstraction gates (and the FAN-OUT gate, of course) instead of the four gates of the original graphic lambda calculus, this makes 3 gates instead of four. Is then enough place to add a FAN-IN gate, as in the chemical concrete machine (while renouncing at identifying it with an gate, as indicated in the chemical concrete machine formalism). This way we shall have four gates again, along with some natural distributivity moves, namely the ones from the chemical concrete machine and the one called the “mystery move” in the series on the dictionary from emergent algebra to graphic lambda calculus. In this way, as long as we stay in the “scaled version of combinatory logic sector” (which will contain BOTH the emergent algebras and the combinatory logic, interacting in beautiful ways), we will not need the GLOBAL FAN-OUT move.

After these mildly technical things will be done, interpretations with words will follow.

## 2 thoughts on “A space program in graphic lambda calculus”