Actions

Work Header

~ATH - A Handbook for the Imminently Deceased

Chapter Text

Welcome to ~ATH for dummies! This is a simple, online guide which will teach you how to program awesome ~ATH scripts, one step at a time. From simple graves to advanced reacharounds (up to and including scripts of the caliber of the infamous Mobiius Viirus), the handbook will tell you everything. This first page, or chapter, or whatever you want to call it, is a simple and easy tutorial on setting up the ~ATH compiler, the ~ATH running environment, and the popular ~ATH IDE, ~ATHFORASSHOLES. It is available here: http://www.mspaforums.com/showthread.php?37680-Novelty-ATH-Editor

Disregard the above link - ~ATHFORASSHOLES 2.0 is now out! It allows you to develop ^CAKE and &VIL programs as well as ~ATH, so that's a major improvement. There's also going to be support for proper bifurcation coloring very soon, which will please all of us. Directly download it here.

FOR PEOPLE USING ~ATHFORASSHOLES V1.3 AND LOWER (THAT IS, THE OLD LINK): For some weird reason, the author decided to host the file on some website called "Docs". Anyway, we at the ~ATH tutorial team have found that, once in the ~ATH.zip page, you need to hit File==>Download. For those of you who are unfamiliar with old-fashioned, HTML powered websites like this. Seriously, Docs should really update to use &VIL. It runs a hell of a lot better than some shitty HTML parser, and my browser can hardly handle the crappy scripts. Anyways.

FOR EVERYONE: Once you download it, extract it to a safe directory. Just run the ~ATH file. It should start the editor. The ~ATH environment and compiler *should* be initialized with the IDE. You'll know if they don't - the IDE will fail to run. If this happens, just follow the instructions below, depending on your OS.

-- For Windows 2050 (Hugely outdated OS, but anyway.) --

1. Go into Universe Editor.
2. Run ~MYATH.
3. Reboot the IDE.

-- For ~ATH Rev 500 --

1. Open the ~MYATH ^CAKE file.
2. Enable the ~ATHDEV options.
3. Reboot the IDE.

-- For SKAIANET Beta 12 --

1. Create a file called ~MYATH.^CAKE in the IncipiCenter. It will be autofilled.
2. Reboot the IDE.

Congratulations - you've successfully completed the installation of ~ATHFORASSHOLES! If you want, you can read the short ~FAQ below. Otherwise, continue to the next chapter, to create your first-ever complete ~ATH script.

-- ~FAQ --

Q: I tried to run the ~ATHFORASSHOLES IDE, and it crashed. But I couldn't find my ~MYATH file! What the fuck?

A: What the fuck indeed. Illegal installations of ~ATHOS and Windows 2050 are not supported. And I know they're illegal because the ~MYATH panel contains the anti-piracy checks, and a ^CAKE script is run to remove it in the cracking process.

Q: I set up my ~MYATH file correctly, but the IDE crashes with the message "~ATHCRASH 10: Unsupported filesystem type.". Why?

A: Bug concerning running Windows 2050 with the ^CAKE filesystem support. Got to ~MYATH and disable the ~FSCHECK options.

Q: I want to develop an awesome program, like Total Bullshit or the Hephaestus web browser. Can I do that now?

A: ~ATH is not the right language for developing applications like that. Look into our ^CAKE tutorials.

Q: Why are you so good at ~ATH.

A: That's the best fucking question anyone's ever asked before. And I honestly have no idea.

Note: Many bugs and failures are discussed throughout these tutorials. Check my other work, the ~ATH Buglist, to review what these bugs are and how they can affect you.

Chapter Text

Now that you've set up your IDE and the ~MYATH panel, you can begin writing your first file! Let's examine the IDE for a moment first, though. I want to make sure that you understand how this little piece of technology works before we get started.

Here's a quick picture showing the basic interface (yes, I use Windows 2050. Fight me.)

The basic ~ATH interface.

See those buttons up the top? They're the important things. The 'N' stands for a New Document. When you finish working on a script, you can start a new one with this button. The 'O' stands for Open. You can open and edit an old script with this button. The 'S' stands for Save and Build. It not only saves the current script, but also auto-builds it, leaving you with an ~ATH file which is ready to execute. The 'X' stands for exit. This should be self-explanatory.

That big black area is the text working area. It's where you place all your code! Let's start off our first-ever script now. Observe and enter the following code.

