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 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 , a set of , or a data type extended with properties.

In general, a context declaration looks like the :

"Context Name" :: "A description of the optional 'type names' of the context" : 
     'names of the data, corresponding to the type names by order, 
        with matching default values, as appropriate'.

Here are a couple of concrete examples of declaring contexts:

By the way, in Rede are any text contained within backticks ( ` ), or any text on a line after two backticks.

`An adaptation of the built-in  type.`

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

`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 "" 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].

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.

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.