TOPIC:

In the standard, there seem to exist 3 different rules of when declarations
have to be made:

1) On top scope, there is no requirements where declarations are placed.
2) In all other scopes, it is declare-before-use.
3) Inside a statement block, declarations have to come first.

1 and 2 make sense, 3 does not, in my opinion. If it is legal in a function
to declare variables when they are needed, why should this not be allowed
inside a statement block, e.g., the then-clause of an if-then-else
statement?

It is legale to write:

function f() returns integer {
some_code;
integer i :=0 ;
some_more_code;
}

so it should be legal to write

if condition then {
some_code;
integer i := 0;
some_more_code;
}

So, I propose to eliminate the clauses in the standard that state that
declarations shall come first in a statement block.

Best regards

Olle

---

---

Telelogic Tau 4.2 speeds up your wireless development!
Read more about it at www.telelogic.com/tau42

---

---

Olle Palmgren
Director of Engineering, PD Test
Telelogic, St Persgatan 13, SE-753 20, Uppsala, Sweden
Phone: +46 18 66 18 59
Fax: +46 18 66 18 70
This email address is being protected from spambots. You need JavaScript enabled to view it.
www.telelogic.com

---

---

Telelogic - Putting you ahead in software development!

---

---

Dear Olle,

you forgot the effect of the GOTO statement ...

if condition then {
some_code;
goto Mylabel;
integer i := 0;
some_more_code;
label Mylabel;
i := i + 20
}

might not be that nice.

Regards
Jens Grabowski

>

---

Original Message

---

> From: Olle PALMGREN [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Sent: 23 October 2001 15:07
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Placement of Declarations
>
>
> In the standard, there seem to exist 3 different rules of
> when declarations
> have to be made:
>
> 1) On top scope, there is no requirements where declarations
> are placed.
> 2) In all other scopes, it is declare-before-use.
> 3) Inside a statement block, declarations have to come first.
>
> 1 and 2 make sense, 3 does not, in my opinion. If it is legal
> in a function
> to declare variables when they are needed, why should this
> not be allowed
> inside a statement block, e.g., the then-clause of an if-then-else
> statement?
>
> It is legale to write:
>
> function f() returns integer {
> some_code;
> integer i :=0 ;
> some_more_code;
> }
>
> so it should be legal to write
>
> if condition then {
> some_code;
> integer i := 0;
> some_more_code;
> }
>
> So, I propose to eliminate the clauses in the standard that state that
> declarations shall come first in a statement block.
>
> Best regards
>
> Olle
>
>

---

>

---

>

---

> Telelogic Tau 4.2 speeds up your wireless development!
> Read more about it at www.telelogic.com/tau42
>

---

>

---

>

---

> Olle Palmgren
> Director of Engineering, PD Test
> Telelogic, St Persgatan 13, SE-753 20, Uppsala, Sweden
> Phone: +46 18 66 18 59
> Fax: +46 18 66 18 70
> This email address is being protected from spambots. You need JavaScript enabled to view it.
> www.telelogic.com
>

---

>

---

>

---

> Telelogic - Putting you ahead in software development!
>

---

>

---

>

---

>

a goto might not be that nice

--

Dr. Oliver Block
********************************************
Siemens AG
ICM N IS P DEV 1
Siemensdamm 50
D-13629 Berlin

Fon: +49 30 386 35596
Fax: +49 30 386 22860

Geb.202 Raum E428
52.54 N 013.27 E
*******************************************

---

Ursprüngliche Nachricht

---

Von: Jens Grabowski [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Gesendet: Dienstag, 23. Oktober 2001 15:42
An: This email address is being protected from spambots. You need JavaScript enabled to view it.
Betreff: Re: Placement of Declarations


Dear Olle,

you forgot the effect of the GOTO statement ...

if condition then {
some_code;
goto Mylabel;
integer i := 0;
some_more_code;
label Mylabel;
i := i + 20
}

might not be that nice.

Regards
Jens Grabowski

>

---

Original Message

---

> From: Olle PALMGREN [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Sent: 23 October 2001 15:07
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Placement of Declarations
>
>
> In the standard, there seem to exist 3 different rules of
> when declarations
> have to be made:
>
> 1) On top scope, there is no requirements where declarations
> are placed.
> 2) In all other scopes, it is declare-before-use.
> 3) Inside a statement block, declarations have to come first.
>
> 1 and 2 make sense, 3 does not, in my opinion. If it is legal
> in a function
> to declare variables when they are needed, why should this
> not be allowed
> inside a statement block, e.g., the then-clause of an if-then-else
> statement?
>
> It is legale to write:
>
> function f() returns integer {
> some_code;
> integer i :=0 ;
> some_more_code;
> }
>
> so it should be legal to write
>
> if condition then {
> some_code;
> integer i := 0;
> some_more_code;
> }
>
> So, I propose to eliminate the clauses in the standard that state that
> declarations shall come first in a statement block.
>
> Best regards
>
> Olle
>
>

