Send Expressions

      Most of the important details about sending events were covered in the previous section, but this section includes some details that were missed in that overview. Send expressions have two   forms:

expression -> name ( val, val, )

expr -> [ expr ] ( val, val, )

In both cases Glish evaluates the expression to the left of the -> operator to see whether it's an agent. If not, an error is generated. Otherwise the name of the event is taken from   either name or by evaluating expr, which must yield a string scalar. The following are equivalent:

    a->foo( 5 )
    a->["foo"]( 5 )

The second send-event form is quite flexible. Here, for example, is one way to send a three events, foo, bar and bletch, with values of 1, 2, and 3:

    for ( i in 1:3 )
        a->["foo bar bletch"[i]]( i )

    The value of the event is taken from the various val's. If you specify just one val then that's the event's value. If you don't list any val's then the event's value is F. If you give more than one val then Glish constructs a record from the val's. In this latter case usually the val's are given names, using the same name = expression syntax as when creating records (§ 3.4.1, page ) or calling functions (§ 6.4.1, page ). See § 7.3 for examples of sending events.

Depending on the context in which the send expression occurs, a result value may be required from the agent, e.g.

    print a->foobar( action="show all" )

here print requires a result value. There are a few salient points regarding these send expressions which require a result:

• Presently you can only use request/reply events with clients; not with subsequences (§ 7.12, page ), which presently just immediately return F in reply to the request (and never see the request event).
• After a client is sent a request, the Glish interpreter waits for that client to generate a single event in response. Any events generated by any other clients are blocked (they will be processed normally once the requested client replies). If the requested client generates any event other than a reply to the request, the Glish interpreter generates a warning and treats the event as a reply anyway.
• If you find you cannot abide waiting for the requested client to reply, then you should consider instead using an await statement (§ 7.6, page ) or restructuring your application to use a whenever statement.
• The reply event sent by the client does not have a name, just a value. In particular, no value for it gets entered in the client's agent record (§ 7.2.2, page ).