/ elang / kernel

Immediate Call Expression

Has the conventional meaning -- ask the recipient to immediately perform the action named verb as parameterized by the argumens. This is the synchronous call-return message pass familiar from a zillion object programming languages.

BNF:	eExpr Verb ["(" eExpr ("," eExpr)* ")"]
XML DTD:	<!ELEMENT callExpr (%eExpr;, Verb, (%eExpr;)*)>
Java:	E.call(jExpr, "verb", jExpr...)
Example:	a + b * c
in Kernel-E:	a.add(b.multiply(c))
in XML:	<callExpr verb="add"> <Noun>a</Noun> <Verb>add</Verb> <callExpr> <Noun>b</Noun> <Verb>multiply</Verb> <Noun>c</Noun> </callExpr> </callExpr>
in Java:	E.call(a, "add", E.call(b, "multiply", c))

The recipient is the value of the expression on the left and the arguments are the values of the expressions between the parens. As is typical in E, expressions are evaluated left to right, and variables defined on the left are visible on the right. How the recipient responds to the request is purely up to the recipient, and should be documented according to the type of recipient. The three forms of recipient are

• Primitives: any object not defined in E but accessible from E
• Methodical objects: objects defined using the methodical object expression.
• Plumbing objects: objects defined using the plumbing expression.

all of which must be designated with a NEAR reference. If the recipient is designated by an EVENTUAL or BROKEN reference, the call terminates with a thrown exception without any involvement by the recipient. Therefore, calls only succeed among objects within the same vat.

The recipient receives the string which is the verb, the list of argument values, and by synchronous call context, the implicit continuation (like a return address) it uses to exit the call. It may exit the call by normal return of a value, by throwing a problem, or by ejection with an ejector. The outcome of the call we then be the normal evaluation to a value, a throw, or an ejection.

This all follows strict stack discipline. During the call, the caller is blocked waiting for the call to exit. Once the call exits, the synchronous processing of the call by the recipient is necessarily over. All synchronous side effects performed by the recipient as part of its synchronous processing of the message are guaranteed to have taken place before the caller continues. Implicit continuations cannot be made explicit, and are use-once.

The continuations at any time form a linear chain, not a tree, and they can only be used in the reverse order in which they were created. This chain is the call-stack. At any moment, an individual vat has at most one call-stack. Activity within the call stack therefore knows that it has mutually exclusive access to everything it has synchronous access to, ie, everything in its own vat.

The top continuation of a call stack looks like the continuation of a call from its recipient's point of view -- we still say the recipient has been called. However, there cannot be a caller, because we'd then have to wonder who called it. Or, we'd have to postulated the uncalled call (sorry). Instead, the top continuation is for a delivery, which is a eventual consequence of a send expression. When a delivery exits the vat at that moment has no stack. We say all the activity from the start of a delivery to the exiting of the delivery is a turn. Like a game turn, it runs to completion exclusively changing the state of the vat (board), but when it's done, it yield completely to the next turn. A turn therefore also has many of the properties associated with transactions. Activity in a vat proceeds serially through a sequence of turns.