---

>

---

>

---

> Telelogic Tau 4.2 speeds up your wireless development!
> Read more about it at www.telelogic.com/tau42
>

---

>

---

>

---

> Olle Palmgren
> Director of Engineering, PD Test
> Telelogic, St Persgatan 13, SE-753 20, Uppsala, Sweden
> Phone: +46 18 66 18 59
> Fax: +46 18 66 18 70
> This email address is being protected from spambots. You need JavaScript enabled to view it.
> www.telelogic.com
>

---

>

---

>

---

> Telelogic - Putting you ahead in software development!
>

---

>

---

>

---

>

Wow !
It is a very bad programming example.
I would rather not to publish it :-)

But ...
Why are you still keeping this old programming solution: GOTO ?
It always leads to problems.
Maybe GOTO is simple and powerful but it is aften confusing.
It is time for object-oriented programming solution also for TTCN.
GOTO is against the philosophy of OOP.

I would propose to develop TTCN-3 by extending JAVA capabilities.
It would be more practically and functionally to modify Java a little bit
to get the same results like new TTCN plus capabilities of Java. as a base
for
extension.
Is it possible to do some rework and modify Java for TTCN ?
I think things should go towards the future, not only doing mixture of
TTCN-2, Pascal, C++, Java and Basic, there is neded some adoption
for the next years.
Sometimes if you want to make happy all, nobody will be satisfied.

Regards,
Mariusz Kupiec

---

Original Message

---

From: "Jens Grabowski" <This email address is being protected from spambots. You need JavaScript enabled to view it.>
To: <This email address is being protected from spambots. You need JavaScript enabled to view it.>
Sent: Tuesday, October 23, 2001 3:42 PM
Subject: Re: Placement of Declarations


> Dear Olle,
>
> you forgot the effect of the GOTO statement ...
>
> if condition then {
> some_code;
> goto Mylabel;
> integer i := 0;
> some_more_code;
> label Mylabel;
> i := i + 20
> }
>
> might not be that nice.
>
> Regards
> Jens Grabowski
>
> >

---

Original Message

---

> > From: Olle PALMGREN [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> > Sent: 23 October 2001 15:07
> > To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > Subject: Placement of Declarations
> >
> >
> > In the standard, there seem to exist 3 different rules of
> > when declarations
> > have to be made:
> >
> > 1) On top scope, there is no requirements where declarations
> > are placed.
> > 2) In all other scopes, it is declare-before-use.
> > 3) Inside a statement block, declarations have to come first.
> >
> > 1 and 2 make sense, 3 does not, in my opinion. If it is legal
> > in a function
> > to declare variables when they are needed, why should this
> > not be allowed
> > inside a statement block, e.g., the then-clause of an if-then-else
> > statement?
> >
> > It is legale to write:
> >
> > function f() returns integer {
> > some_code;
> > integer i :=0 ;
> > some_more_code;
> > }
> >
> > so it should be legal to write
> >
> > if condition then {
> > some_code;
> > integer i := 0;
> > some_more_code;
> > }
> >
> > So, I propose to eliminate the clauses in the standard that state that
> > declarations shall come first in a statement block.
> >
> > Best regards
> >
> > Olle
> >
> >

---

> >

---

> >

---

> > Telelogic Tau 4.2 speeds up your wireless development!
> > Read more about it at www.telelogic.com/tau42
> >

---

> >

---

> >

---

> > Olle Palmgren
> > Director of Engineering, PD Test
> > Telelogic, St Persgatan 13, SE-753 20, Uppsala, Sweden
> > Phone: +46 18 66 18 59
> > Fax: +46 18 66 18 70
> > This email address is being protected from spambots. You need JavaScript enabled to view it.
> > www.telelogic.com
> >

---

> >

---

> >

---

> > Telelogic - Putting you ahead in software development!
> >

---

> >

---

> >