~ATH(THIS) {

    //Additional graves...

} EXECUTE(NULL);

THIS.DIE();

This is the most simple file we can work with. It does nothing on its own, but it acts as a template for every other script we will write in this series. I'll break it down, step by step.

~ATH(THIS)

This tells the ~ATHLISTENER to listen for a Death on this Object - that is, the file itself. Since this file will not die, this code should not be executed, unless you foolishly decide to delete it while the script is running (this would also probably cause errors, loops, and recursion, ultimately crashing and/or exploding your computer).

{

    //Additional graves...

}

This is fairly simple to read. All your code ('graves') goes between the curly brackets. The double slash before the middle line denotes it as a comment. The Compiler will not read comments, and they are just there for documentation.

EXECUTE(NULL);

This is where it gets tricky. You see, the death of the Object you are listening to doesn't directly execute the code within the brackets. Rather, it checks the EXECUTE call that must come immediately after, and executes whatever it finds there. In this instance, the Graves are never even executed. NULL is a keyword for nothing, so nothing is executed. To execute the code in this file, it should be changed to EXECUTE(THIS).

THIS.DIE();

This is fairly simple again. It 'kills' the script (or rather, ends it). It will then lie dormant until ran again.

There are several more basic components to normal ~ATH files. Besides Graves, which will be covered in the next chapter, there are also Definitions and Imports. Imports allow the use of external libraries - such as the Being and Universe libraries. Definitions allow you to assign data to specific keywords, such as author.

Take a look at this revised script.

import author Ziddia;

import Universe u;

~ATH(author) {

    //Additional graves...

} EXECUTE(THIS);

THIS.DIE();

There's really only one new part - the rest are all already covered.

import author Ziddia;

import Universe u;

~ATH(author)

This is fairly simple. This defines the author keyword - which is generally used in the writing of automatically executing wills - as Ziddia - me. It also defines my Universe as an import, and creates an Object of its type (u).

It then checks for my death. Note that, no matter how many Ziddias there may be, it chooses me because of the thought in my head as I type it. The ~ATH Compiler is smart.

That's all for this chapter - I guess I should mention I'll be updating several times daily. Check back constantly for new chapters, as we explore the ~ATH Universe!

Chapter Text

Graves are simple lines of code designed to execute pieces of data. They are kept within the main ~ATH loop of a file. To use Graves, you have to have a sufficient understanding of when and how a particular Object will die.

Take the following code example, for instance.


import author Ziddia;
import Universe u;
import Dimension d;
import Object o1, o2;
import Session s;

~ATH(author)
{
SET[o1, author];
SET[o2, GET[Globals.DISPLAY]];
BIND[o1, s];
BIND[o2, s];
BIND[s, d];
BIND[d, u];
~ATH(u)
{

SET[u, NULL];

} EXECUTE(THIS);
} EXECUTE(THIS);
THIS.DIE();

This is probably extremely overwhelming for you right now, but don't worry - there is sense to all of this, and this little code snippet should help us explain a lot of the basics. This will be the code snippet we will be referencing over the next three lessons.

First, let's take a look at all those imports. It defines the Author - we already know this. It goes on to define the Universe - we already know this too. It also defines a Dimension and a Session. The Dimension is the one that we live on - that is, Earth, or Mortal in the ~ATH records. Sessions are somewhat ambiguous; the ~ATH documentation barely brushes over them. However, in general, they are tied to a person's life. The Session used here is the author's life. There are also multidefined Objects. Multidefining is when you use a comma to separate two different imports of the same type.

I feel that now might be a good time to define what an object is. Everything in ~ATH is an object. The computer you are reading this from is an object. You are an object. The Universe is an object. And ~ATH can manipulate objects, to a certain degree. For example, if I have an object representing my clock, and I use an ~ATH script to set that clock as a watch, it will happen to the actual clock. Object manipulation.

This leads us into the next section. It contains a bunch of keys, assigning and getting values all over the place. Let's break it down.

First, we have the ~ATH loop - it executes on the author's death. In the loop itself, we have two SET keys.

Keys are words that are used for data manipulation in ~ATH. For example, EXECUTE is a key, THIS is a key, NULL is a key, and import is a key. By convention, keys are written in all capitals, but this isn't required for compilation - it's simply a guideline.

