Subject: Re: SDL-News: A simple problem (?) : the FORWARDER.
From: Oystein Haugen (etooha#eto.ericsson.se)
Date: Wed Apr 29 1998 - 09:20:50 GMT
The originator of this message is responsible for its content.
-----From Oystein Haugen <etooha#eto.ericsson.se> to sdlnews -----
Dear SDL friends
Concerning the ongoing discussion about the FORWARDER, I would like to
draw your attention to my contribution to the Lutterworth experts
meeting in 1997. The suggestions are not as detailed as requested by the
SDL Rapporteur, but it was meant not only as an input to the discussion
on signals, but also equally much as an input to the discussion on a new
data concept. My understanding of the discussion at Lutterworth was that
the ideas should be used as input for the ongoing discussion on the new
data concept.
I have earlier sent these ideas on the sdlnews mailing list, but it
seems that a repetition can do no harm. As can easily be seen, the
FORWARDER can be implemented by these more general concepts. (Still also
this proposal is not complete in all respects and not all problems are
solved)
Signal objects as variables
As any SDL implementation has discovered, there is definitely some gain
in harmonizing signals and variables. We suggest the following scheme:
1. Signal data type. We define a new predefined data type which is the
set of all signals. It is designated SIGNAL, such that a declaration of
a signal variable will look like: “dcl my_sig SIGNAL;”. The signal data
type may then also appear as parameter to another signal. It is also
possible to define variables of specific signal types by extending the
syntax: “dcl my_sig SIGNAL mysignaltype;”
2. Output. It is possible to output a stored signal by outputting the
variable: “output my_sig;” The SENDER attribute of the signal is
modified to SELF of this process.
3. Dash signal. We define a predefined function (called DASHSIGNAL)
which returns a SIGNAL value which is equal to the most recently
consumed signal of the process.
4. Check signal type. We define a Boolean function which can be used to
check the signal type of a signal variable: “my_sig is return;”. A
similar construct can then be used to interpret parameters: “my_sig qua
exceptreturn(param);”.
5. Atleast input. We may consume signals of different signal types in
one transition by specifying a supertype of the signal types by “input
atleast return;”. Combination with DASHSIGNAL and signal type check
makes it possible to use this effectively. In general we can use
“atleast signaltype” also in signallists to indicate that any signal
type which is inherited from signal type is allowed.
All together these features make it possible to generalize SDL
communication more wrt. signals.
Rick Reed TSE wrote:
> 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
-- ------------------------ Oystein Haugen, Ericsson as. , P.O. box 34, N-1361 Billingstad, Norway Tel: +47 66 84 23 46 Fax: +47 66 84 19 15 E-mail: etooha#eto.ericsson.se-----End text from Oystein Haugen <etooha#eto.ericsson.se> 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