---

> >
>

---

Czat w rytm pisku opon... czateria.interia.pl/gosc?cid=622
Janusz Kulig na CZATerii > ¦roda, 24 pa?dziernika od 12:00

On Tue, 23 Oct 2001, Mariusz Kupiec wrote:

> Wow !
> It is a very bad programming example.
> I would rather not to publish it :-)
>
> But ...
> Why are you still keeping this old programming solution: GOTO ?
> It always leads to problems.
> Maybe GOTO is simple and powerful but it is aften confusing.
> It is time for object-oriented programming solution also for TTCN.
> GOTO is against the philosophy of OOP.

I have to agree with that, although this has not much to do with
OOP programming style but with the higher level of abstraction
which goes beyond the control-flow being implemented in a
_specification_. (One could point to the 1968 article by Dijkstra
'Goto statement considered harmful')

Just to open another Pandora's Box. What happens, if I assign
the field of a record which has the value 'omit' (which, if you
look closely, is not really a template like the standard
proposes, but a _value_, because you can also initialize
optional fields of constants and variables - i.e. non-templates -
with it) to a variable? Should that lead to a runtime-error as it
is - in essence - the use of an uninitialized field? If not, does
every variable declaration carry an implicit 'optional'?

In extension, if any variable (even though it is impossible to
declare that it shall be optional) can have three modes of existence:
uninitialized, initialized and omitted, I propose that uninitialized
and omitted should be treated the same way (as they seem to have
the same meaning).

The next question arises (and which I already posed some very
long time ago, but it is still unanswered) when thinking about
the field selection expression when applied to 'omit'.
Either, this should lead to a runtime-error (as it cannot be
statically checked) or it should simply also result in the
value 'omit' (making it easy for all involved parties).
I would favour the latter for the sake of simplicity.

Regarding the declaration of variables vs. the goto statement,
the argument _could_ be that a _declaration_ of a variable
just makes it known in the context (to the compiler/reader of
the specification), no matter _where_ it appears in the context
(although I admit that this could produce confusing code) -
so, if the declaration _statement_ is placed _textually_ before
any use of the variable, the confusion should be limited
(and this can also very easily statically checked).

Independent of that, an _initialization_ should always _happen_
(at runtime) before the first use (i.e. reading) of a variable.

So, if you have code like:

{
<do a lot without i>
goto l1;
var integer i := 2;
<do the first thing with i>
label l1;
i := 1;
<do other things with i>
}

This does not pose any problem for me.
The combined declaration/initialization statement is only a
shortcut for two statements (a declarative one and an operational
one). The goto statement should only influence the order in
which the operational statements are exectuted (at runtime).

Declarative statements are not executed and thus it should not
matter where they are put (in a given context). If readability
is enhanced by enforcing an 'declare before use' rule, this
is fine by me, but it should not lead to the confusion of the
different meanings of the language constructs.

Greetings, Jacob Wieland, TU-Berlin

PS: If the Goto statement is not to be abolished again,
at least the operational semantics should be changed
so that the local variables of the scopes that are
left by the jump are removed from the stack.

I know implementation details shouldn't influence a language design, but
maybe this one is an exception. I have always thought it easier to regard
all TTCN values as having associated values, even though the user might be
unaware of, and could think of no use for such things. For example, normally
we think of an integer as just an integer, in other cases we have to think
of an integer as being something more complex because it has attached
matching information and/or type constraint information. Where a value could
be either representation (a parameter for example) that gives potentially
different depending on the nature of the actual parameter. Any potential
problems (imagined or real, (imagined means there may be no problems, I just
worry about things)) are solved by presuming everything carries associated
extra information. So, in this case, an implementation detail could be used
to indicate that the language design should state that everything has such
associated data.

Setting a variable from a field set to omit doesn't worry me. If the value
is later used to set a constraint, then that constraint is set to omit, no
problem. If the user tries to actually use the value (for other than
assignment), well how does that differ from erroneously using any "contains
rubbish" varaiable in any language? It's his problem not ours.

