Re: SDL-News: A simple problem (?) : the FORWARDER.


Subject: Re: SDL-News: A simple problem (?) : the FORWARDER.
From: Rick Reed TSE (rickreed#tseng.co.uk)
Date: Tue Apr 28 1998 - 19:31:53 GMT


The originator of this message is responsible for its content.
-----From Rick Reed TSE <rickreed#tseng.co.uk> to sdlnews -----

At 15:40 +0100 27/04/98, Elie Cohen wrote:
>Such a construct does not exist and it is sad indeed.
>
>I would love to see a new symbol "Forward" that would merely "Output" the
>"last consumed message", possibly using the TO and VIA construct the same
>way the "output" construct does.
>
>Furthermore, it would be useful to have the option to leave the "sender"
>information alone, so the receiver would perceive the "sender" to be the
>"original sender".

In the Q.6/10 SDL expert's group we are aware that passing on a message
received is not as smooth (or efficient) as it could be.

However, the "solution" is not as simple as it may first appear. Elie has
already indicated one potential issue: which process instance should be
considered the SENDER of the SIGNAL. Furthermore there is interaction with
procedure calls (which may consume signals), spontaneuos transitions,
continuous signals, remote procedures, import/export.

I am also getting the requests from both users and toolmakers: "No New
Symbols", so I would prefer a proposal that used existing symbols - for
example using the keyword SIGNAL to refer to the last signal (cf. STATE
expression in current SDL) to be used in an output.

This IS an "open item", so I would welcome a FULL proposal of how this may
be acheived in Z.100. By a FULL proposal, I mean that the grammar and
semantics have been worked out for both SDL/GR and SDL/PR. To be accepted
the proposal needs "substantial user support" and should be demonstrated as
feasible by a tool implementation. These criteria are to prevent ad hoc
changes to the language and also to try to move to a situation (sadly not
yet acheived) where tools support the complete language.

With respect to "full tool support", I have requested inputs (in particular
from tool suppliers) on which features are required in SDL and can be
removed. Obviously features not currently supported by tools are
candidates.

The reason for removing some features is because it is becoming difficult
to support SDL both from a tool point of view and maintaining the language
standard - becuase of the size of the language. If new features are to be
added, it is preferable if some little used or unused ones are deleted.

--
Rick Reed, TSE Limited
13 Weston House, 18-22 Church Street
Lutterworth Leicestershire LE17 4AW United Kingdom
Tel +44 14 55 55 96 55; Fax +44 14 55 55 96 58
Mob +44 79 70 50 96 50
email: rickreed#tseng.co.uk
http://www.tseng.co.uk   ftp://ftp.tseng.co.uk/tseng/

-----End text from Rick Reed TSE <rickreed#tseng.co.uk> to sdlnews ----- For help, email "majordomo#sdl-forum.org" with the body of your email as: help or (iff this does not answer your question) email: owner-sdlnews#sdl-forum.org



This archive was generated by hypermail 2a23 : Sun Jun 16 2013 - 10:41:40 GMT