Language Design

Computability Space: A paradigm for computational design

April 13th, 2018

Manifest Statement: Computing science as well as industry oriented programming deserve the same principles of design which make mathematical spaces and number systems as potent and utilizable as they are.

What are the design properties of mathematical spaces for which I speak?

1. Navigable Complexity (Interface Theory, Structural Typology):

   Let's use the space $R3$, the 3-dimensional product of real numbers as a prototypical example.

   It has a concrete constructive grammar. It's built from the real line $R$ and the grammatical product construct. The real line is its own space which has its own constructive grammar, but we focus only on our current layer of abstraction.

   Once this space is constructed, we then inventory universal navigational systems. Basically, we have a space of objects, so how do we access them? The most natural one is the cartesian coordinate system, which is constructed directly from the navigation system of the real line. If we start at the origin, we then take advantage of the monoids of addition and multiplication to move to the coordinate of interest. There are of course alternative coordinate systems, namely spherical as well as cylindrical coordinates.

   If we were to take a bigger picture view of spaces like this, we would ask the question: Why this space? What makes it special? Mathematical constructive grammar is potent enough we could construct all sorts of navigable spaces, so why this one?

   We choose spaces such as $R3$ because they are navigably complex. We are able to easily find a rich magnitude of subspaces, all of which we can navigate by default through the universal coordinate systems. As each subspace potentially uses less information to uniquely represent its internal objects than used in the whole space, the informational entropy is also potentially lowered, meaning we can compress the representation of the subspace. In the situation where we are also able to compress the navigational system, we call this an interface.

   Finally, there is the idea of a type. The space as a whole, in this case $R3$ is its own type. Type is a matter of context though: A space in comparison to other spaces has a type, but if it existed in isolation the idea of a type becomes less potent. As we don't consider $R3$ in the context of other spaces, we can view it as untyped. Yet, when we create subspaces and interfaces from this untyped space, we are introducing spaces as comparable against each other, and so the idea of a type again becomes potent. These types aren't cultural or political—imbued by the will and intention of the user, they are implied by their structural restrictions relative to the whole. As such they are referred to as structural types.

2. Predicate Logic (Concept Theory, Functional Typology):

   Predicates are the medium of exchange in logic, and math uses predicate logic as its deductive system.

   Math largely has three kinds of predicates—all having to do with similarity: identity, proximity, shape. Identity predicates identify objects with each other through equality or equivalence. Proximity predicates compare objects with each other through their orders of nearness. Shape predicates measure objects against each other through mappings of behaviour and the categorical company they keep.

   Predicates are our means of specifying subspaces, and within any interface it allows us to narrow groups of objects in the scope of our focus. Predicates also allow us to construct new navigational systems within the limits of interfaces. They allow us to extend or move beyond our monoids. for example in $R3$ we may restrict ourselves to a Klein bottle and create new operators to navigate across its surface. The combination of our space being navigably complex and being equipped with a predicate logic is that it allows us to use this single space to model many different applications.

   Our predicates are expressed through the properties of the concrete grammar used to construct the whole space. From there, we can combine these predicates in new ways, forming a filter algebra. A filter being the dual concept of a type specification. This is to say, the more filters you combine, the further you restrict the type. There is a bijection between filters and types, yet a complicated filter represents a simple type while a simple filter represents a complicated type.

   Finally, each interface may be used as the model for a multitude of applications, which is to say it may be interpreted and reinterpreted. Another way of viewing this is that we equip this interface with an additional perspective of type, thus temporarily equipping it with additional navigators and other operators. As we are imbuing the type upon the interface, it is cultural and political, and so we refer to these as functional types.

If you look at the history of computing science and programming, the focus has been on algorithms, not the spaces for which the inhabit. It is time we build and teach computational spaces which parallel those ideal properties of design which make mathematically designed spaces so intriguing.

This paradigm of design is split into specification side and implementation side, each of which are decomposed into simpler paradigms:

1. Specification side:

   If the language permits, narratively construct the space through a polymorphic grammar which would allow you to construct a polymorphic space. For example in C++ you could specify a memory space constructively as bits, words, then addresses, all defined weakly through templates. This holds value as it allows you to reuse this code for any interface that can be grafted on through interpretation later in practice.

   For each constructive structure, supply an inventory of coordinate systems to universally navigate that structure. Once the whole space has been constructed, restrict any relevant subspace along with its navigable discourse, compress when possible, resulting in interfaces.

   Supply inventories of perspectives (collections of methods and operators defining functional types) to interpret and reinterpret the structural interface types.

   As we build this paradigm on top of a concrete language, when possible take advantage of the language's natural efficiencies and dispatch optimizations for concrete cases of structural and functional types. In the case of C++ this might be done by dispatching partial template specializations for builtin types.

2. Implementation side:

   We modularize our narratives by tethering/indexing them to hardware abstractions. For each hardware module, we use the constructive narrative to further modularize any given narrative path into constructive objects.

   We classify the code for each object as interface, perspective, instance.

   Interfaces are decomposed into structure and navigator, while perspective holds an inventory of functional types bundled as methods, and finally instances hold concrete cases which dispatch to optimized or (general) user safe code.

   The perspectives and instances both have semiotic and media versions: Semiotic code has the requirement to be elegant, efficient, reusable, but otherwise it has no requirement to be safe. It's not meant to be accessed by the general user, only the architects. Media code has the requirement to be safe and user-friendly for the general user, and is built from the semiotic code. It has the best of both worlds this way as it allows for optimizations and safety.