TOPIC:

What should be allowed in the for-statment initialiser?

Currently, it is a bit broad, allowing a VarInstance as well as an
Assignment.

A VarInstance covers these possibilities:
1. var integer foo
2. var integer foo, bar
3. var integer foo := 1
4. var integer foo, bar := 1
5. var integer foo := 1, bar := 1
6. any of the above combinations with an ArrayDef after an identifer.

Number 3 should definitely be legal. 1,2 should be illegal.
Number 6 should probably be illegal.
Numbers 4,5 I'm not sure: possibly legal (as long as there's an
assignment somewhere)

I'll put in a change request later next week tightening up this area, so
if you don't agree with me, now's your chance to say so.

Cheers,
--

---

Carl Cerecke - Software Designer
Da Vinci Communications Ltd
Christchurch - New Zealand

---

TEL : +64 3 3838311
FAX : +64 3 3838310
e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
www : www.davinci-communications.com

---

On Fri, 22 Nov 2002, Carl Cerecke wrote:

> What should be allowed in the for-statment initialiser?
>
> Currently, it is a bit broad, allowing a VarInstance as well as an
> Assignment.
>
> A VarInstance covers these possibilities:
> 1. var integer foo
> 2. var integer foo, bar
> 3. var integer foo := 1
> 4. var integer foo, bar := 1
> 5. var integer foo := 1, bar := 1
> 6. any of the above combinations with an ArrayDef after an identifer.
>
> Number 3 should definitely be legal. 1,2 should be illegal.
> Number 6 should probably be illegal.
> Numbers 4,5 I'm not sure: possibly legal (as long as there's an
> assignment somewhere)

I would put only this restriction there:

All variables declared in the for-statement initializer have
to be fully initialized.

Why do you want to forbid this:

for (var integer a[] := { 0, 1, 2 }, i := 0; ... a ...; ...)

?

> I'll put in a change request later next week tightening up this area, so
> if you don't agree with me, now's your chance to say so.

Done :-)

Cheers,

Jacob Wieland, TTthree-Team, TU-Berlin

Hi,

Currently only (3) is legal, see subclause 19.7 of the standard:

"The index variable of a for loop can be declared before being used in the for statement or can be declared and initialized in the for statement header. If the index variable is declared and initialized in the for statement header, the scope of the index variable is limited to the loop body, i.e. it is only visible inside the loop body."

(the singular above excludes 5, all other alternatives are illegal because do not initialize the variable). I propose not to put a CR.

Best Regards, György

> dr György RÉTHY
> Manager
> Test Services, Test House, Ericsson Hungary
> Address: H-1037 Budapest, Laborc street 1.
> Phone: + 36 (1) 437-7006
> Mobile: + 36 (30) 297-7862
> Fax: + 36 (1) 437-7767
> Mail-to: This email address is being protected from spambots. You need JavaScript enabled to view it.


>

---

Original Message

---

>From: Carl Cerecke [This email address is being protected from spambots. You need JavaScript enabled to view it.]
>Sent: Friday, November 22, 2002 3:41 AM
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: for statement initialiser
>
>
>What should be allowed in the for-statment initialiser?
>
>Currently, it is a bit broad, allowing a VarInstance as well as an
>Assignment.
>
>A VarInstance covers these possibilities:
>1. var integer foo
>2. var integer foo, bar
>3. var integer foo := 1
>4. var integer foo, bar := 1
>5. var integer foo := 1, bar := 1
>6. any of the above combinations with an ArrayDef after an identifer.
>
>Number 3 should definitely be legal. 1,2 should be illegal.
>Number 6 should probably be illegal.
>Numbers 4,5 I'm not sure: possibly legal (as long as there's an
>assignment somewhere)
>
>I'll put in a change request later next week tightening up
>this area, so
>if you don't agree with me, now's your chance to say so.
>
>Cheers,
>--
>

---

