Skip to content

Evaluation

To evaluate a document, coeval asks it the verb eval. The ladder finds the evaluator. The evaluator gets the parts of the document, and it decides when to evaluate each part. Each result comes up to the parent through a port.

The glyphs so far: 9, 3 new on this page
  • 42Data: a value without a type
  • number
    42
    A document: the tab is its type
  • number
    42
    A dashed tab: the container declares the type
  • add
    number
    1
    number
    2
    Parts: a card inside a card
  • kindA kind: a document of type kind
  • OKDA rung: own, kind or default
  • 3A port: the result of a documentnew
  • 0A sealed part: an evaluator cannot read itnew
  • #NAME?An error value, in a red portnew

Select Next to go one event forward. Each start and each end of an evaluation is one event. The panel shows the current card: the ladder that found its evaluator, its context, the parts that its evaluator gets, and its result. Select a card to look at it.

Open in the playground

Nothing started yet. Select Next or Play.

add
number
2
multiply
number
3
number
4
The result shows at the end of the evaluation.
The evaluation of add starts first and ends last. Between them, each part starts and ends. Each result goes up through a port, and the parent combines the results.

The picture is the document. The cards are nested as the parts are nested. The order of the events is the order of the evaluation. No other drawing describes it.

An evaluator gets each part as a sealed card. It can evaluate the part, in a context that it chooses. It can give the part to another evaluator, or keep it for later. It cannot read the part, because a sealed part has no field with its value.

The parent
The part

Two parts with the value 5

What the parent gets

0

The parent, with part A

multiply
add
number
2
2
number
3
3
5
number
10
10
50
The parent getsResult
Part A50
Part B50

A swap changes nothing. The parent sees only the value of its part. Thus each part with the value 5 is correct in this place.

An evaluator gets its parts sealed. It can evaluate them, or give them to another evaluator. It cannot look inside them. This rule keeps equal parts interchangeable. The kernel enforces it: a part has no field with its value.

The seal gives a simple test for a new evaluator. Evaluate the same documents with the old evaluator and the new evaluator, and compare each result. When each result agrees, the new evaluator can replace the old one.

An evaluation does not throw. A failure gives an error value with a code and a reason, and the port of the card shows it in red. The parent gets the error value as its result, unless it can recover.

Open in the playground

The evaluation of add ends with the error #NAME?: The context has no name price.

add
ref
namesprice
#NAME?
number
2
2
#NAME?
The result of the document: #NAME?
The context has no name price, thus the reference gives #NAME?. The add gets an error, and its result is that error.
Code Cause
#KIND? The type is not a kind of the world.
#NOEVAL No rung of the ladder gives an evaluator.
#PART? A part has no envelope, and its position declares no type.
#NAME? The context has no such name.
#VALUE! A value has the wrong form for its kind.
#ARGS Two or more parts failed.
#CAP! The context has no capability for an effect.
#CALC! The code of an evaluator failed.

An editor, a checker or a compiler works on the document as data. It must look inside. These tools work before an evaluation or beside it. They do not give meaning to a document, thus the seal does not apply to them.

An evaluator is not one fixed formula language. A pure evaluator can be a formula. An evaluator of effects is a sequence of calls. An evaluator that builds a tree is a tree template. Each evaluator uses the language of its side, and code evaluators are the base cases.