Subject: SDL-News: Re: [SDLTF-Members] possible extension to SDL
From: Rick Reed TSE (rickreed#tseng.co.uk)
Date: Tue Nov 25 2003 - 22:58:07 GMT
Become an SDL Forum Society member <http://www.sdl-forum.org/Society/members.htm>
The originator of this message is responsible for its content.
-----From Rick Reed TSE <rickreed#tseng.co.uk> to sdlnews -----
KEMoss6#aol.com at KEMoss6#aol.com 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 - rickreed#tseng.co.uk Tel:+44 15394 88462 Mob.:+44 7970 50 96 50--End text from Rick Reed TSE <rickreed#tseng.co.uk> to sdlnews --- For extra SDL Forum Society benefits join at <http://www.sdl-forum.org/Society/members.htm>
This archive was generated by hypermail 2a23 : Thu May 09 2013 - 16:05:50 GMT