>Carl Cerecke - Software Designer
>Da Vinci Communications Ltd
>Christchurch - New Zealand
>

---

>TEL : +64 3 3838311
>FAX : +64 3 3838310
>e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
>www : www.davinci-communications.com
>

---

>

Gyorgy Rethy (ETH) wrote:
> Hi,
>
> Currently only (3) is legal, see subclause 19.7 of the standard:
>
> "The index variable of a for loop can be declared before being used
> in the for statement or can be declared and initialized in the for
> statement header. If the index variable is declared and initialized
> in the for statement header, the scope of the index variable is
> limited to the loop body, i.e. it is only visible inside the loop
> body."
>
> (the singular above excludes 5, all other alternatives are illegal
> because do not initialize the variable). I propose not to put a CR.

My reading of the paragraph above does not prohibit multiple
declarations in the initialiser of a for.
But...
Earlier in section 19.7, the sentence "The for statement conatins two
assignments and a boolean expression." implies that only one initialiser
is permitted.

The EBNF should be changed to reflect this:

something precise like:

Initial ::= Assignment | VarKeyword Type VarIdentifier AssignmentChar
VarInitialValue

instead of the current overly-broad definition of Initial:

Initial ::= Assignment | VarInstance

Cheers,
Carl
--

---

Carl Cerecke - Software Designer
Da Vinci Communications Ltd
Christchurch - New Zealand

---

TEL : +64 3 3838311
FAX : +64 3 3838310
e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
www : www.davinci-communications.com

---

On Mon, 25 Nov 2002, Carl Cerecke wrote:

> Gyorgy Rethy (ETH) wrote:
> > Hi,
> >
> > Currently only (3) is legal, see subclause 19.7 of the standard:
> >
> > "The index variable of a for loop can be declared before being used
> > in the for statement or can be declared and initialized in the for
> > statement header. If the index variable is declared and initialized
> > in the for statement header, the scope of the index variable is
> > limited to the loop body, i.e. it is only visible inside the loop
> > body."
> >
> > (the singular above excludes 5, all other alternatives are illegal
> > because do not initialize the variable). I propose not to put a CR.
>
> My reading of the paragraph above does not prohibit multiple
> declarations in the initialiser of a for.

I totally agree, as the restriction (in the above sentence) is only a
condition under which something else is restricted. There is nothing
said what happens if the condition is not met.

But, since uninitialized local variables don't make sense in a for-loop,
it would be prudent to add such a restriction (that all local variables
to a for-statement should be initialized by the for-initializer) to the
standard.

> But...
> Earlier in section 19.7, the sentence "The for statement conatins two
> assignments and a boolean expression." implies that only one initialiser
> is permitted.

A VarInstance wich declares and initializes several variables is
STILL only one (though obviously compound) statement, I would think.
I don't see the necessity of the restriction to at most one local
variable. What do you gain by it?

Jacob Wieland, TTthree-Team, TU-Berlin

Hi,

Do not muddle "simple" local variables (i.e. those declared within the statement block following the for construct) with the _for_ index (which is also a variabe)!

The _for_ header shall clearly identify and initialize THE _for_ index but nothing more. Variable declaration is allowed there just for the use of a local variable as the _for_ index but not vica versa, i.e. it shall not be used to declare local variables that are NOT used for the _for_ index. These shall be declared in the statement block.

Reading $19.7 again, this is clear from there (and from the sence of the whole _for_) even if the bnf does not explicitly excludes other options.

Nevertheless I agree that Carl's proposal

Initial ::= Assignment | VarKeyword Type VarIdentifier AssignmentChar
VarInitialValue

would simply remove any possibility of misuse!

Best Regards, György
Ãœdv, Gyuri

> dr György RÉTHY
> Manager
> Test Services, Test House, Ericsson Hungary
> Address: H-1037 Budapest, Laborc street 1.
> Phone: + 36 (1) 437-7006
> Mobile: + 36 (30) 297-7862
> Fax: + 36 (1) 437-7767
> Mail-to: This email address is being protected from spambots. You need JavaScript enabled to view it.