As for goto, do we really still need to be discussing this after all these
decades? TTCN2 had problems which meant the occasional goto could be useful.
I thought these problems were cured in TTCN3. So why can't we just get rid
of it and avoid these sort of semantic problems. Although I'm not using it
at the moment, I have written countless real time and non-real time
Modula-2 programs. That language has no goto. Was this ever a problem in any
of those programs? No. I've written even more in C/C++ and Ada. Have I ever
used the available goto? No. So if we have done a good job on TTCN3 (we
have, haven't we?) goto should be redundant.

Regards

Derek

---

Derek C Lazenby
Anite
127 Fleet Road
Fleet
Hampshire
GU51 3QN
Tel : +44 1252 775200
Fax: +44 1252 775299

---

Anite Telecoms Limited Registered in England No. 1721900 Registered
Office: 100 Longwater Avenue, GreenPark, Reading, Berkshire RG2 6GP,
United Kingdom

---

Original Message

---

From: Jacob 'Ugh' Wieland [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: 24 October 2001 08:17
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Placement of Declarations


On Tue, 23 Oct 2001, Mariusz Kupiec wrote:

> Wow !
> It is a very bad programming example.
> I would rather not to publish it :-)
>
> But ...
> Why are you still keeping this old programming solution: GOTO ?
> It always leads to problems.
> Maybe GOTO is simple and powerful but it is aften confusing.
> It is time for object-oriented programming solution also for TTCN.
> GOTO is against the philosophy of OOP.

I have to agree with that, although this has not much to do with
OOP programming style but with the higher level of abstraction
which goes beyond the control-flow being implemented in a
_specification_. (One could point to the 1968 article by Dijkstra
'Goto statement considered harmful')

Just to open another Pandora's Box. What happens, if I assign
the field of a record which has the value 'omit' (which, if you
look closely, is not really a template like the standard
proposes, but a _value_, because you can also initialize
optional fields of constants and variables - i.e. non-templates -
with it) to a variable? Should that lead to a runtime-error as it
is - in essence - the use of an uninitialized field? If not, does
every variable declaration carry an implicit 'optional'?

In extension, if any variable (even though it is impossible to
declare that it shall be optional) can have three modes of existence:
uninitialized, initialized and omitted, I propose that uninitialized
and omitted should be treated the same way (as they seem to have
the same meaning).

The next question arises (and which I already posed some very
long time ago, but it is still unanswered) when thinking about
the field selection expression when applied to 'omit'.
Either, this should lead to a runtime-error (as it cannot be
statically checked) or it should simply also result in the
value 'omit' (making it easy for all involved parties).
I would favour the latter for the sake of simplicity.

Regarding the declaration of variables vs. the goto statement,
the argument _could_ be that a _declaration_ of a variable
just makes it known in the context (to the compiler/reader of
the specification), no matter _where_ it appears in the context
(although I admit that this could produce confusing code) -
so, if the declaration _statement_ is placed _textually_ before
any use of the variable, the confusion should be limited
(and this can also very easily statically checked).

Independent of that, an _initialization_ should always _happen_
(at runtime) before the first use (i.e. reading) of a variable.

So, if you have code like:

{
<do a lot without i>
goto l1;
var integer i := 2;
<do the first thing with i>
label l1;
i := 1;
<do other things with i>
}

This does not pose any problem for me.
The combined declaration/initialization statement is only a
shortcut for two statements (a declarative one and an operational
one). The goto statement should only influence the order in
which the operational statements are exectuted (at runtime).

Declarative statements are not executed and thus it should not
matter where they are put (in a given context). If readability
is enhanced by enforcing an 'declare before use' rule, this
is fine by me, but it should not lead to the confusion of the
different meanings of the language constructs.

Greetings, Jacob Wieland, TU-Berlin

PS: If the Goto statement is not to be abolished again,
at least the operational semantics should be changed
so that the local variables of the scopes that are
left by the jump are removed from the stack.

On Wed, 24 Oct 2001, Lazenby, Derek wrote:

> Setting a variable from a field set to omit doesn't worry me. If the value
> is later used to set a constraint, then that constraint is set to omit, no
> problem. If the user tries to actually use the value (for other than
> assignment), well how does that differ from erroneously using any "contains
> rubbish" varaiable in any language? It's his problem not ours.

Actually, as someone writing a compiler for TTCN-3 i _need_ to know what
_all_ possible syntax-correct specifications should _mean_ as to make it
possible to implement them. If the semantics of some syntactic contstruct
are partly unspecified in the language, it should at least be known so
that a compiler can either warn the user of the language (if the situation
is detectable at compile time) or produce a proper runtime-error (if the
situation is only detectable at runtime).
Just saying 'I don't care what happens if I assign an omit to a
non-optional field' is like saying 'I don't care about assertions
associated with types' or, to be more blunt, 'I don't care about types'.

But, types give _meaning_ to the different expressions and constructs
and thus allow the compiler to find errors and optimize code or - at
the least - to actually implement the meaning of the constructs.

> As for goto, do we really still need to be discussing this after all these
> decades? TTCN2 had problems which meant the occasional goto could be useful.
> I thought these problems were cured in TTCN3. So why can't we just get rid
> of it and avoid these sort of semantic problems. Although I'm not using it
> at the moment, I have written countless real time and non-real time
> Modula-2 programs. That language has no goto. Was this ever a problem in any
> of those programs? No. I've written even more in C/C++ and Ada. Have I ever
> used the available goto? No. So if we have done a good job on TTCN3 (we
> have, haven't we?) goto should be redundant.

I have to agree with you on that point.
Actually, goto is redundant in that it is not needed if you have
while-loops. But that is just the theory and can lead to
impracticalities (if you have no construct which lets you leave a
while-loop prematurely).
Unfortunately, TTCN-3 fails to sport such well-known and old constructs
like 'break' and 'continue' which would normally facilitate such things
(and would make mapping TTCN-3 to any 'normal' High-Level programming
language instead of Assembly-Code far easier than it is at the moment).

Greetings, Jacob Wieland, TU-Berlin

Er, well actually you may want to set non optional fields to omit sometimes.
It's one way you test how a SUT reponds to invalid data. (Yes, I know there
are other ways of doing it.)

Now, Jacob, the only way I could respond to the spectacular, but erroneous
sequence of "if you believe this then..." is over several beers in bar
somewhere :-) For a start I believe TTCN3 should be more strongly typed,
which doesn't fit with your reasoning at all well, so set the beers up, this
could be fun......