The SET key is used to assign the value of one object to another. For example, in the first SET line, we assign the value of the Author key to o1. The only difference between a key (like author) and a SET object is that an Object can be bound (see next chapter). If you want an antiquated reference to how SET keys work, it would be accurate to think of it as a pointer - however, rather than pointing to something in memory, it points to an actual, existing object.

In the second SET line, we also see a GET key. GET keys work in the opposite way - they retrieve values from pieces of data. In this example, o2 is assigned the data from the Global Variable DISPLAY. Globals is a file in the ~ATH SDK, and DISPLAY is an Object within it representing the native game window.

For those of you who are curious, yes, this is a legitimate code sample from a real game called Sburb. It's from the Serverside scripts. It's been slightly modified to make it easier (e.g. Changed from ~ATH(~ATH(!u){SET[u, NULL]}EXECUTE(THIS);) to ~ATH(author)).

A full review of the Globals file should be in around three chapters from now, after I finish explaining all the basics

Now might be a nice time to mention that, on it's own, ~ATH is a rather useless language. It can manipulate real-world Objects, and has a powerful Data Management System, but it isn't enough to create powerful applications like Sburb or Pesterchum.

Most of the time, ~ATH only handles the graphics (if that), and rendering real Objects. ^CAKE is normally used for the game's code.

Chapter Text

In the last chapter, we had a quick look at getting and setting imported values, and at some of the important uses of those keys. In this chapter, we take a look at using the BIND key.

Let's look at this code sample again.

import author Ziddia;

import Universe u;

import Dimension d;

import Object o1, o2;

import Session s;

~ATH(author) {

    SET[o1, author];

    SET[o2, GET[Globals.DISPLAY]];

    BIND[o1, s];

    BIND[o2, s];

    BIND[s, d];

    BIND[d, u];

    ~ATH(u) {

        SET[u, NULL];

    } EXECUTE(THIS);

} EXECUTE(THIS);

THIS.DIE();

Now, I'd like you to focus on the four BIND key statements. These are the most important bits in this.

BIND is actually quite simple when you get down to it. It takes the data of one object and appends it to another. For example, if you bound a Being to a Universe, they would be shifted from their own universe to the one you bound them to. Fairly straightforward.

Let's look at the first one. All this is doing is binding the author (or, the player of the game) to the Session that they will be participating in. The second one is more or less the same, as it binds the Display to the session. This allows the person running the Display to see what is happening in the Session.

We then go on to bind the Session to the current Dimension, and the Dimension to the current Universe. While those last two were not technically necessary - considering the Session already exists in this Dimension and Universe - it helps for debug and for keeping stable loops and undefiled Graves.

We also have an example of nested ~ATH loops. Nested loops are a powerful feature that allow you to start a loop only when another one executes. For example, in the example above, we have a nested loop which will begin running after the author dies. It Listens for the death of the Universe. Once the Universe dies, it executes and nulls the Universe.

Nested ~ATH loops and a programming technique called !ATH go hand in hand. !ATH is fairly advanced, and keeping stable loops while using it can be complicated, but the way !ATH works is enough to more than counterbalance the damage it can do.

In most programming languages, an !-operator checks for the opposite f something. The same is true for ~ATH. !ATH checks for your condition, but only executes it while it is alive, rather than dead. For example...

import author Ziddia;

import Universe u;

import Dimension d;

import Object o1, o2;

import Session s;

~ATH(!author) {

    SET[o1, author];

    SET[o2, GET[Globals.DISPLAY]];

    BIND[o1, s];

    BIND[o2, s];

    BIND[s, d];

    BIND[d, u];

    ~ATH(u) {

        SET[u, NULL];

    } EXECUTE(THIS);

} EXECUTE(THIS);

THIS.DIE();

This is exactly the same as the other example, excluding one little detail - I used !ATH on the author Object. By using !ATH, I have caused this program to execute when I am alive.