>

---

Original Message

---

>From: Jacob 'Ugh' Wieland [This email address is being protected from spambots. You need JavaScript enabled to view it.]
>Sent: Monday, November 25, 2002 11:55 AM
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: for statement initialiser
>
>
>On Mon, 25 Nov 2002, Carl Cerecke wrote:
>
>> Gyorgy Rethy (ETH) wrote:
>> > Hi,
>> >
>> > Currently only (3) is legal, see subclause 19.7 of the standard:
>> >
>> > "The index variable of a for loop can be declared before
>being used
>> > in the for statement or can be declared and initialized in the for
>> > statement header. If the index variable is declared and
>initialized
>> > in the for statement header, the scope of the index variable is
>> > limited to the loop body, i.e. it is only visible inside the loop
>> > body."
>> >
>> > (the singular above excludes 5, all other alternatives are illegal
>> > because do not initialize the variable). I propose not to
>put a CR.
>>
>> My reading of the paragraph above does not prohibit multiple
>> declarations in the initialiser of a for.
>
>I totally agree, as the restriction (in the above sentence) is only a
>condition under which something else is restricted. There is nothing
>said what happens if the condition is not met.
>
>But, since uninitialized local variables don't make sense in a
>for-loop,
>it would be prudent to add such a restriction (that all local variables
>to a for-statement should be initialized by the for-initializer) to the
>standard.
>
>> But...
>> Earlier in section 19.7, the sentence "The for statement conatins two
>> assignments and a boolean expression." implies that only one
>initialiser
>> is permitted.
>
>A VarInstance wich declares and initializes several variables is
>STILL only one (though obviously compound) statement, I would think.
>I don't see the necessity of the restriction to at most one local
>variable. What do you gain by it?
>
>Jacob Wieland, TTthree-Team, TU-Berlin
>

On Mon, 25 Nov 2002, Gyorgy Rethy (ETH) wrote:

> Hi,
>
> Do not muddle "simple" local variables (i.e. those declared within the
statement block following the for construct) with the _for_ index (which is also
a variabe)!

I didn't intend to do any such thing. I meant the for-header-variables
ONLY.

> The _for_ header shall clearly identify and initialize THE _for_ index but
nothing more. Variable declaration is allowed there just for the use of a local
variable as the _for_ index but not vica versa, i.e. it shall not be used to
declare local variables that are NOT used for the _for_ index. These shall be
declared in the statement block.

Where is it said that the variables in a for-statement shall be an
_index_?? It could very well be an enumerator-structure (like in Java):

for (var Enumerator e := enumerate(l); hasNext(e); ) {
... next(e) ...
}

It could also be several indices:

for (var integer row := 0, col := 0; row * width + col <= max; ) {
... screen[row * width + col] ...
... a[row] ...
... b[col] ...
col := col + 1;
if (col == width) {
col := 0;
row := row + 1;
}
}