Regards

Derek

---

Derek C Lazenby
Anite
127 Fleet Road
Fleet
Hampshire
GU51 3QN
Tel : +44 1252 775200
Fax: +44 1252 775299

---

Anite Telecoms Limited Registered in England No. 1721900 Registered
Office: 100 Longwater Avenue, GreenPark, Reading, Berkshire RG2 6GP,
United Kingdom

---

Original Message

---

From: Jacob 'Ugh' Wieland [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: 24 October 2001 14:39
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Placement of Declarations


On Wed, 24 Oct 2001, Lazenby, Derek wrote:

> Setting a variable from a field set to omit doesn't worry me. If the value
> is later used to set a constraint, then that constraint is set to omit, no
> problem. If the user tries to actually use the value (for other than
> assignment), well how does that differ from erroneously using any
"contains
> rubbish" varaiable in any language? It's his problem not ours.

Actually, as someone writing a compiler for TTCN-3 i _need_ to know what
_all_ possible syntax-correct specifications should _mean_ as to make it
possible to implement them. If the semantics of some syntactic contstruct
are partly unspecified in the language, it should at least be known so
that a compiler can either warn the user of the language (if the situation
is detectable at compile time) or produce a proper runtime-error (if the
situation is only detectable at runtime).
Just saying 'I don't care what happens if I assign an omit to a
non-optional field' is like saying 'I don't care about assertions
associated with types' or, to be more blunt, 'I don't care about types'.

But, types give _meaning_ to the different expressions and constructs
and thus allow the compiler to find errors and optimize code or - at
the least - to actually implement the meaning of the constructs.

> As for goto, do we really still need to be discussing this after all these
> decades? TTCN2 had problems which meant the occasional goto could be
useful.
> I thought these problems were cured in TTCN3. So why can't we just get rid
> of it and avoid these sort of semantic problems. Although I'm not using it
> at the moment, I have written countless real time and non-real time
> Modula-2 programs. That language has no goto. Was this ever a problem in
any
> of those programs? No. I've written even more in C/C++ and Ada. Have I
ever
> used the available goto? No. So if we have done a good job on TTCN3 (we
> have, haven't we?) goto should be redundant.

I have to agree with you on that point.
Actually, goto is redundant in that it is not needed if you have
while-loops. But that is just the theory and can lead to
impracticalities (if you have no construct which lets you leave a
while-loop prematurely).
Unfortunately, TTCN-3 fails to sport such well-known and old constructs
like 'break' and 'continue' which would normally facilitate such things
(and would make mapping TTCN-3 to any 'normal' High-Level programming
language instead of Assembly-Code far easier than it is at the moment).

Greetings, Jacob Wieland, TU-Berlin