Subject: SDL-News: Reply to M T Chan
From: Rick Reed TSE (rickreed#tseng.co.uk)
Date: Sun Nov 16 1997 - 18:54:50 GMT
The originator of this message is responsible for its content.
-----From Rick Reed TSE <rickreed#tseng.co.uk> to sdlnews -----
I hope that Mr. Chan receives some alternative replies, but here is my
contribution.
At 02:05 +0000 10/11/97, M T Chan wrote:
>We would like to have some help from SDL experts concerning the following :-
>
>1. We noted the reference of SDL-96, has it been standardised yet ?
>any new features compared to SDL-92 ?
I usually prefer to refer to the version of SDL that is covered by the
addendum approved in 1996 as "current SDL" rather than SDL-96. The addendum
came into force in October 1996 but was only published recently (see a
separate email).
A summary of the additions to SDL-92 in "current SDL" can be found in my
paper in the SDL '97 proceedings about the use of SDL in ITU-T. The
addendum to Z.100 also documents the changes.
>2. Is there any discussion about the pros and cons of using ACT-ONE
>and ASN.1 ? With respect to Rick Reed's recent mail re : Lutterwork
>Q.6/10 meeting results, there mentioned about the start of revision of the
>data model, what will be the direction of revision ? e.g. towards a total
>object orientation ?
The sdlnews#sdl-forum.org exploder is (in my opinion) the correct place for
this discussion. The first part of the exercise is have the discussion to
determine the direction of the revision. The associate rapporteur for this
work is Thomas Weigert <weigert#comm.mot.com>. However, from discussions to
date it seems to me that:
a) (from the user point of view) the ACT ONE model will be dropped;
b) "object orientation" will be more consistent throughout SDL;
c) there is a significent body of users that need ASN.1 support.
A good contribution to the discussion would be if Mr. Chan could explain
what he envisages "a total object orientation" would be in the context of
SDL data.
>3. Is there any way to model threads ? i.e. concurrency with total
>shared memory variables
a) processes are very good for modelling threads;
b) SDL (currently) has no concept of "memory" or "address" space;
c) the use of "shared" data in SDL is breifly outlined below.
SDL has shared variables between truely concurrent processes within a block
using VIEW and REVEAL. However, the use of this feature has been deprecated
since 1988, and it is high on the list of possible features to be REMOVED
from the language. I usually recommend that IMPORT and EXPORT, or REMOTE
procedures are used instead for obtaining (and setting) the values of
variables that do not belong to the executing process.
Also there can be variables shared between services within one process, but
such services are interleaved rather than concurrent.
Truly shared variables raise a number of synchronization issues,
particularly when then may be serviced by different, distributed processors.
>4. We wish to model concurrency within operators of datatypes and
>propose the following :-
>
>newtype a
> literals;
*********there appears to be some literals missing here******
> operators
> op1 : a,b -> c;
> operator op1 referenced;
>endnewtype a;
>operator op1; fpar x a, y b; returns v c;
> start;
> task v := call remote-proc(x,y);
************a procedure cannot be called here************
******* a name cannot contain a "-", an underline is OK ********
>endoperator op1;
>In some process specification, there exists :
>
>exported procedure remote-proc; fpar x a. y b; returns v c;
************* syntax error " x a. " should be "x a, ".
> start;
> create process1;
> create process2; /* etc. handling the operator's detail actions */
> --
> --
> return v;
>endprocedure remote-proc;
*** it is not clear why this procedure should launch two other processes.
*** I can only assume that process1 and process2 should each proceed in
*** parallel and then reply with messages (say m1 and m2) to the process
*** for remote_proc, and there is a synchronization of the results in
*** remote_proc waiting for both m1 and m2.
>The application of operator op1 will be within a process which has an
>import of remote-proc.
It is not clear why you do not replace "op1(x,y)" with "CALL remote_proc(x,y)"?
-- 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 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