XML CO538 Anonymous Questions and Answers Keyword Index

This page provides a keyword index to questions and answers. Clicking on a keyword will take you to a page containing all questions and answers for that keyword, grouped by year.

To submit a question, use the anonymous questions page. You may find the keyword index and/or top-level index useful for locating past questions and answers.

Keyword reference for result

Question 56 (2011):

Submission reference: IN2089

In Question 55 (2011), you wrote:

"From the software engineering principle of cohesion, your move process should just move the rover, reporting back its success and distance moved through reference data parameters. It should not have the additional responsibility of reporting that result back to mission control (which it currently does via the opr.resp channel). The latter should be done separately by whatever has invoked the move. In this way, you will be able to reuse this move code for other purposes – e.g. for Task 4."

I'm not quite sure what you mean by "reference data parameters", please could you explain?

Answer 56:

See basics slides 37, 67 and 68. The parameter result is a reference data parameter and, in this example, is expected to be set by the code within the body of the foo process before that terminates. When foo is invoked, an INT variable must be supplied as its third argument (slide 68) – anything the foo code does with result will actually be done to the variable supplied. See also this relevant bit from the occam-pi Reference wiki (which is linked from the "Practical Resources" box on the Moodle page for this course).

In this way, occam-pi PROCs can return results (plural: there can be any number of reference parameters), as well as interact with their environments (through channel communications, barrier syncs etc.). [Aside: occam-pi FUNCTIONs also return results (plural), but they are not allowed side-effects (e.g. interacting with their environments).] For the example provoking this discussion, your move process could have a reference boolean parameter (for success) and a reference integer (for distance).

Revision: VALue data parameters cannot be changed by their PROC body (i.e. they are constants). Supplied arguments may be variables, constant literals or expressions (basics slides 37and 67).

Constant literals or expressions may not, of course, be supplied as arguments for reference parameters.

Also, the answer to Question 57 (2010) is highly relevant to this question – so, do check this as well. The question in Question 57 (2010) may be best ignored!

Final note: better than reference parameters for returning PROC results are RESULT parameters. RESULT parameters are new in occam-pi, not in any course materials and, of course, not examinable. However, they are very simple, easy to use and improve security – see Question 58 (2010) and (the end bit of) Question 60 (2010).

Keywords: mars , parameter , reference , value , result

Referrers: Question 58 (2011)

Question 60 (2010):

Submission reference: IN1956

I'm experiencing an embarrassingly stupid problem with reading a value on a channel into a variable.

  PROC a (CHAN INT a?)
    CHAN INT b:
    INT output:
    SEQ
      some.proc (a?, b!)
      b ? output
      ...  do stuff with output
  :

"some.proc" hangs when it outputs on b because I guess nothing picks up the value. Can you please suggest what I need to do to get this to work? The compiler warns about sequential input/output on b but I can't think how else to express that I just want the value on that channel assigned to a variable.

Answer 60:

The code you have above tries, in SEQuence, to output then input on the same channel (b). Because channel communication is synchronous, the output (inside "some.proc") will just block, because there is no parallel process to communicate with. That process ("b ? output") cannot run until the call to "some.proc" completes, because of the SEQ, thus deadlock. The answer is to add some parallelism, e.g.:

    PROC a (CHAN INT a?)
      INT output:
      SEQ

        CHAN INT b:   -- only needed for the PAR (declare stuff only where needed)
        PAR
          some.proc (a?, b!)
          b ? output

        ...  do stuff with output
    :

This assumes that "some.proc" only outputs once on "b" and then terminates, else the "... do stuff with output" won't be able to run. If "some.proc" outputs repeatedly on "b" (and maybe never terminates), you would need something like:

    PROC a (CHAN INT a?)
      CHAN INT b:
      PAR

        some.proc (a?, b!)
  
        INT output:
        SEQ
          b ? output
          ...  do stuff with output
    :

On the other hand, if your "some.proc" does only output one value down the "b" channel, it's much simpler to return that value through a reference parameter – i.e. not to use a channel and the first PAR code above. Question 58 (2010) introduces the (non-examinable) concept of RESULT reference parameters, which would be ideal for this – for example:

    PROC some.proc (CHAN INT in?, RESULT INT answer)
      ...  puts some value into 'answer'
    :

    PROC a (CHAN INT a?)
      INT output:
      SEQ
        some.proc (a?, output)
        ...  do stuff with output
    :

The above code will work the same without the RESULT keyword qualifying the "INT answer" reference parameter. Having the keyword improves safety, since the compiler checks that "answer" is not used before it is given a value and that it is given a value (at least once) before "some.proc" terminates.

Keywords: channels , seq , par , result

Referrers: Question 56 (2011)

Question 58 (2010):

Submission reference: IN1954

Sorry but I have another question regarding my Question 57 (2010). I have looked through the lecture slides but can't see any reference to "result reference parameters". What exactly do you mean by this?

Answer 58:

Result parameters are those which are only used to return results from a procedure call. They can be thought of as the opposite of VAL parameters (which only pass data into procedure calls), though that's a bit vague. As a simple example:

    PROC add (VAL INT a, b, RESULT INT v)
      v := a + b
    :
  
    ...

    INT x:
    SEQ
      -- 'x' not defined here
      add (42, 15, x)
      -- 'x' is now defined and is 57

Added by PHW: I didn't present formal RESULT parameters in the lectures and they are not examinable. In my answer to Question 57 (2010), I didn't mean anything formal by the word result – my emphasis was on reference parameters. Fred's add process works the same without the RESULT keyword in the parameter declaration of v. The only difference is in the semantic checks made by the compiler. With the RESULT keyword, the compiler checks that it is not used in the body before it is assigned and that it is assigned (either by an assignment or an input). Without the RESULT keyword, the compiler assumes that it has some value when passed which may be used in the body before being changed – we assume it will be changed since, otherwise, it should have been passed as a VAL parameter.

So, when a parameter is being used only to return a result (as in add above), declaring it as a RESULT parameter increases security – as the compiler checks it is used in that way. When a parameter is used to deliver a value to a PROC and to return a result, it should be a reference parameter – i.e. no keyword. When a parameter is used only to deliver a value to the process, it should be declared as a VAL parameter.

Keywords: result

Referrers: Question 49 (2012) , Question 56 (2011) , Question 60 (2010)