Note that there is presently a sandbox in place when it comes to ~ATH programs that use Universe, Dimension, Session, and Author which prevents directly deleting or killing objects. This sandbox is also in place for all !ATH programs, regardless of content. It was implemented in an attempt to nullify the effects of viruses such as the Mobius Double Reacharound Virus. This sandbox is removed for applications that are signed by the government (applications that are currently known to have this removed are the Government's own Low-Orbital ~ATH Cannon, which is used to combat terrorism, and Sburb).

Chapter Text

~ATH is a great language to work with, especially now that you know about !ATH and the BIND key. But just how much more can you do with a script?

It turns out that you can do a hell of a lot more. We've barely brushed the surface of keys, and we haven't even begun to look at the Standard ~ATH Kit. ~ATH has so much more to offer than just what I've shown you. As such, the next two chapters are dedicated to learning the functions of most (if not all) keys.

To begin, here's a list of all keys and their description in the official ~ATH documentation (check in your ~MYATH panel for a link to the docs). The words in the brackets are the arguments they take, and are generally fairly self-explanatory.

- ~ATH(Object): The key representing a main script loop.
- EXECUTE(Script): The key representing an execution statement. Equivalent to GET[Globals.CURRENTSCRIPT].COMMANDPARSER.EXECUTE(Script).
- THIS: A key representation of the Script object being used.
- NULL: Nothing. Generally used as a fail-safe in loops which fail to execute.
- import: Key used for definitions and pre-execution binding.
- author: Key used to represent the creator of the script. Equivalent to GET[Globals.CURRENTSCRIPT].AUTHOR.
- SET[Object, Object]: Key used to assign values.
- GET[Object]: Key used to check values.
- BIND[Object, Object]: Key used to bind two Objects together.
- KILL[Object]: Key for killing an Object instance. This is banned when Sandbox is in place (the majority of ~ATH programs will experience this).
- SPLIT[Object, Object]: Key for splitting an Object into two streams. Splits the first argument, not the second. Assigns the original to the first Object, the copy to the second.
- COMB[Object, Object]: The BIND key for streams.
- STREAM[Stream]: Gets a Stream Object.
- BIFURCATE[Object]: Splits an Object into two mirror streams. Advanced and extreme programming technique.
- CAKE[Script]: Calls a ^CAKE script for execution.
- ~IF(Condition): Checks a condition.
- ~WHILE(Condition): Executes a piece of code while a condition is true.
- ~ELSIF(Condition): Checks again after a prior ~IF.
- METHOD[Object, Array]: Creates a new Method, accessible from any other script. An example of a method defined like this is Object.DIE(). DIE is the method, and there are no arguments in the Array.

~ATH also includes a bunch of keys which are broken or useless. Make sure to NEVER use these.

- define: Key that's supposed to be used for definitions; causes ~ATH to crash.
- ship[Object, Object]: Unknown. It's not listed in the docs, but it's set in the ~MYATH panel. It's been confirmed to have something to do with the Troll Reproductive Cycle, the Imperial Drones, and the Exile aspect of the game Sburb. No one else knows how to use it though.
- for[Condition, Condition, Condition]: Some sort of ridiculous leftover from when the lead programmers moved from PHP/HTML to ~ATH. Completely useless, and crashes scripts.
- SANDBOX: Emergency cancellation or restriction. Unusable in modern ~ATH scripts, although beta testers report that it was available in an early version, and that it was capable of automatically cancelling any script, as an outside command, no matter what the script is doing.
- ABORT[Object]: Unknown. Never used in any program I know of.
- ASCEND[Object]: Unknown. Used in a small side-script in Sburb. Having never played Sburb, I'm not sure how that works. While testing under sandbox, I found that feeding it anything but an Author causes it to crash; when fed an Author, it explodes the computer and cancels itself instantly.
- DESCEND[Object]: Another weird Sburb-only key. Similar warnings and requirements.

For this chapter, I will take a look at SPLIT, COMB, and STREAM. BIFURCATE and METHOD get the next chapter. The loops will be in the third and final part of this arc.

The SPLIT key is probably one of the most important keys, right up there with BIND. SPLIT is like ~ATH's own copy machine. It takes two objects as its arguments, and basically creates an exact copy of the first Object. The two objects - the original, and the copy - are now known as Streams.

SPLIT is essential to objects like the Sendificator, for example. All the Sendificator needs to do to send an object out is use SPLIT on the object to send, move the copy to the new location, and destroy the original. The same is true for the Appearifier, but in reverse.

A simple script demonstrating the use of SPLIT is shown below. It's a script extracted from an old Sendificator.

import Sendificator s;

import Universe u;

import Location l;

import Object o, o1;

~ATH(!u) {

    SET[l, GET[s.LOCATION_TO_SEND]];

    SET[o, GET[s.OBJECT_ON_PLATFORM]];

    SPLIT[o, o1];

    SET[o1.LOCATION, l];

    o.DIE();

} EXECUTE(THIS);

THIS.DIE();

This should be a piece of cake for you to read by now.

The first thing we need to notice is their custom Sendificator class. All we need to know about that is that it has two variables - LOCATION_TO_SEND being the Location displayed on the screen, OBJECT_ON_PLATFORM being the Object to send.

It sets the Location - named l - to the co-ordinates to send the object to. It sets an Object - o - to the Object you wish to send. It then splits the Object named o into two streams that are exactly the same, named o and o1. It sets the location of the copy to the sending place, and then kills the original. Simple!

Now, we need to look into combining two streams. The COMB key is the thing we need for this job.

Combining two Streams is like using BIND on a pair of Objects, but with a twist. Where BIND merely appended the data of one to the other, COMB actually combines them on the Mortal plane.

This may seem impractical, but think about it. We all know about Captcha codes. We all know about Alchemiters. How do you think that the Alchemiter works? That's right - it turns two totems into Streams, and then uses COMB to create a new Object.

It can also be used to re-combine a stream and a copy, thus creating one Object with the experiences of both Streams.

I think that this should be simple enough, so we move on to the easiest part of this particular tutorial - the STREAM key.

STREAM is used almost exclusively in SET to transform an Object directly into a Stream. By this, I mean that it will create a new Stream without going through the process of splitting an Object. This, too, should be straightforward.

If you need any help or extra examples, leave a message in the comments. I'll be sure to help you out with your scripts! Next up is Bifurcation and Method Creation!

Chapter Text

Hi guys! The following is a direct note from the developers of ~ATHFORASSHOLES, which was recently updated to Version 2.0! I highly recommend you update, as this new version introduces a whole heap of new stuff.

The message:

"Hello to all ~ATH developers! As you all know, we at ~ATHFORASSHOLES have been holding back on Version 2.0 of our popular IDE for a while now. There were a multitude of reasons for this, but we finally fixed most of the bugs, and we're pretty confident that it will meet your expectations!

~ATHFORASSHOLES includes a whole heap of new features, including these:

- Bifurcation support! (Almost).
- A new panel for ^CAKE and &VIL, making it three IDEs in one!
- The Generate tab, which can create basic outlines of a script!
- A framework for an autocomplete mechanism, which should be out in ~ATHFORASSHOLES 2.1, along with the coloring!
- Seperate sections for Build and Save!
- ~ATH compile encoding - this means we're finally compatible on every OS out there!

There are a few small bugs we are aware of. These will hopefully be fixed in 2.1/2.2.

- The Universe tab in Generate fails. We're looking into it.
- Sometimes, Build from Generated source can fail. Once in a hundred times, though.
- Attempting to open a non-~ATH file can crash the IDE.
- We haven't managed to restrict the files in load and save to ~ATH only, or the files to build to COMPILED_ATH only, so that can crash it.

We're very proud of this success, and we can only get better thanks to everyone's help!"

I'm excited, and you should be too! This is a huge step forward in ~ATH development.

You can download the program from here: http://dl.dropbox.com/u/18856017/ATH.zip

Enjoy!

Chapter Text

speed-edit: coloring is broken, will upload a picture soon

Now that we've worked out how Streams work, it's time to move onto the single most complicated and useful portion of ~ATH programming: Bifurcation. Bifurcation can be an extremely useful tool, or it can be a hindrance. It's important to note that not using bifurcation in stream-heavy code is like signing your own death warrant; it greatly simplifies and speeds up your code. If bifurcation didn't exist, there's no way Pesterchum and previous chat clients would ever have been useable, with all the lag they would cause.


Bifurcation is somewhat difficult to define, as it's a concept which hasn't been used in any programming language previously. While I define it as 'creating two mirror streams' in the previous chapter, it's far more complex than that makes it seem. Essentially, bifurcation has little or no effect on the world, dimension, universe, plane, session, or author, which is highly unusual for a key in ~ATH. Instead, its main focus is the program itself. Bifurcation will not split actual objects, but the code representation of the objects.


The most basic example of bifurcation is to split the program proper into two bifurcated Streams. This can be accomplished in two ways - one is shorthand and uses the quick key, the other is longer and was the only method supported until recent updates.

// Short form

BIFURCATE[THIS];

// Long, 'proper' form

bifurcate THIS[THIS, THIS];

Bifurcation is incredibly useful in that it follows a specific set of rules that allow for isolation, concurrency, and exactness. Bifurcated Streams have four major laws, which define these aspects:

1. Bifurcated Streams are exact mirrors of each other at their conception

2. Bifurcated Streams can act independently of each other, and are thus able to interact with each other

3. Bifurcated Streams are capable of running simultaneously

4. Objects within Bifurcated Streams are also turned into perfect Bifurcated Streams, and can be interacted with through the main Bifurcated Stream.


These laws may seem odd to you know, but they will be incredibly useful in the continued study of ~ATH. Here is an example program, which displays these four major laws in an appropriate fashion:

import author Ziddia;

import Universe u;

import Session s;

import Object o, o1, o2;

~ATH(!u) {

    SET[o, author];

    SET[o1, u];

    SET[o2, Globals.DISPLAY];

} EXECUTE(THIS);

BIFURCATE[THIS];

~ATH(!THIS) {

    SET[THIS.o2.TEXT, "The value of o is " + THIS.o];

    SET[THIS.o, THIS.o1];

    SET[THIS.o2.TEXT, "The value of o is " + THIS.o];

} EXECUTE(THIS);

THIS.DIE();

~ATH(!THIS) {

    SET[THIS.o, THIS.s];

    SET[THIS.o2.TEXT, "The value of o is " + THIS.o];

    SET[THIS.o, THIS.o2];

    SET[THIS.o2.TEXT, "The value of o is " + THIS.o];

} EXECUTE(THIS);

THIS.DIE();

THIS.DIE();

Wow, I can almost hear you say. This looks impossibly difficult! But really, when I spell it out for you, you'll be able to grasp it quite quickly.

Firstly, take note of our ridiculous amount of imports we have. This is the first time we've worked with 3 objects; a large amount of objects is fairly typical for bifurcated scripts, since you'll want to store large amounts of information in them. Next, look at the first !ATH statement. Within it, we SET each of the objects - one handles the author, one handles the Universe, one handles the Display.  Where we would normally call THIS.DIE(), at the end of this !ATH block, we continue on. The bifurcate statement is shown now, and that's still easy enough to grasp. Then, we get to the colours.

Bifurcated code isn't simply recognized through special keys or text. No, for the compiler to recognize bifurcation, each bifurcated portion is in a different color. Using the long form of the bifurcation statement, you can set the colors yourself. If you're using shorthand like I did, then default text bifurcates into Red and Blue, Red bifurcates into Green and Yellow, Blue bifurcates into Purple and Pink, and each of those continue to bifurcate with more and more colors.

Now, we see the demonstration of the first and fourth laws of Bifurcated Streams. Both the Blue and Red Streams have exact copies of the original objects - however, although the objects are all called through THIS, the coloration decides which stream the object is pulled and modified from.

Next, we can see in both streams that objects are completely independent of one another. One thing to note here is o2's (or rather, Globals.DISPLAY's) TEXT object. TEXT can be set to any line of text, and the line of text you set it to is automatically read and written to the screen, with the TEXT object emptied microseconds later. Anyway, because each stream is setting objects and text independently, we can see the second law in action.

