Re: SDL-News: context

Subject: Re: SDL-News: context
From: Rick Reed TSE (
Date: Tue Jan 07 2003 - 13:31:43 GMT

Become an SDL Forum Society member <>
The originator of this message is responsible for its content.
-----From Rick Reed TSE <> to sdlnews ----- at wrote on 05/01/2003 15:18:

> Hello everyone
> I spend my life asking questions it seems but usually to some purpose.
> I would like to be able to understand context parameters and parameterised
> types. In particular I would like to be able to use a Pid value as a
> parameter to a block type. Unfortunately the syntax for doing seems to be
> beyond my comprehension. Is there anybody who could give an example of the
> formal definition of a parameterised and the actual type definition? Clearly
> the graphical representation would be preferable.
> I have the SDL definition documentation but I cannot interpret it correctly.
> Any help would be most welcome
> Keith Moss
> Open University Tutor UK

Dear Keith,

Actual context parameters have to refer to:

1. something that is static (such as a type definition, signal definition,
or (within a process) a variable;

2. something that is visible;

3. something that has an identifier (except in SDL-2000 for a synonym
context parameter which can be a "constant primary").

Context parameters can only be applied to types not instances.
A type with an unresolved context parameter is a parameterised type.
Such a type CANNOT be instantiated because there are unresolved items
therefore its semantics are not fully defined. For example a PROCESS TYPE
ppt with a context parameter SIGNAL cps(Integer), has to be given the name
of a defined signal that has an Integer parameter before instances of can be

Formal context parameters appears after the name of the type and before any
dynamic formal parameters. So for ppt the heading becomes
PROCESS TYPE ppt <SIGNAL cps(Integer)>

In Cinderella invoke the menu VIEW->Heading and type the context parameters
in the box used for formal parameters (next line after the name). Note that
SDT gives the message: ERROR 397 Context parameters are not supported.

SIGNAL ms1(Integer), ms2(Integer);
could be used to resolve the context parameter of the type as
ppt<ms1> or ppt<ms2>

The (anonymous) unparameterised type ppt<ms1> can be used where a process
type can be used - typically to define a set of process instances, or to
define another process type. In the fist case ppt<ms1> appears inside a
process symbol.

It is perhaps helpful to think of context parameters as a kind of macro
replacement with type checking so that you can't specify something of the
wrong kind as the actual parameter. Also the actual parameter has to be a
visible named item (except the synonym case).

A context parameter (SDL-92) has to be one of the following:

Remote Procedure
Remote variable

In SDL-2000 it is allowed to have in addition to the above:
Agent types (block type or process type but not system type)
Block (as well as process) as an agent actual parameter
Composite state type

A value can be resolved as the context parameter of a synonym context
parameter. In SDL-92 it would be necessary to have a named synonym for the
value. In SDL-2000 the value can be given as the actual parameter (there is
an implied anonymous synonym for this case). However, the value has to be a
constant - that is, it is interpreted once during the initialisation of the
system. Only the Pid value Null can be treated in this way.

Instead a variable could be used to hold the Pid value and this could be
resolved as the actual context parameter to a block type. However, such a
variable would have to be visible. This is allowed in SDL-2000 but the
variable would then be global to the block and there are implied procedure
calls to get and set the variable. In SDL-92 global variables are not
allowed, so the only option would be a remote Pid variable (also valid in
SDL-2000). In this case access is by implied remote procedure calls to the
process owning the actual variable. Note that it is allowed to have more
than one owning process for a remote variable and in this case the access
has to be directed using a Pid value!

Possibly, none of these solutions are what you actually want which is to
pass a particular Pid value to a process in a block when it is initially
created in that block. I suggest that the way to do this is to call a remote
procedure in the block that does the process creation and has the Pid value
as a parameter (or use SENDER in the remote procedure if this is the correct
Pid). The Pid value can be passed to the created process as a parameter. The
remote procedure can return the OFFSPRING Pid value of the created process.

Rick Reed -
Tel:+44 15394 88462 Mob.:+44 7970 50 96 50

--End text from Rick Reed TSE <> to sdlnews --- For extra SDL Forum Society benefits join at <>

This archive was generated by hypermail 2a23 : Thu May 09 2013 - 16:05:49 GMT