> For the complete documentation index, see [llms.txt](https://rede.gitbook.io/a-general-introduction-to-contextual-programming/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://rede.gitbook.io/a-general-introduction-to-contextual-programming/chapter-4-reacting-with-behaviors/4.1-revisiting-hello-world.md).

# 4.1 Revisiting Hello World!

## The Concept of Behavior

Behaviors are constructs that provide additional meaning to their required, and qualifying, contexts, with encapsulated operations that can react[^1] to changes in those contexts. The contexts associated with a behavior form a relationship that can be leveraged by the behavior and other behaviors/operations, [as seen later](/a-general-introduction-to-contextual-programming/chapter-5-abstracting-evaluations/5.1-compositions.md). This reactivity and the conditional associations between contexts and their shared operations is at the heart of Contextual Programming, enabling programmers to more effectively develop dynamic applications.

## Activation

Before going over the internals of a behavior, it's best to understand how a behavior exists and what to expect of it. Behaviors require contexts that have been "activated". So far, there have been no such contexts explicitly activated. Doing so can be done with this generalized syntax, within an operation, [like so](#user-content-fn-2)[^2]:

```
activate "some context"
```

All contexts can be activated. Once this is done, a behavior that requires a context of the same type as the activated context can evaluate it to see whether it qualifies to be associated with the behavior and its other contexts, that is, if all of its required contexts exist and qualify. In some cases, multiple instances of behaviors can exist.

{% hint style="warning" %}
An instance of a behavior may be similar to an instance of an object in Object-Oriented Programming, although there are some differences. A behavior will be instanced, meaning it will exist with specific associations and will perform its functionality, if its context requirements are met. Once a behavior has its requirements met, any additional contexts (that cannot be associated with that behavior based on [how it is defined](/a-general-introduction-to-contextual-programming/chapter-4-reacting-with-behaviors/4.4-expanding-purpose.md)) will be considered for additional behavior instances.

When a behavior can no longer continue to exist as an instance, namely because one of its contexts were [deactivated](#deactivating). Then the remaining contexts are (usually, again depending on how its defined) considered for new behavior instances with other contexts that are currently in-use with other behaviors. This highlights one of the primary differences in instances, compared to Object-Oriented Programming, that being the internal data of a behavior instance may persist and be associated with a new behavior instance automatically.

Although, if a context enters a state in which it will no longer qualify for any behavior that either already exists or that can be immediately created, then it will be deactivated automatically and removed from memory once it is no longer in use by any evaluating operations.
{% endhint %}

### Introducing Console Output

One of the most basic behaviors is one that was, unknowingly, being used back in the [original Hello World! example](/a-general-introduction-to-contextual-programming/chapter-3-evaluating-with-operations/3.1-hello-world.md). That code was:

```
Output Hello World :: 
    operation when initialized?
        evaluate "Hello World!" as Console Message.
```

There's no apparent activation occurring here, but the operation that handles `Console Message` will actually activate the `Console Message` and a `Console Output` context. Afterwards, a behavior that works with a `Console Output` context and any activated `Console Message` contexts will append each value of those `Console Messages` to a `Messages` list[^3] property of `Console Output`. The `Console Messages` are deactivated at a later time through another behavior to prevent unnecessary memory use. As part of the console's refresh cycle, any content in `Messages` of `Console Output` will be printed onto the console.

{% hint style="info" %}
One may be wondering, "How can I know in what ways a context, such as `Console Message` is being used?" In the modern era, IDE[^4]s play a vital role in software development. While the programmer looking at this evaluating code may not know all of the associations of `Console Message` and its conditional operations/behaviors, the IDE can, since it is always knowledgeable of how the `Console Message` is referenced and manipulated across those operations/behaviors. The short answer here is, a proper IDE should inform the programmer of everything they need to know for the contexts that the programmer is working with.
{% endhint %}

As described, that's quite a bit happening behind the scenes. The purpose of reducing all of that down to `evaluate some string as Console Message` is to simplify the steps taken to output to the console, and to prevent the need to make `Console Output` a required context for any number of behaviors/operations. However, there may be times when it is appropriate to declare and activate `Console Output` directly, and to have it as a dependency[^5].

In addition to other useful properties, `Console Output` has the aforementioned `Messages` property. The value of this property is exactly that which appears in the console to the user, including the user's [own active input text and previous responses](#user-content-fn-6)[^6], although word wrap to fit within the bounds of the console may change how it appears. Every message is assumed to be its own print statement, with an assumed [new line](#user-content-fn-7)[^7] at the end. Having direct access to this property is useful, as the contents of the console can be cleared by changing that property to be an empty list, or otherwise altered.

### Activating Console Output

The Hello World! example can be updated, based on the generalized syntax to activate a context, to explicitly declare `Console Output`, like so:

```
Output Hello World :: 
    operation when initialized?
        activate output is Console Output,
        output(messages) is "Hello World!".
```

On the third line, `activate output is Console Output` is performing an inline declaration of a `Console Output` called `output`, then activating it. This provides `output` for further use while also activating it so the console printing behavior mentioned previously can be initialized and begin working.

The last line, `output(messages) is "Hello World!"` is assigning a single `String` to the list of `messages` in `output`. This will result in `messages` being a list with one item, the `String` that is `Hello World!`. This change will [later trigger](/a-general-introduction-to-contextual-programming/chapter-4-reacting-with-behaviors/4.2-from-when-to-whenever.md#understanding-execution-flow) the console printing behavior to update the console's display, resulting in `Hello World!` being displayed to the user.

This example can be shortened further by setting `messages` at the point of `output` being declared:

```
Output Hello World :: 
    operation when initialized?
        activate Console Output [messages ["Hello World!]].
```

This code is similar, but `output` is no longer named in the declaration, as it isn't needed beyond its activation, and the `Console Output` instance is initialized with `messages` set to `"Hello World!"`, as is accomplished with the code `Console Output [messages ["Hello World!"]]`.

{% hint style="info" %}
Per how the console printing behavior is set up, only one `Console Output` can sensibly be activated at a time to effect printing to the console, as that behavior will be the one to capture all `Console Messages`. This type of behavior parallels the concept of a 'singleton' in Object-Oriented Programming, where there is only one instance of some kind of system required to do something.

That's not to say that there can't be more than one activated `Console Output` though, and it's entirely possible that some other behavior that does not print to the console may do something with all of them. That's a difference between a self-enforced singleton as a behavior and a dependency determined singleton of an object; the data that defines the behavior can serve other purposes (through other behaviors) that may still effectively extend the functionality of the behavior.
{% endhint %}

## Deactivating

The opposite of activating is deactivating, which informs the runtime that the previously activated context (if it was activated, if not, nothing happens) should no longer be active. Any behavior that was depending on the context will no longer have access to that context, so if its existence was required for the behavior to function, then the behavior will be terminated, and any relationships formed between other contexts due to that behavior are broken.

Deactivation is done in the same manner as activation, [generally being](#user-content-fn-2)[^2]:

```
deactivate "some context"
```

Knowing that `Console Output` will update the console display with its contents if it is activated, then it can be expected that the console won't continue to update if `Console Output` is deactivated:

```
Output Hello World :: 
    operation when initialized?
        activate output is Console Output [messages ["Hello World!"]],
        output(messages) is itself + "This is a second message.",
        
        await output,  `Wait for the behavior to update for the new message.`
        
        deactivate output,
        output(messages) is itself + "This message won't be printed.".
```

The above code will deactivate `output`, after the first two messages are printed, which will prevent the console printing behavior from outputting the last message, as would have happened once the operation completed. Besides that, there are a couple of new concepts in this code.

The keyword `itself` is seen when updating the value of `output(messages)`. When used as part of an [assignment statement](#user-content-fn-8)[^8] `itself` refers to the value being assigned to. It's a shorthand, in some cases, to updating a value that changes with reference to its previous state.

The second is `await`. While there is a comment in the code describing what that line is doing, it's worth noting that in general `await` will allow any pending reactive evaluations of the subsequent context(s) to occur before this operation continues. In this specific case, the only pending reactive evaluation is the console printing behavior updating the display for the change to `messages` as shown in the line directly before `await`.

[^1]: Meaning that behavior operations can be performed automatically if a behavior's context(s) change in some way.

[^2]: As before, text within double quotations here would be replaced by text meaningful to an actual declaration, in this case, the name of an actual context instance.

[^3]: A List in programming is a one-dimensional collection that can rather easily have items added and removed from it, much like an everyday list.

[^4]: IDE stands for Interactive Development Environment. These are software that parses a codebase and can inform a programmer about the code they are working with and also simplify a number of tasks that a programmer may wish to perform on the codebase.

[^5]: A dependency is any construct required by another construct for the latter to function as expected. All required contexts of a behavior or operation are dependencies. Some control flow qualifiers can also define dependencies with other operations.

[^6]: Both of these are appended to the `Messages` list in their own way, as the result of user input.

[^7]: A new line, coded most often as `\n` in a string, is the same as using the `Enter` key when typing in a word document. The current line of text will end, and the cursor will move to the next row to type any new text. It functions the same when printing to the console.

[^8]: Any statement with `is` is an assignment statement, which is to say that the result of the right-side of `is` will be assigned to the variable specified on the left-side.