Yes, I know that the last example could be programmed differently,
but that is not the point - all for-loops could be programmed using
while, too - there could be myriads of applications of for-statements
with multiple initializer-variables. No restriction to only one makes
any sense. (At least I haven't heard any reasons yet)

If you want a REAL for-statement which only deals with indices, then you
should introduce an own syntax (there's lots of 'em around, after all) and
not re-use other syntactic constructs and restrict them artificially.
All else will only confuse the user (who sees C-like syntax and thus
expects C-like behavior).

Jacob

Hi,

I'm a bit confused what this discussion is about? Originally there was a question if the _for_ statement is clear in the standard or not. I'm claiming that it is.

>Where is it said that the variables in a for-statement shall be an
>_index_??

Read the standard first! It is used there and that's all. I think this mailing list is to discuss essential issues (by the way it does not mean a type restriction, e.g. "an integer type variable"; as shown in example 2 of 19.7).

Also, if you have an idea to allow indeces instead of one index, let's put a CR. But the FACT IS that today a single index is allowed:

"... The first assignment is necessary to initialize the index (or counter) variable of the loop....
The index variable of a for loop can be declared before being used in the for statement or can be declared and initialized in the for statement header. If the index variable is declared and initialized in the for statement header, the scope of the index variable is limited to the loop body, i.e. it is only visible inside the loop body."

Hence your example is simply invalid and does not answers the original question (or answers it incorrectly).

Best Regards, György

> dr György RÉTHY
> Manager
> Test Services, Test House, Ericsson Hungary
> Address: H-1037 Budapest, Laborc street 1.
> Phone: + 36 (1) 437-7006
> Mobile: + 36 (30) 297-7862
> Fax: + 36 (1) 437-7767
> Mail-to: This email address is being protected from spambots. You need JavaScript enabled to view it.


>

---

Original Message

---

>From: Jacob 'Ugh' Wieland [This email address is being protected from spambots. You need JavaScript enabled to view it.]
>Sent: Monday, November 25, 2002 6:04 PM
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: for statement initialiser
>
>
>On Mon, 25 Nov 2002, Gyorgy Rethy (ETH) wrote:
>
>> Hi,
>>
>> Do not muddle "simple" local variables (i.e. those declared
>within the statement block following the for construct) with
>the _for_ index (which is also a variabe)!
>
>I didn't intend to do any such thing. I meant the for-header-variables
>ONLY.
>
>> The _for_ header shall clearly identify and initialize THE
>_for_ index but nothing more. Variable declaration is allowed
>there just for the use of a local variable as the _for_ index
>but not vica versa, i.e. it shall not be used to declare local
>variables that are NOT used for the _for_ index. These shall
>be declared in the statement block.
>
>Where is it said that the variables in a for-statement shall be an
>_index_?? It could very well be an enumerator-structure (like in Java):
>
>for (var Enumerator e := enumerate(l); hasNext(e); ) {
> ... next(e) ...
>}
>
>It could also be several indices:
>
>for (var integer row := 0, col := 0; row * width + col <= max; ) {
> ... screen[row * width + col] ...
> ... a[row] ...
> ... b[col] ...
> col := col + 1;
> if (col == width) {
> col := 0;
> row := row + 1;
> }
>}
>
>Yes, I know that the last example could be programmed differently,
>but that is not the point - all for-loops could be programmed using
>while, too - there could be myriads of applications of for-statements
>with multiple initializer-variables. No restriction to only one makes
>any sense. (At least I haven't heard any reasons yet)
>
>If you want a REAL for-statement which only deals with
>indices, then you
>should introduce an own syntax (there's lots of 'em around,
>after all) and
>not re-use other syntactic constructs and restrict them artificially.
>All else will only confuse the user (who sees C-like syntax and thus
>expects C-like behavior).
>
>Jacob
>

Gyorgy Rethy (ETH) wrote:
> Hi,
>
> I'm a bit confused what this discussion is about? Originally there
> was a question if the _for_ statement is clear in the standard or
> not. I'm claiming that it is.

The description of the for-statement in the EBNF does not match the
description of the for-statement in Section 19.7

Furthermore, there is a range of generalness of the for-statement among
different languages. At the specific end, we have something like:
"for i := 1 to 10 step 2", with a specific index variable, a specific
start and end, and an optional specific step in the index. At the other
extreme, there are languages like C, which allow arbitrary and optional
expressions in the for-statement. That can lead to programs like this
interesting 2-line specimen (ioccc.org/1995/makarios.c):
main(n,i,a,m){while(i=++n)
for(a=0;a<i?a=a*8+i%8,i/=8,m=a==i|a/8==i,1:(n-++m||printf("%o\n",n))&&n%m;);}

The TTCN-3 for-statement is inbetween these two extremes in its
generality: It requires an initial assignment (optional declaration) of
the index variable, a boolean expression which (presumably, but not
necessarily) tests the index variable, and a single assignment (again,
presumably, but not necessarily) to the index variable. This is, by far,
how for-statements are usually used in C, and these restrictions do not
impose too severe a limitation. There are a few cases where the
limitations might be frustrating, but they don't tend to occur very
often, in my opinion (unless you are trying to write obfuscated programs
like the C program above).

In short, I'm happy for the text of section 19.7 to remain the same, but
I think the EBNF should be changed to reflect the restrictions in the
initialiser part of the for-statment: one assignment or one initialised
variable declaration.

Cheers,
Carl
--

---

Carl Cerecke - Software Designer
Da Vinci Communications Ltd
Christchurch - New Zealand

---

TEL : +64 3 3838311
FAX : +64 3 3838310
e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
www : www.davinci-communications.com

---

Hi,

When I'm saying "clear" this means the bnf and the text together. It has to be clearly understood, that the language is not the bnf alone; not everything is allowed that is possible by the bnf. The text may contain additional restrictions to that (though the intention is to add these restrictions also to the bnf as operational semantic rules).

Best Regards, György

> dr György RÉTHY
> Manager
> Test Services, Test House, Ericsson Hungary
> Address: H-1037 Budapest, Laborc street 1.
> Phone: + 36 (1) 437-7006
> Mobile: + 36 (30) 297-7862
> Fax: + 36 (1) 437-7767
> Mail-to: This email address is being protected from spambots. You need JavaScript enabled to view it.


>

---

Original Message

---

>From: Carl Cerecke [This email address is being protected from spambots. You need JavaScript enabled to view it.]
>Sent: Tuesday, November 26, 2002 9:13 PM
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: for statement initialiser
>
>
>Gyorgy Rethy (ETH) wrote:
> > Hi,
> >
> > I'm a bit confused what this discussion is about? Originally there
> > was a question if the _for_ statement is clear in the standard or
> > not. I'm claiming that it is.
>
>The description of the for-statement in the EBNF does not match the
>description of the for-statement in Section 19.7
>
>Furthermore, there is a range of generalness of the for-statement among
>different languages. At the specific end, we have something like:
>"for i := 1 to 10 step 2", with a specific index variable, a specific
>start and end, and an optional specific step in the index. At the other
>extreme, there are languages like C, which allow arbitrary and optional
>expressions in the for-statement. That can lead to programs like this
>interesting 2-line specimen (ioccc.org/1995/makarios.c):
>main(n,i,a,m){while(i=++n)
>for(a=0;a<i?a=a*8+i%8,i/=8,m=a==i|a/8==i,1:(n-++m||printf("%o\n
",n))&&n%m;);}
>
>The TTCN-3 for-statement is inbetween these two extremes in its
>generality: It requires an initial assignment (optional declaration) of
>the index variable, a boolean expression which (presumably, but not
>necessarily) tests the index variable, and a single assignment (again,
>presumably, but not necessarily) to the index variable. This
>is, by far,
>how for-statements are usually used in C, and these restrictions do not
>impose too severe a limitation. There are a few cases where the
>limitations might be frustrating, but they don't tend to occur very
>often, in my opinion (unless you are trying to write
>obfuscated programs
>like the C program above).
>
>In short, I'm happy for the text of section 19.7 to remain the
>same, but
>I think the EBNF should be changed to reflect the restrictions in the
>initialiser part of the for-statment: one assignment or one initialised
>variable declaration.
>
>Cheers,
>Carl
>--
>

---

>Carl Cerecke - Software Designer
>Da Vinci Communications Ltd
>Christchurch - New Zealand
>

---

>TEL : +64 3 3838311
>FAX : +64 3 3838310
>e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
>www : www.davinci-communications.com
>

---

>