Finally, we have the law concerning concurrency, and this one is more difficult to explain without running the code. You would expect the output to the screen from this to be:

The value of o is Ziddia

The value of o is Universe

The value of o is Session

The value of o is Globals.DISPLAY

However, due to the law of concurrency, this is not the case. Both Streams work independently of each other, with two separate instances of the runtime - one for Red code, one for Blue code. They execute commands at exactly the same speed - concurrently. Therefore, we can break it down like this:

SET[THIS.o2.TEXT, "The value of o is " + THIS.o]; / SET[THIS.o, THIS.s];

Output : The value of o is Ziddia

SET[THIS.o, THIS.o1]; / SET[THIS.o2.TEXT, "The value of o is " + THIS.o];

Output: The value of o is Session

SET[THIS.o2.TEXT, "The value of o is " + THIS.o]; / SET[THIS.o, THIS.o2];

Output: The value of o is Universe

(none) / SET[THIS.o2.TEXT, "The value of o is " + THIS.o];

Output: The value of o is Globals.DISPLAY

As you can see, the concurrency factor plays a huge part. Programs such as Pesterchum rely on this to allow users to post messages at exactly the same time, without which messages would likely become lost.

I realise that this lesson was likely confusing, so if you have any questions or concerns, don't be afraid to comment.