Guide:Execution Model - Revision history

Admin: /* Execution model */

2012-10-05T14:36:57Z

‎Execution model

spambot_Tumble: /* Execution model */ minor grammar

2009-04-08T08:24:26Z

‎Execution model: minor grammar

spambot_Mdobmeier: /* Execution model */

2009-02-08T10:58:47Z

‎Execution model

Cv: New page: = Execution model = The way an Ioke program work is very simple. Everything executes based on two things. The first is the context, or the ground, and the second is the receiver. The firs...

2009-01-25T23:03:39Z

New page: = Execution model = The way an Ioke program work is very simple. Everything executes based on two things. The first is the context, or the ground, and the second is the receiver. The firs...

New page

= Execution model =

The way an Ioke program work is very simple. Everything executes based on two things. The first is the context, or the ground, and the second is the receiver. The first message sent in each message chain will have the ground as receiver. The default ground in Ioke source files is an object called Ground. This object is in the mimic chain for most regular objects created in Ioke, which means that things defined at the top level will generally be available in most objects. Inside of methods and blocks, the ground will be different. Exactly in what way is defined by the type of code executing.

Every message in a chain will be sent to the receiver of that message. That receiver is the result of the last message, or the current ground if there was no previous message, or if that previous message was a terminator. So Ioke code like "foo bar(flux bar) quux" involves 5 different messages.

# The message "foo" is sent to Ground, which is the current ground and also the default receiver.
# The message "bar" is sent to the result of the "foo" message. The value returned will be activated.
# The cell "bar" contains a method in this case, and that method expects one argument, so that forces evaluation of the arguments.
# The message "flux" is sent to Ground, since it's the ground and there is no prior message inside of an argument list.
# The message "bar" is sent to the result of the "flux" message.
# The result of the "bar" message is used as the argument value given to the outside "bar" method.
# The message "quux" is sent to the result of the initial "bar" message.
# The result of the quux message is thrown away, unless this code is part of a larger piece of code.
This description generally describes what happens in the case of this code. The more general control flow is this:

# A message is encountered
# If the message is a symbol message, the corresponding symbol will be returned.
# Otherwise the name of the message will be looked up in the receiver, or in the receivers mimics.
# If the name is found and is not activatable, the value of that name (the cell) is returned.
# If the name is found and is activatable, it will be activated, with the current ground, receiver and message sent to the activatable object.
# If the name is not found, a second search is done for the name "pass". If a pass is found, use that instead of the name of the original message, and go back to 4.
# If a pass is not found, signal a Condition Error NoSuchCell condition.
Exactly what happens when an object is activated depends on what kind of code gets activated. It's really up to the method, block or macro to handle evaluation of arguments in any way it likes - including not evaluating them. For a description of the default models available, see the chapter on [http://{{SERVERNAME}}/#code code]

@@ Line 21: / Line 21: @@
 # If the name is found and is activatable, it will be activated, with the current ground, receiver and message sent to the activatable object.
 # If the name is not found, a second search is done for the name <code>pass</code>. If a pass is found, use that instead of the name of the original message, and go back to 4.
-# If a pass is not found, signal a [http://ioke.org/dok/kinds/Condition/Error/NoSuchCell.html <code>Condition Error NoSuchCell</code>] condition.
+# If a pass is not found, signal a [http://ioke.org/dok/release/kinds/Condition/Error/NoSuchCell.html <code>Condition Error NoSuchCell</code>] condition.
 Exactly what happens when an object is activated depends on what kind of code gets activated. It's really up to the method, block or macro to handle evaluation of arguments in any way it likes - including not evaluating them. For a description of the default models available, see the chapter on [[Guide:Code|code]].

@@ Line 1: / Line 1: @@
 = Execution model =
-The way an Ioke program work is very simple. Everything executes based on two things. The first is the context, or the ground, and the second is the receiver. The first message sent in each message chain will have the ground as receiver. The default ground in Ioke source files is an object called <code>Ground</code>. This object is in the mimic chain for most regular objects created in Ioke, which means that things defined at the top level will generally be available in most objects. Inside of methods and blocks, the ground will be different. Exactly in what way is defined by the type of code executing.
+The way an Ioke program works is very simple. Everything executes based on two things. The first is the context, or the ground, and the second is the receiver. The first message sent in each message chain will have the ground as receiver. The default ground in Ioke source files is an object called <code>Ground</code>. This object is in the mimic chain for most regular objects created in Ioke, which means that things defined at the top level will generally be available in most objects. Inside of methods and blocks, the ground will be different. Exactly in what way is defined by the type of code executing.
 Every message in a chain will be sent to the receiver of that message. That receiver is the result of the last message, or the current ground if there was no previous message, or if that previous message was a terminator. So Ioke code like <code>foo bar(flux bar) quux</code> involves 5 different messages.

