Welcome,
Guest
|
|
TOPIC: Placement of Declarations
Placement of Declarations 23 Oct 2001 13:07 #6011
|
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! |
The administrator has disabled public write access.
|
Placement of Declarations 23 Oct 2001 13:42 #6012
|
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! > > > > |
The administrator has disabled public write access.
|
Placement of Declarations 23 Oct 2001 14:05 #6014
|
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! > > > > |
The administrator has disabled public write access.
|
Placement of Declarations 23 Oct 2001 21:20 #6017
|
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 |
The administrator has disabled public write access.
|
Placement of Declarations 24 Oct 2001 07:17 #6019
|
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. |
The administrator has disabled public write access.
|
Placement of Declarations 24 Oct 2001 09:15 #6020
|
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. |
The administrator has disabled public write access.
|
Placement of Declarations 24 Oct 2001 13:39 #6023
|
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 |
The administrator has disabled public write access.
|
Placement of Declarations 24 Oct 2001 15:29 #6024
|
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 |
The administrator has disabled public write access.
|
|