Introduction

In this essay, I discuss the need-to-know principle.

Many PLs^[1] do not obey this principle.

This idea — YAGNI applied to information — is central to creating layered software designs.

I arrive at the conclusion that there are many linking-loaders, not just one.  Loading is a continuum of operations.  Likewise, I conclude that compilers should supply less information in .o files.

Anecdote - Eiffel in Emacs Lisp

I used an early version of the Eiffel compiler.

Build times became progressively longer as more classes were added.

I concluded that the compiler was doing too much work — it scoured the file system trying to resolve all classes.

I wrote an experimental Eiffel compiler in Emacs Lisp.  The compiler ran in linear time, regardless of the number of classes being used.  The main feature of this experiment was that type checking could be done in stages by successive "loader" invocations.  The compiler created .o files that contained a bare minimum of information — the compiler created code, but deferred multi-class type checking by leaving "holes" in the .o files.  The "loader" worked in stages — it did as much type checking as it could given the .o files that it was given, and deferred all other type checking for later.  A .o file with no remaining "holes" was executable (.exe).

The UNIX® archive utility —  ar — worked in a similar manner.  The archiver would patch as many holes as it could, but not more, before creating a library .o file.

Ar worked only with address "holes".  

The n2k^[2] principle can be applied to:

• address resolution, and,
• type checking.

Simple Component

Fig. 1 Component with 2 Input Ports and 3 Output Ports

In Fig. 1, there are some things (relationships) that we know, and there are some relationships that we do not need to know, for example:

• We know that the Component has kind "ty1"
• We know that the Component has 2 inputs
• We know that the Component has 3 outputs
• We do not know the types of data that are required by the inputs
• We do not know the types of data sent from the output pins
• We do not know how the Component is implemented
• We do not know whether the Component is a Composite or a Leaf
• We do not know where the input data comes from
• We do not know where the output data is going to be sent.

Events

Data arrives on input ports and is sent on output ports, carried by events.  Events are mostly data-agnostic.  Events consist of 2 details:

1. A port name (a tag)
2. Any kind of data. 

Layered Data

Events can carry layered data as well as scalar (non-layered) data.

Data is packed and unpacked by successive layers of Components.

APIs / Signatures

Fig. 1 shows us what the signature of a Component is, namely:

• A kind
• Inputs
• Outputs.

Note that:

• We do not know how child components are implemented
• We do not know how this component is implemented
• We do not know the signatures of contained components (if any).

(That information is deferred and left as a "hole" to be filled in later).

---

[1] PL means programming language

[2] n2k means "need to know"