@@ Line 1: / Line 1: @@
 = Execution model =
-The way an Ioke program work is very simple. Everything executes based on two things. The first is the context, or the ground, and the second is the receiver. The first message sent in each message chain will have the ground as receiver. The default ground in Ioke source files is an object called Ground. This object is in the mimic chain for most regular objects created in Ioke, which means that things defined at the top level will generally be available in most objects. Inside of methods and blocks, the ground will be different. Exactly in what way is defined by the type of code executing.
+The way an Ioke program work is very simple. Everything executes based on two things. The first is the context, or the ground, and the second is the receiver. The first message sent in each message chain will have the ground as receiver. The default ground in Ioke source files is an object called <code>Ground</code>. This object is in the mimic chain for most regular objects created in Ioke, which means that things defined at the top level will generally be available in most objects. Inside of methods and blocks, the ground will be different. Exactly in what way is defined by the type of code executing.
-Every message in a chain will be sent to the receiver of that message. That receiver is the result of the last message, or the current ground if there was no previous message, or if that previous message was a terminator. So Ioke code like &quot;foo bar(flux bar) quux&quot; involves 5 different messages.
+Every message in a chain will be sent to the receiver of that message. That receiver is the result of the last message, or the current ground if there was no previous message, or if that previous message was a terminator. So Ioke code like <code>foo bar(flux bar) quux</code> involves 5 different messages.
-# The message &quot;foo&quot; is sent to Ground, which is the current ground and also the default receiver.
+# The message <code>foo</code> is sent to <code>Ground</code>, which is the current ground and also the default receiver.
-# The message &quot;bar&quot; is sent to the result of the &quot;foo&quot; message. The value returned will be activated.
+# The message <code>bar</code> is sent to the result of the <code>foo</code> message. The value returned will be activated.
-# The cell &quot;bar&quot; contains a method in this case, and that method expects one argument, so that forces evaluation of the arguments.
+# The cell <code>bar</code> contains a method in this case, and that method expects one argument, so that forces evaluation of the arguments.
-# The message &quot;flux&quot; is sent to Ground, since it's the ground and there is no prior message inside of an argument list.
+# The message <code>flux</code> is sent to <code>Ground</code>, since it's the ground and there is no prior message inside of an argument list.
-# The message &quot;bar&quot; is sent to the result of the &quot;flux&quot; message.
+# The message <code>bar</code> is sent to the result of the <code>flux</code> message.
-# The result of the &quot;bar&quot; message is used as the argument value given to the outside &quot;bar&quot; method.
+# The result of the <code>bar</code> message is used as the argument value given to the outside <code>bar</code> method.
-# The message &quot;quux&quot; is sent to the result of the initial &quot;bar&quot; message.
+# The message <code>quux</code> is sent to the result of the initial <code>bar</code> message.
-# The result of the quux message is thrown away, unless this code is part of a larger piece of code.
+# The result of the <code>quux</code> message is thrown away, unless this code is part of a larger piece of code.
 This description generally describes what happens in the case of this code. The more general control flow is this:
@@ Line 20: / Line 20: @@
 # If the name is found and is not activatable, the value of that name (the cell) is returned.
 # If the name is found and is activatable, it will be activated, with the current ground, receiver and message sent to the activatable object.
-# If the name is not found, a second search is done for the name &quot;pass&quot;. If a pass is found, use that instead of the name of the original message, and go back to 4.
+# If the name is not found, a second search is done for the name <code>pass</code>. If a pass is found, use that instead of the name of the original message, and go back to 4.
-# If a pass is not found, signal a Condition Error NoSuchCell condition.
+# If a pass is not found, signal a [http://ioke.org/dok/kinds/Condition/Error/NoSuchCell.html <code>Condition Error NoSuchCell</code>] condition.
-Exactly what happens when an object is activated depends on what kind of code gets activated. It's really up to the method, block or macro to handle evaluation of arguments in any way it likes - including not evaluating them. For a description of the default models available, see the chapter on [http://{{SERVERNAME}}/#code code]
+Exactly what happens when an object is activated depends on what kind of code gets activated. It's really up to the method, block or macro to handle evaluation of arguments in any way it likes - including not evaluating them. For a description of the default models available, see the chapter on [[Guide:Code|code]].