OEP

142

Title

Extended outputs

Summary

Allow extended outputs, the opposite of extended inputs.

Owner

Carl Ritson

Status

Proposed

Date-Proposed

2006-03-14

Keywords

language output channels

The converse of an extended input -- an extended output, in which some code can be executed while the other party is blocked on the input -- could be useful for interfacing to things that must be polled, such as a real-time clock or an FFI-interfaced C library. The process would commit to doing an output, but only run the code to determine the value to output once it knew that the other party was trying to read. The syntax could look something like the existing VALOF block:

INT v:
c !!
  ...  set v
  OUTPUT v

The merits of output guards in ALTs have been debated in the past; if they were supported, then extended output guards should also be made available.

Having CIF bindings for extended outputs would make operations on static mobile types simpler in some cases, avoiding the need to allocate from mobilespace.

Trivial change suggested by P.H.Welch (09/08/2012): rather than inventing a new keyword (OUTPUT), reuse the !! symbol:

INT v:
c !!
  ...  set v
  !! v

Semantics: this is given by a formal transformation of the system code employing it. Suppose we have the above process running in parallel with:

c ? x

Invent a BOOL request channel, say c.request. The extended output process becomes:

INT v:
SEQ
  c.request ! TRUE    -- only accepted by receiver when ready for our data
  ...  set v
  c ! v

The receiving process becomes:

BOOL any:
SEQ
  c.request ? any
  c ? x

If the receiving process were an ALT guard, an obvious variation of the transformation applies.

Note: an implementation can be much lighter than this - no need for a request channel and additional communication.

OEP/142 (last edited 2012-08-09 14:19:32 by phw)