SDL-News: Fwd: Re: [SDLTF-Members] possible extension to SDL

Subject: SDL-News: Fwd: Re: [SDLTF-Members] possible extension to SDL
From: William H. Skelton (
Date: Wed Nov 26 2003 - 01:18:18 GMT

Become an SDL Forum Society member <>
The originator of this message is responsible for its content.
-----From "William H. Skelton" <> to sdlnews -----

Dear Keith & Rick,

This is subject that is personally interesting for me and it has been
discussed in a couple of task force meetings already. It is in fact
mentioned in the State Machine Block section of the draft specification in
connection with APIs as 'under review'.

Building on your comments I would like to add what has been discussed so far:

1) Signal lists do look like a data-type and Keith's comments support that
view. That way variables and parameters could be declared using a signal
list name as a type and allowed to be assigned an instance of a signal from
that signal list. There are implications also for gates, under review.

Probably this is out-of-scope regarding the subset, but may fall in scope
regarding test requirements.

2) In the draft specification we have discussed that the definition of
signals used in a signal list should be declared within the signal list,
i.e. as belonging to that signal list. Something we tighten up in the subset.

Unfortunately it seems the syntax doesn't allow this. There was a glimmer
of hope that the new INTERFACE syntax of SDL-200 would allow signals to be
declared within the INTERFACE, but on checking the SDL-2000 specification
it seems it also doesn't allow it either.

Are you, or anybody else, able to clarify this point for us?


>User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022
>Date: Tue, 25 Nov 2003 22:58:07 +0000
>Subject: Re: [SDLTF-Members] possible extension to SDL
>From: Rick Reed TSE <>
>To: <>
>CC: SDLnews <>
> at wrote on 25/11/2003 15:58:
> > Dear All
> >
> > I have encountered what I might regard as an inconsistency in the
> > specification of SDL. It is only a simple one though. Signal lists are
> used to
> > group signals at interfaces and the reason their use seems to me to me
> to be
> > to produce a less cluttered diagram than might otherwise result if all the
> > signals are shown individually on a diagram. A laudable aim. However when
> > signals are used as parameters of a block or process they have to be shown
> > individually. Could not a new parameter type be allowed that of signal
> lists?
> >
> > Keith Moss
>Dear Keith, Dear All,
>In the context of the objectives of the task force "to find the simplest
>useful SDL subset", I think that such a proposal is clearly out of scope:
> It assumes the use of agent (context) parameters,
> which I doubt would be in such a subset.
>However, it could be considered as a language proposal outside the scope of
>this work.
>Signal lists are quite useful for the reasons you note, but also have
>limitations. It overcome such limitations that interfaces were introduced in
>SDL-2000. In typical simple systems an interface and a signal list are very
>similar and would both collect together a set of signals to be used on
>channels, gates and input lists.
>So why was a new concept introduced rather than extend the semantics of
>signal lists?
>Part of the answer is in the underlying semantics of signal lists. In effect
>these are just a macro concept. When a signal list is used it is
>semantically replaced by the list of identifiers defined by the list. The
>only real difference between this and a plain text macro is the language
>restricts what can be in a signal list and where a signal list can be used.
>An interface identifier can be used where a signal list is used, but is type
>definition rather than a macro mechanism. An interface can be used to group
>signal definitions together, whereas for a signal list the signals have to
>be defined and then grouped. If an interface is visible, all the signals
>defined by it are visible, which is not always true for a signal list.
>Interfaces can inherit from other interfaces. Finally interfaces can be used
>as context parameters, giving exactly the feature requested.
>Interfaces provide everything that the language needs, so why do we have
>both signal lists and interfaces?
>The answer is "legacy". To minimise the amount work needed to change SDL-92
>to SDL-2000 it was decided to keep signal lists.
>The way forward would be to redefine the semantics of "signal list" so that
>it is equivalent to an interface definition with no locally defined signals
>(that is one that uses visibly defined items).
>For example,
>SIGNALLIST Siglist = Sig1, Sig2, Sig3;
>should be equivalent to
>INTERFACE anon_Siglist { USE Sig1, Sig2, Sig3; }
>and the use of a signal list identifier in brackets should be equivalent to
>referring to this (anonymous) interface name, so that
>( Siglist )
>should be equivalent to
>INTERFACE anon_Siglist
>and (Siglist) should be allowed wherever an interface identifier is allowed.
>The consequence would be that an agent could have an INTERFACE context
>parameter and be given (Siglist) as an actual context parameter. This is
>what Keith wants.
>Although all this sounds complex, I think it might actually simplify the
>language, as there would be no real distinction (other than syntax) between
>signal lists and interfaces with no local definitions.
>Rick Reed -
>Tel:+44 15394 88462 Mob.:+44 7970 50 96 50

William H. Skelton, Engineering Dept.
SOLINET GmbH Solutions for Innovative Networks
Mittlerer Pfad 26, 70499 Stuttgart, Germany
Tel +49 711 1398 1377, Fax +49 711 866 1240
Mobile +49 171 247 6688,

--End text from "William H. Skelton" <> to sdlnews ---
For extra SDL Forum Society benefits join at <>

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