Subject: SDL-News: RE:News:Contribution : Textual agorithms
From: Rick Reed TSE (rickreed#tseng.co.uk)
Date: Sat Oct 11 1997 - 16:32:13 GMT
The originator of this message is responsible for its content.
-----From Rick Reed TSE <rickreed#tseng.co.uk> to sdlnews -----
Thnak you for your contribution - it will be taken into account with the
original document at the Lutterworth meeting.
With respect to:
>You talk about algorithms but I remind you what N.Wirth said:
> "Algorithms + Data Structure = Programs"
>
>And what can we tell about data structures in SDL ?
>
>Let's try to declare a variable
> xyz as an array of 12 integer
>
>using SDL:
>+-----------------------------|\
>|syntype from1to12 = integer |_\
>| constants 1:12 |
>|endsyntype |
>| |
>|newtype array12int |
>| ARRAY(from1to12,INTEGER) |
>|endnewtype |
>| |
>|dcl |
>| xyz array12int; |
>+--------------------------------+
> Frustrating !
>9 lines ( and a lot of keywords ) against 1 line of "English
>specification"
>I really think that SDL is the worst language for data declarations.
>
>So, despite some good unique features of SDL, namely
> FSM concept
> the routing of messages at architectural level
>I think that SDL will be always a penalized language, as long as
>algorithms and data-structures cannot be expressed more concisely.
This issue is partially addressed by Z.105 where sort of data can be
defined in context and using the ASN.1 syntax. The non-ASN.1 parts are to
be integrated into the main part of Z.100.
A detailed study and revision of the data part of SDL is just being
commenced and along with some lexical changes releasing square brackets and
braces (curly brackets) from the status of "national characters", SDL
should be more readable and writeable - "more readable" should (of course)
take precedence.
> ---------------------
>Last point: Variables or memory ?
> ---------------------
>It's time to make a net separation among what we declare (dcl) as
>variables inside an SDL-process:
>
>We need variables for the whole lifetime of a process
> --> see "msg", "agent" at page 21
> and we declare them 'globally' using "dcl"
>
>we need variables just for temporary computations
> --> see "tmp1", "tmp2" at page 10
> and we WILL declare them inside a <statement list>
>
>we need variables just for a transition lifetime
> --> see "i" at page 21
> but this is missing !!
> What I'm trying to highlight is that the variable "i" in the example at
>page 21, is not part of the "permanent memory" of the process; it's only
>a temporary variable required for a transition (and only a specific
>transition,; the one starting from state "wait_for_reset" with signal
>"in"), after the transition ends, it's not necessary to keep-memory of
>"i"
>
>Personally, when I write SDL processes I always adopt a special notation
>in order to distinguish the variables denoting "the memory of the
>process" from the auxiliary and temporary variables.
>
> +--------------------------------|\
> | DCL /*** memory of FSM ***/ |_\
> | varA bigBuffType; |
> | DCL /*** auxiliary ***/ |
> | varB bigBuffType; |
> +-----------------------------------+
>My notation is nothing more than a poor comment, but it's a FORMAL
>notation, although non FORMALIZED !
>
>This is a good notation for me, but not for a code-generator; a
>code-generator will always reserve "permanent memory"
>(permanent=process-lifetime) for "varB" too, but this is not what I
>want; I want space for "varB" only when a transition using it is
>running.
>
>Don't you think it could be useful to introduce a new construct for
>declaring auxiliary variables ? I think we can have better
>specifications, and also better code-generation.
I understand the main requirement as a need to define variable with a scope
and lifetime of a "transition" - meaning that the scope and life of the
variable is bounded by the state and the next state. In a textual language
is usually achieved by inserting extra begin-end brackets, but I expect
that many SDL users will want to retain the graphical form (particularly
where there are outputs to be shown) AND have variables with limited scope
and lifetime. This should therefore be added to the list of open items
(which I assume you have found is part of the Master List for Z.100 I
distributed).
-- 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:39 GMT