/ e	E World Scripting Examples in the C syntactic tradition (from a correspondence with Tony Grant, archived on ec_ez)

This document presents examples in E for scripting behaviors in our virtual worlds. Tony started things off with examples showing how our worlds might be made easily scriptable for the Visual Basic programmer. After some (archived) iterations, here is my best take on doing Tony's examples within all our foundational constraints--including capability secure programming--in the E language. The examples use E as it works today except for two enhancements noted below.

Here is Tony's original message. The examples in this document and Tony's message are now cross-linked to each other so you can easily see how the examples compare. IMO, the results compare well with the imagined Visual Basic code. For those more comfortable with the Visual Basic syntactic tradition, here is a version of this document you may like better. The E language accepts both styles.

However, I'm almost totally ignorant of Pluribus and of the internals of the cosm level of our system, so the interface to it presented here may be wholly unrealistic. Cosm/Unum programmers: How reasonable are our assumptions? How reasonable are our examples?

Hypothetical Unum/Puppet/Cosm Interface

Standard events:

    noticeClick
    noticeBump(other)
    noticeRegionEntry(avatar)
    noticeRegionExit(avatar)
    noticeSpeech(avatar, text)

"other" and "avatar" above would probably be some appropriate level of puppet, but none of this has been revisited since the puppet revolution. Suggestions and clarifications would be most appreciated!

"Instance" Variables:

    myName
    myPossessions
    myOwner
    myRegion
    myBody

"Global" Name Spaces:

    bodies
    regions
    gestures

"Global" Functions:

    PlayGesture(gesture)
    Say(text)
    TestLaunch(avatarBody, region)
    WalkTo(region)
    TeleportTo(region)
    RandomElement(collection)

(I need to understand more about portals & teleport pads)

>1. Launch Microcosm with Yappy as the avatar and have him transition back
>and forth between CentralPark region and BeachResort.
>
>This would help us to find any memory leaks occurring on transitions. I
>don't know how much overhead would be involved in this, but it would be
>great if it were simple:

    TestLaunch(bodies["Yappy"], regions["CentralPark"])

    for i in (1..100) {
        TeleportTo(regions["BeachResort"])
        TeleportTo(regions["CentralPark"])
    }

>2. Visit every region in a realm. This would a great script to run after
>new art checking to make sure that none of the new regions have broken the
>world.

    TestLaunch(bodies["Dax"], regions["CentralPark"])

    for r in (myRegion realm regions) {
        TeleportTo(r)

}

>3. Simple Click response:

    on noticeClick {
        Say("Ow!")
    }

>4. The next generation Click response. Play a random gesture.

    on noticeClick {
        PlayGesture(RandomElement(gestures))
    }

Where RandomElement could be defined by:

    def RandomElement := to (collection) {
        def elements := collection indexable
        elements[elements size random]
    }

>5. A greeting bot. When an avatar enters the region, the bot welcomes him
>or her:

    on noticeRegionEntry(avatar) {
        Say("Hi " + avatar name + ". Welcome to KidsWorld!")

}

>6. A ridiculously simple Eliza:

    on noticeSpeech(avatar, text) {
        Say("That's interesting " + avatar name + ". Tell me more about " + text)
    }

>7. Have a bot in your Turf that reacts to the mention of your name.

    on noticeSpeech(avatar, text) {
        if (text includes(myOwner name)) {
            PlayGesture(gestures["Spin"])
            Say("I sure do love " + myOwner name)
        }
    }

>8. The wandering avatar: (no error checking for a region with no portals)

I'm not sure what you intended by saying "no error checking". If you want to code in ignorance of the issue of errors, uncaught errors will terminate your loop:

    TestLaunch(bodies["Dax"], regions["CentralPark"])

    for i in (1..100) {
        WalkTo(RandomElement(regions))
    }

The first WalkTo that throws an error will exit this loop. Alternatively, if you want to ignore errors and keep going:

    TestLaunch(bodies["Dax"], regions["CentralPark"])

    for i in (1..100) {
        try {
            WalkTo(RandomElement(regions))
        } catch {}
    }

try/catch is how you handle errors. The empty curlies after the 'catch' say to do nothing on an error.

Assumed E Enhancements

E has already reserved the "on" keyword. This document assumes that the "on" keyword has been added to the language in a role similar to the existing "to" keyword. The difference between "on" and "to" reflect two very different purposes for invocation (calling/sending) in object oriented programming.

• When object A invokes object B, usually it is to serve a purpose of A's, and the invocation can be seen as an imperative or query. The invocation is assumed to be on the caller's behalf. For this case the "to" form is used to define the corresponding method, as in "to verb(arg, ...) { body }", and invocation can be either a synchronous call or an asynchronous send ("<-"). A synchronous call is a sensible possibility since A is subcontracting to B, and B's effects are typically part of the effects A is trying to bring about. Since the invocation is assumed to be on A's behalf, a to-invocation has an implicit return value, which is a Promise in the asynchronous case.

• The other common purpose for an invocation is event notification (called by various o-o commentators Observers, Dependents, Reactors, ...). Typically, object B will have earlier registered with A an interest in certain kinds of events. Later, when A decides that these events have occurred, it informs all interested parties, like B, by invoking them. These invocations are assumed to be on the callee's behalf. The method would be defined as "on eventName(arg, ...) { body }", and the corresponding invocation could only be asynchronous ("<-"), since B's reactions to the event (and any consequent side effects) are not properly part of the action A was in the midst of. By the same token, A is assumed not to be interested in any results or exceptions from B, so no implicit return value is supplied.

As Hypercard has shown, the event driven model is quite pleasant. Unlike Smalltalk, Hypercard does not make an object register in order to receive notifications of events it's interested in. It suffices to have (the equivalent of) an on-method for that event, and to be in a context in which these events are ambient. For our worlds, the Frame/Session (or maybe the container?) can serve as such a context. [Need to explain group membership] We therefore need a CRAPI-like E meta-protocol so such a context can find out, when an object is added to that context, what on-methods it has. An object can be assumed to be interested in any event it has an on-method for.