# 2.1 Organizing Data

## Contexts vs. Records

Contextual Programming defines two ways to structure data, **contexts** and **records**. These types are nearly equivalent, except for the following:

* Contexts cannot be part of other contexts or records.
* Only contexts can be evaluated and manipulated by operations/behaviors.
  * This includes reactive[^1] evaluations that occur in response to context property changes.

These differences create clear and explicit expectations for working with data. Consider if contexts could be composed of other contexts. When an inner context changes, do reactive evaluations occur for the outer context as well? When evaluating an outer context, does an inner context get evaluated by its own operations too? If an inner context is entirely replaced, what kind of change should that be considered and does the inner context persist for its own behaviors?

While these questions can have defined answers, any set of answers would complicate practicing Contextual Programming without adding any particular value that cannot already be achieved by other means. To keep the paradigm simple and focused, a distinction is created between contexts and records; contexts being the containers for potentially persistent and changeable data and records being organized data for use within contexts or local manipulations within an operation.

## Defining a Context

In its most simple form, contexts are defined by declaring an identifier, describing the form (and usually the purpose) of its data, stating that the construct is a context, and then naming its data. The data may either be another [singular data type](#user-content-fn-2)[^2], a set of properties[^3], or a data type extended with properties.

In general, a context declaration looks like the following[^4]:

<pre><code>"Context Name" :: "A description of the optional 'type names' of the context" : 
    <a data-footnote-ref href="#user-content-fn-5">context</a> 'names of the data, corresponding to the type names by order, 
        with matching default values, as appropriate'.
</code></pre>

Here are a couple of concrete examples of declaring contexts:

{% hint style="warning" %}
By the way, comments[^6] in Rede are any text contained within backticks ( \` ), or any text on a line after two backticks.
{% endhint %}

<pre><code>`An adaptation of the built-in <a data-footnote-ref href="#user-content-fn-7">Int</a> type.`

Some Int :: Int : context.
`Names are not required, as it is a direct adaptation with no extending properties.`
</code></pre>

```
`A context for two integers, intended to be used as a position.`

Position :: a 2D location represented by Int and Int : context x, y.

`The same can also be as simple as the following, but it is less descriptive.`

Position :: Int, Int : context x, y.
```

### Default Values

All data types in Rede are expected to have default values. There is no "null[^8]" concept, as may be found in some other languages. Built-in types already have defaults, such as "Int" defaulting to 0. These defaults will propagate to the use of those types in new data types, but explicit defaults can also be specified. For the previous examples, adding defaults of -1 would look like:

```
Some Int :: Int : context itself[-1].
```

```
Position :: a 2D location represented by Int and Int : context x[-1], y[-1].
```

{% hint style="info" %}
Specifying any value or other type that can take the place of another in specific circumstances, also called a "stand-in", is denoted in Rede by square brackets. In this case, the explicit integer value of -1 is being defined as the stand-in for a default integer when instances of these types are created.
{% endhint %}

{% hint style="warning" %}
The keyword, `itself`, explicitly specifies that the matching data value is the type's primary value, that it is the value that the type is adapting. It can be omitted when there is only one data value for the type, as done previously, but is required if there are multiple data values or if the data value needs a specific default.
{% endhint %}

[^1]: React, in this sense, means to be automatically performed in response to something. In the case of Contextual Programming, what is being reacted to is a change to the state of a context.

[^2]: This relationship between an ancestor data type and a descendent data type is called [Adaptation](/a-general-introduction-to-contextual-programming/chapter-2-creating-context/2.3-adaptation.md).

[^3]: Named data values, like a number called "x".

[^4]: Where text within double quotations would be replaced by text meaningful to an actual declaration and text within single quotations is additional optional text to be specified.

[^5]: Changing this keyword to `record` would make this a record.

[^6]: Non-compiling text intended to convey information about the code to a programmer.

[^7]: "Int" stands for "Integer", a type of number.

[^8]: Also known as "None" or "Nil", this value is often a stand-in for the lack of any value, either for any data type or for data types that are permitted to be "nullable".


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://rede.gitbook.io/a-general-introduction-to-contextual-programming/chapter-2-creating-context/2.1-organizing-data.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
