Hi all,

Section 5.1.1 said :"Forward references are only allowed for declarations in the
module definitions part. Forward references shall never be made inside the
module control part, test case definitions, functions and altsteps. This means
forward references to local variables, local timers and local constants shall
never occur."

My question is: Whether the constants defined in a component type is global or
local?
for example:

moudule test
{
...
type component MyMTC
{
const integer a := b; //forward reference, I think
it's not valid
const integer b := 1;

}
...

}




Thank you.




Ji XiangDong
Univ. of Science & Technology of China
86-551-3606124
This email address is being protected from spambots. You need JavaScript enabled to view it.
2003-04-01 10:28:52

Hi Ji,

well, you are asking whether you can have forward references within a
component definition. Why not? I do not see a reason a to forbid it. In
addition says nothing contrary.

So in my view and reading of the standard, the example you gave is VALID.

Best regards,

Theo


xdji wrote:
> Hi all,
>
> Section 5.1.1 said :"Forward references are only allowed for
> declarations in the module definitions part. Forward references shall
> never be made inside the module control part, test case definitions,
> functions and altsteps. This means forward references to local
> variables, local timers and local constants shall never occur."
>
> My question is: Whether the constants defined in a component type is
> global or local? for example:
>
> moudule test { ... type component MyMTC { const integer a := b;
> //forward reference, I think it's not valid const integer b := 1;
>
> } ...
>
> }
>
>
>
>
> Thank you.
>
>
>
>
> Ji XiangDong Univ. of Science & Technology of China 86-551-3606124
> This email address is being protected from spambots. You need JavaScript enabled to view it. 2003-04-01 10:28:52
>


--

---

Theofanis Vassiliou-Gioles Testing Technologies IST
Oranienburger Str. 65 The TTCN-3 Company
10117 Berlin, Germany phone +49 30 726 19 19 0
This email address is being protected from spambots. You need JavaScript enabled to view it. DDI +49 30 726 19 19 12
www.testingtech.de fax +49 30 726 19 19 20

In einer eMail vom 4/1/03 4:45:00 AM W. Europe Daylight Time schreibt
This email address is being protected from spambots. You need JavaScript enabled to view it.:

Hi,


> My question is: Whether the constants defined in a component type is global
> or local?
> for example:
>
Constants declared in a component type are only visible (that is, are local)
to any component instance of that particular type. If you create 5
components of the same
type, then you will have 5 instances of that particular constant, each being
independent
of one another.

Hope this helps.

Cheers,

Claude.


Conformance Technologies Ltd. email: This email address is being protected from spambots. You need JavaScript enabled to view it.
685 Cedar Point Road phone: +1 705 533 23 94
Penetanguishene, Ontario
Canada
L9M 1R3

Solonplatz 3 phone: +49 30 9606 7986
13088 Berlin
Germany

In einer eMail vom 4/1/03 9:42:05 AM W. Europe Daylight Time schreibt
This email address is being protected from spambots. You need JavaScript enabled to view it.:

Hi again,


> > My question is: Whether the constants defined in a component type is
> > global or local? for example:
>
Humm, forward referencing may not have much to do with scoping/visibility.

Now, if b were defined outside the component type, and after it, then that
would be
a valid question.


Cheers,

Claude.


Conformance Technologies Ltd. email: This email address is being protected from spambots. You need JavaScript enabled to view it.
685 Cedar Point Road phone: +1 705 533 23 94
Penetanguishene, Ontario
Canada
L9M 1R3

Solonplatz 3 phone: +49 30 9606 7986
13088 Berlin
Germany

Hi Theo, hi Ji,

I agree that the current standard leaves this issue open, but I disagree that it should be allowed to use forward refernces in component declarations.

There is a good reason why forwards refences are allowed on module level (mutually recursive functions, types, etc., which could not be expressed otherwise), but I don't see what would be gained in terms of expressiveness when component members can be initialized with forward references. It only makes generation of code for the initialization unecessarily complicated without gain in expressiveness.

I would actually suggest writing a CR that disallows forward references

Example:

type component WithForwardReferences {

var integer x := 2 * y;
var integer y := c;
const integer c := d;
const integer d := 2;

}

Now, what is the value of x for a freshly instantiated component of type WithForwardReferences?

Two solutions come to my mind:

a) One cannot create components of this type because initializing x requires access to y, which is undefined at that time. In this case, why allow forward references in the first place?

b) The assignments are sorted so that y is initialized before x. I cannot find in the standard that this should be done. Furthermore, if the initialization of a variable might involve a side effect, e.g., via a call to an external function, this re-ordering will have unwanted side effects...

It is bad enought that this ordering needs to be done for module constants, but at least there no side effects can occur since the initialization must be a contant expression.

BR

Stephan Tobies

>

---

Original Message

---

> From: ext Theofanis Vassiliou-Gioles [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Sent: 01. April 2003 09:41
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Question about forward reference
>
>
> Hi Ji,
>
> well, you are asking whether you can have forward references within a
> component definition. Why not? I do not see a reason a to
> forbid it. In
> addition says nothing contrary.
>
> So in my view and reading of the standard, the example you
> gave is VALID.
>
> Best regards,
>
> Theo
>
>
> xdji wrote:
> > Hi all,
> >
> > Section 5.1.1 said :"Forward references are only allowed for
> > declarations in the module definitions part. Forward
> references shall
> > never be made inside the module control part, test case definitions,
> > functions and altsteps. This means forward references to local
> > variables, local timers and local constants shall never occur."
> >
> > My question is: Whether the constants defined in a component type is
> > global or local? for example:
> >
> > moudule test { ... type component MyMTC { const integer a := b;
> > //forward reference, I think it's not valid const integer b := 1;
> >
> > } ...
> >
> > }
> >
> >
> >
> >
> > Thank you.
> >
> >
> >
> >
> > Ji XiangDong Univ. of Science & Technology of China 86-551-3606124
> > This email address is being protected from spambots. You need JavaScript enabled to view it. 2003-04-01 10:28:52
> >
>
>
> --
>

---

> Theofanis Vassiliou-Gioles Testing Technologies IST
> Oranienburger Str. 65 The TTCN-3 Company
> 10117 Berlin, Germany phone +49 30 726 19 19 0
> This email address is being protected from spambots. You need JavaScript enabled to view it. DDI +49 30 726 19 19 12
> www.testingtech.de fax +49 30 726 19 19 20
>

In einer eMail vom 4/2/03 2:54:14 PM W. Europe Daylight Time schreibt
This email address is being protected from spambots. You need JavaScript enabled to view it.:

Hi Stephan,

I believe forward referencing was allowed into TTCN-3, because it is
permitted in ASN.1.
This is just a guess and would need confirmation from Anthony Wiles, Colin
Willcock,
or Jens Grabowski.

My personal opinion, as with yours, is that forward referencing is not useful
except in the
case of defining recursive (mutual or otherwise). TTCN-3 would be much
simpler to
implement if forward referencing were limited to the definition of mutually
recursive types,
functions, etc. and nowhere else.

In your example,

var integer x := 2 * y;
var integer y := c;
const integer c := d;
const integer d := 2;

}

you need to (potentially ) parse the entire module, or all modules involved
to be able to
determine the value of x, if y is forward referenced. Thinking more about
forward references,
there may be situations in which, if it were not allowed, that certain
declarations or
definitions which are interdependent, might not be possible to express. An
concrete
example fails me at this point in time... :-(. It may not be possible to
eliminate forward
referencing by re-ordering code.

Cheers,


Claude.

PS: One of the ideas behind TTCN-3 was to make it simpler, yet more
powerful. Surely
elimination of forward references would disallow mutual recursive function
definitions, which
would limit TTCN-3 expresiveness. However, limiting forward referencing to
cases where
mutual recursion is required, is also not so satisfactory, as one would
expect forward
referencing to be allowed for the entire language, instead of in only special
cases. Sticking
to generality makes learning of a new language simpler for users. Adding
special cases and conditions, only clutters a language, and makes its
learning unduly, and unnecessarily
more complex. People tend to have problems remembering special cases, and
assume the general case.

If forward referencing is removed, then it should be completely removed, or
left as is. No half way solution is acceptable, otherwise the generality
(could we say its orthogonality) starts to suffer. Avoiding having many
different special cases is always the better choice.

Anyways, those are my two Euro cents for tonight. :-)

Cheers,

Claude.





> Now, what is the value of x for a freshly instantiated component of type
> WithForwardReferences?
>


Conformance Technologies Ltd. email: This email address is being protected from spambots. You need JavaScript enabled to view it.
685 Cedar Point Road phone: +1 705 533 23 94
Penetanguishene, Ontario
Canada
L9M 1R3

Solonplatz 3 phone: +49 30 9606 7986
13088 Berlin
Germany

Hi all,

in TTCN-3 standard one reads "Definitions in the module definitions part
may be made in any order and while forward references should be avoided
(for readability reasons) this is not mandatory. For example, recursive
elements, such as functions that call other functions and module
parameterization, may lead to unavoidable forward references.

Forward references are only allowed for declarations in the module
definitions part. Forward references shall never be made inside the
module control part, test case definitions, functions and altsteps. This
means forward references to local variables, local timers and local
constants shall never occur. The only exceptions to this rule are
labels. Forward references to labels maybe used in goto statements to
jump forwards (see clause 19.5)."

Forward references within in component type definitions are not
explicitly forbidden and should be allowed.

In addition, one should follow the argumentation line of Claude - at
least partially since forward references are needed and cannot be
omitted - that "Avoiding having many different special cases is always
the better choice." We should discuss to delete the restriction given
above on the use of forward references in module control part, test case
definitions, functions and altsteps.

For a TTCN-3 user it is hard to understand that e.g. the following holds:

module test16 {

const integer C := D;
const integer D := 2; //allowed

type component TCType {
var integer x := 2 * y;
var integer y := c; //not explicitly forbidden, to be allowed
const integer c := d;
const integer d := 2; //not explicitly forbidden, to be allowed
}

function f() {
var integer x := 2 * y;
var integer y := c; //explicitly forbidden
const integer c := d;
const integer d := 2; //explicitly forbidden
}

control {
var integer x := 2 * y;
var integer y := c; //explicitly forbidden
const integer c := d;
const integer d := 2; //explicitly forbidden
}

}

For what reason is their a need to have forward references on global
level (i.e. module definition) only, but not on local level - the same
argument on recursive elements apply to local scopes as well.

So, in order to have this expressiveness on all levels and to ease the
usage, we should simply allow forward references in TTCN-3. A style
guide could explain that forward references should be avoided for
readability reasons, but the language should have the complete and not
just half of the feature.

Cheers, Ina.


Claude Desroches wrote:
> In einer eMail vom 4/2/03 2:54:14 PM W. Europe Daylight Time schreibt
> This email address is being protected from spambots. You need JavaScript enabled to view it.:
>
> Hi Stephan,
>
> I believe forward referencing was allowed into TTCN-3, because it is
> permitted in ASN.1.
> This is just a guess and would need confirmation from Anthony Wiles,
> Colin Willcock,
> or Jens Grabowski.
>
> My personal opinion, as with yours, is that forward referencing is not
> useful except in the
> case of defining recursive (mutual or otherwise). TTCN-3 would be much
> simpler to
> implement if forward referencing were limited to the definition of
> mutually recursive types,
> functions, etc. and nowhere else.
>
> In your example,
>
> var integer x := 2 * y;
> var integer y := c;
> const integer c := d;
> const integer d := 2;
>
> }
>
> you need to (potentially ) parse the entire module, or all modules
> involved to be able to
> determine the value of x, if y is forward referenced. Thinking more
> about forward references,
> there may be situations in which, if it were not allowed, that certain
> declarations or
> definitions which are interdependent, might not be possible to express.
> An concrete
> example fails me at this point in time... :-(. It may not be possible
> to eliminate forward
> referencing by re-ordering code.
>
> Cheers,
>
>
> Claude.
>
> PS: One of the ideas behind TTCN-3 was to make it simpler, yet more
> powerful. Surely
> elimination of forward references would disallow mutual recursive
> function definitions, which
> would limit TTCN-3 expresiveness. However, limiting forward referencing
> to cases where
> mutual recursion is required, is also not so satisfactory, as one would
> expect forward
> referencing to be allowed for the entire language, instead of in only
> special cases. Sticking
> to generality makes learning of a new language simpler for users.
> Adding special cases and conditions, only clutters a language, and makes
> its learning unduly, and unnecessarily
> more complex. People tend to have problems remembering special cases,
> and assume the general case.
>
> If forward referencing is removed, then it should be completely removed,
> or left as is. No half way solution is acceptable, otherwise the
> generality (could we say its orthogonality) starts to suffer. Avoiding
> having many different special cases is always the better choice.
>
> Anyways, those are my two Euro cents for tonight. :-)
>
> Cheers,
>
> Claude.
>
>
>
>
>
>> Now, what is the value of x for a freshly instantiated component of
>> type WithForwardReferences?
>
>
>
>
> Conformance Technologies Ltd. email: This email address is being protected from spambots. You need JavaScript enabled to view it.
> 685 Cedar Point Road phone: +1 705 533 23 94
> Penetanguishene, Ontario
> Canada
> L9M 1R3
>
> Solonplatz 3 phone: +49 30 9606 7986
> 13088 Berlin
> Germany


--

---

Ina Schieferdecker
Fraunhofer FOKUS email: This email address is being protected from spambots. You need JavaScript enabled to view it.
Kaiserin-Augusta-Allee 31 tel: ++49-30-3463-7241
D-10589 Berlin fax: ++49-30-3463-8241

---

Hi Ina,

I absolutely disagree. The standard clearly discourages the use of forward references even where they are allowed, which is only in the module definitions part. And I see no reason whatsoever to allow forward references anywhere else. They are hard to understand and error prone.

Also, they semantics is unclear - are the initializations re-order or executed in the order in which they are stated. And if the latter approach is taken, what happens with uninitialized values - remember, your viewpoint that uninitialized variables can be used on the RHS of assignments is not unchallenged.

So, what about component variables and constants. You write that they are definitions on moduel level so that forward referencing is allowed. I disagree - a component type declaration forms its own scope. And in this scope, no forward references are allowed. Yes, the standard is grey in this area and it should clarify this, but it should clarify things so that no forward references are allowed. Again, there is no gain in expressivity, but a loss in semantic clarity and a possible error source if we allow forward references.

I really fail to see what is to gain from allowing forward references. I'm open to arguments here, but to make the language less restictive just to make it less restrictive and w/o a gain in expressivity, succinctness, or notational clarity, does not make sense to me.

BR

Stephan Tobies

>

---

Original Message

---

> From: ext Ina Schieferdecker
> [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Sent: 03. April 2003 07:31
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Question about forward reference
>
>
> Hi all,
>
> in TTCN-3 standard one reads "Definitions in the module
> definitions part
> may be made in any order and while forward references should
> be avoided
> (for readability reasons) this is not mandatory. For example,
> recursive
> elements, such as functions that call other functions and module
> parameterization, may lead to unavoidable forward references.
>
> Forward references are only allowed for declarations in the module
> definitions part. Forward references shall never be made inside the
> module control part, test case definitions, functions and
> altsteps. This
> means forward references to local variables, local timers and local
> constants shall never occur. The only exceptions to this rule are
> labels. Forward references to labels maybe used in goto statements to
> jump forwards (see clause 19.5)."
>
> Forward references within in component type definitions are not
> explicitly forbidden and should be allowed.
>
> In addition, one should follow the argumentation line of Claude - at
> least partially since forward references are needed and cannot be
> omitted - that "Avoiding having many different special cases is always
> the better choice." We should discuss to delete the restriction given
> above on the use of forward references in module control
> part, test case
> definitions, functions and altsteps.
>
> For a TTCN-3 user it is hard to understand that e.g. the
> following holds:
>
> module test16 {
>
> const integer C := D;
> const integer D := 2; //allowed
>
> type component TCType {
> var integer x := 2 * y;
> var integer y := c; //not explicitly forbidden, to
> be allowed
> const integer c := d;
> const integer d := 2; //not explicitly forbidden, to
> be allowed
> }
>
> function f() {
> var integer x := 2 * y;
> var integer y := c; //explicitly forbidden
> const integer c := d;
> const integer d := 2; //explicitly forbidden
> }
>
> control {
> var integer x := 2 * y;
> var integer y := c; //explicitly forbidden
> const integer c := d;
> const integer d := 2; //explicitly forbidden
> }
>
> }
>
> For what reason is their a need to have forward references on global
> level (i.e. module definition) only, but not on local level - the same
> argument on recursive elements apply to local scopes as well.
>
> So, in order to have this expressiveness on all levels and to ease the
> usage, we should simply allow forward references in TTCN-3. A style
> guide could explain that forward references should be avoided for
> readability reasons, but the language should have the complete and not
> just half of the feature.
>
> Cheers, Ina.
>
>
> Claude Desroches wrote:
> > In einer eMail vom 4/2/03 2:54:14 PM W. Europe Daylight
> Time schreibt
> > This email address is being protected from spambots. You need JavaScript enabled to view it.:
> >
> > Hi Stephan,
> >
> > I believe forward referencing was allowed into TTCN-3, because it is
> > permitted in ASN.1.
> > This is just a guess and would need confirmation from Anthony Wiles,
> > Colin Willcock,
> > or Jens Grabowski.
> >
> > My personal opinion, as with yours, is that forward
> referencing is not
> > useful except in the
> > case of defining recursive (mutual or otherwise). TTCN-3
> would be much
> > simpler to
> > implement if forward referencing were limited to the definition of
> > mutually recursive types,
> > functions, etc. and nowhere else.
> >
> > In your example,
> >
> > var integer x := 2 * y;
> > var integer y := c;
> > const integer c := d;
> > const integer d := 2;
> >
> > }
> >
> > you need to (potentially ) parse the entire module, or all modules
> > involved to be able to
> > determine the value of x, if y is forward referenced. Thinking more
> > about forward references,
> > there may be situations in which, if it were not allowed,
> that certain
> > declarations or
> > definitions which are interdependent, might not be possible
> to express.
> > An concrete
> > example fails me at this point in time... :-(. It may not
> be possible
> > to eliminate forward
> > referencing by re-ordering code.
> >
> > Cheers,
> >
> >
> > Claude.
> >
> > PS: One of the ideas behind TTCN-3 was to make it simpler, yet more
> > powerful. Surely
> > elimination of forward references would disallow mutual recursive
> > function definitions, which
> > would limit TTCN-3 expresiveness. However, limiting
> forward referencing
> > to cases where
> > mutual recursion is required, is also not so satisfactory,
> as one would
> > expect forward
> > referencing to be allowed for the entire language, instead
> of in only
> > special cases. Sticking
> > to generality makes learning of a new language simpler for users.
> > Adding special cases and conditions, only clutters a
> language, and makes
> > its learning unduly, and unnecessarily
> > more complex. People tend to have problems remembering
> special cases,
> > and assume the general case.
> >
> > If forward referencing is removed, then it should be
> completely removed,
> > or left as is. No half way solution is acceptable, otherwise the
> > generality (could we say its orthogonality) starts to
> suffer. Avoiding
> > having many different special cases is always the better choice.
> >
> > Anyways, those are my two Euro cents for tonight. :-)
> >
> > Cheers,
> >
> > Claude.
> >
> >
> >
> >
> >
> >> Now, what is the value of x for a freshly instantiated component of
> >> type WithForwardReferences?
> >
> >
> >
> >
> > Conformance Technologies Ltd. email: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > 685 Cedar Point Road phone: +1 705 533 23 94
> > Penetanguishene, Ontario
> > Canada
> > L9M 1R3
> >
> > Solonplatz 3 phone: +49 30 9606 7986
> > 13088 Berlin
> > Germany
>
>
> --
>

---

>

---

> Ina Schieferdecker
> Fraunhofer FOKUS email:
> This email address is being protected from spambots. You need JavaScript enabled to view it.
> Kaiserin-Augusta-Allee 31 tel: ++49-30-3463-7241
> D-10589 Berlin fax: ++49-30-3463-8241
>

---

>

---

>

Haven't posted for a while so hi all. You seemed to be getting on so well
without me too.

But this one is a long standing issue with me in several languages. Forward
references are indeed a nightmare to implement and the source of more
problems than they ever solve.

The only valid use, other than allowing total idleness of thought for the
user, are recursive structures and mutually recursive functions and labels.

Specifically for functions, there is even less need for any forward
referencing. In those languages that allow function definitions to be nested
there is no need for FR's except in the fairly rare case of needing both
functions to be initial entry points.

But that is not good enough for us. We need something that handles the
structures and labels too. So what exactly is wrong with partial
declarations (ie type fred;)? Many languages do it. It isn't as though we
would be breaking new ground and doing something unfamiliar to users.

What? Even labels? Yup. There have been languages that some of us are old
enough to remember where labels had to be declared in a 'label' statement.

So there is known tried and tested technology that means forward references
are never needed.

Summary it is a complete pain in the **** to implement and use and is never
theoretically needed. So taking steps to ensure it's demise would seem
mandatory to me.

Regards

Derek

---

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

---

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

---

Original Message

---

From: Stephen TOBIES [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: 03 April 2003 07:15
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Question about forward reference


Hi Ina,

I absolutely disagree. The standard clearly discourages the use of forward
references even where they are allowed, which is only in the module
definitions part. And I see no reason whatsoever to allow forward references
anywhere else. They are hard to understand and error prone.

Also, they semantics is unclear - are the initializations re-order or
executed in the order in which they are stated. And if the latter approach
is taken, what happens with uninitialized values - remember, your viewpoint
that uninitialized variables can be used on the RHS of assignments is not
unchallenged.

So, what about component variables and constants. You write that they are
definitions on moduel level so that forward referencing is allowed. I
disagree - a component type declaration forms its own scope. And in this
scope, no forward references are allowed. Yes, the standard is grey in this
area and it should clarify this, but it should clarify things so that no
forward references are allowed. Again, there is no gain in expressivity, but
a loss in semantic clarity and a possible error source if we allow forward
references.

I really fail to see what is to gain from allowing forward references. I'm
open to arguments here, but to make the language less restictive just to
make it less restrictive and w/o a gain in expressivity, succinctness, or
notational clarity, does not make sense to me.

BR

Stephan Tobies

>

---

Original Message

---

> From: ext Ina Schieferdecker
> [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Sent: 03. April 2003 07:31
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Question about forward reference
>
>
> Hi all,
>
> in TTCN-3 standard one reads "Definitions in the module
> definitions part
> may be made in any order and while forward references should
> be avoided
> (for readability reasons) this is not mandatory. For example,
> recursive
> elements, such as functions that call other functions and module
> parameterization, may lead to unavoidable forward references.
>
> Forward references are only allowed for declarations in the module
> definitions part. Forward references shall never be made inside the
> module control part, test case definitions, functions and
> altsteps. This
> means forward references to local variables, local timers and local
> constants shall never occur. The only exceptions to this rule are
> labels. Forward references to labels maybe used in goto statements to
> jump forwards (see clause 19.5)."
>
> Forward references within in component type definitions are not
> explicitly forbidden and should be allowed.
>
> In addition, one should follow the argumentation line of Claude - at
> least partially since forward references are needed and cannot be
> omitted - that "Avoiding having many different special cases is always
> the better choice." We should discuss to delete the restriction given
> above on the use of forward references in module control
> part, test case
> definitions, functions and altsteps.
>
> For a TTCN-3 user it is hard to understand that e.g. the
> following holds:
>
> module test16 {
>
> const integer C := D;
> const integer D := 2; //allowed
>
> type component TCType {
> var integer x := 2 * y;
> var integer y := c; //not explicitly forbidden, to
> be allowed
> const integer c := d;
> const integer d := 2; //not explicitly forbidden, to
> be allowed
> }
>
> function f() {
> var integer x := 2 * y;
> var integer y := c; //explicitly forbidden
> const integer c := d;
> const integer d := 2; //explicitly forbidden
> }
>
> control {
> var integer x := 2 * y;
> var integer y := c; //explicitly forbidden
> const integer c := d;
> const integer d := 2; //explicitly forbidden
> }
>
> }
>
> For what reason is their a need to have forward references on global
> level (i.e. module definition) only, but not on local level - the same
> argument on recursive elements apply to local scopes as well.
>
> So, in order to have this expressiveness on all levels and to ease the
> usage, we should simply allow forward references in TTCN-3. A style
> guide could explain that forward references should be avoided for
> readability reasons, but the language should have the complete and not
> just half of the feature.
>
> Cheers, Ina.
>
>
> Claude Desroches wrote:
> > In einer eMail vom 4/2/03 2:54:14 PM W. Europe Daylight
> Time schreibt
> > This email address is being protected from spambots. You need JavaScript enabled to view it.:
> >
> > Hi Stephan,
> >
> > I believe forward referencing was allowed into TTCN-3, because it is
> > permitted in ASN.1.
> > This is just a guess and would need confirmation from Anthony Wiles,
> > Colin Willcock,
> > or Jens Grabowski.
> >
> > My personal opinion, as with yours, is that forward
> referencing is not
> > useful except in the
> > case of defining recursive (mutual or otherwise). TTCN-3
> would be much
> > simpler to
> > implement if forward referencing were limited to the definition of
> > mutually recursive types,
> > functions, etc. and nowhere else.
> >
> > In your example,
> >
> > var integer x := 2 * y;
> > var integer y := c;
> > const integer c := d;
> > const integer d := 2;
> >
> > }
> >
> > you need to (potentially ) parse the entire module, or all modules
> > involved to be able to
> > determine the value of x, if y is forward referenced. Thinking more
> > about forward references,
> > there may be situations in which, if it were not allowed,
> that certain
> > declarations or
> > definitions which are interdependent, might not be possible
> to express.
> > An concrete
> > example fails me at this point in time... :-(. It may not
> be possible
> > to eliminate forward
> > referencing by re-ordering code.
> >
> > Cheers,
> >
> >
> > Claude.
> >
> > PS: One of the ideas behind TTCN-3 was to make it simpler, yet more
> > powerful. Surely
> > elimination of forward references would disallow mutual recursive
> > function definitions, which
> > would limit TTCN-3 expresiveness. However, limiting
> forward referencing
> > to cases where
> > mutual recursion is required, is also not so satisfactory,
> as one would
> > expect forward
> > referencing to be allowed for the entire language, instead
> of in only
> > special cases. Sticking
> > to generality makes learning of a new language simpler for users.
> > Adding special cases and conditions, only clutters a
> language, and makes
> > its learning unduly, and unnecessarily
> > more complex. People tend to have problems remembering
> special cases,
> > and assume the general case.
> >
> > If forward referencing is removed, then it should be
> completely removed,
> > or left as is. No half way solution is acceptable, otherwise the
> > generality (could we say its orthogonality) starts to
> suffer. Avoiding
> > having many different special cases is always the better choice.
> >
> > Anyways, those are my two Euro cents for tonight. :-)
> >
> > Cheers,
> >
> > Claude.
> >
> >
> >
> >
> >
> >> Now, what is the value of x for a freshly instantiated component of
> >> type WithForwardReferences?
> >
> >
> >
> >
> > Conformance Technologies Ltd. email: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > 685 Cedar Point Road phone: +1 705 533 23 94
> > Penetanguishene, Ontario
> > Canada
> > L9M 1R3
> >
> > Solonplatz 3 phone: +49 30 9606 7986
> > 13088 Berlin
> > Germany
>
>
> --
>

---

>

---

> Ina Schieferdecker
> Fraunhofer FOKUS email:
> This email address is being protected from spambots. You need JavaScript enabled to view it.
> Kaiserin-Augusta-Allee 31 tel: ++49-30-3463-7241
> D-10589 Berlin fax: ++49-30-3463-8241
>

---

>

---

>

On Thu, 3 Apr 2003, Lazenby, Derek wrote:

> But this one is a long standing issue with me in several languages. Forward
> references are indeed a nightmare to implement and the source of more
> problems than they ever solve.
>
> The only valid use, other than allowing total idleness of thought for the
> user, are recursive structures and mutually recursive functions and labels.
>
> Specifically for functions, there is even less need for any forward
> referencing. In those languages that allow function definitions to be nested
> there is no need for FR's except in the fairly rare case of needing both
> functions to be initial entry points.

But, this is not the case in TTCN-3, so this would make them
necessary there. And even if there are only SOME cases even
in those languages, where it is necessary, I wouldn't forbid it.

> But that is not good enough for us. We need something that handles the
> structures and labels too. So what exactly is wrong with partial
> declarations (ie type fred;)? Many languages do it. It isn't as though we
> would be breaking new ground and doing something unfamiliar to users.

This kind of construct was used for compilers which had to run on
computers with not a lot of memory, so the one-pass-approach seemed
beneficiary and THIS was what made these (actually even then undesirable)
forward-declarations necessary.

Having passed that stone-age of compiler-construction, the need
for such strange constructs ceased, as forward-references (in a
declarative scope) are indeed very easy to implement with multi-pass
compilers. So, why go back to the stone-age, if it's not necessary?

> What? Even labels? Yup. There have been languages that some of us are old
> enough to remember where labels had to be declared in a 'label' statement.
>
> So there is known tried and tested technology that means forward references
> are never needed.

There are other much more modern tried and tested technologies which
make such outdated workarounds unnecessary. Nobody wants to program
a Turing-machine, either, even though it theoretically works fine.

> Summary it is a complete pain in the **** to implement and use and is never
> theoretically needed. So taking steps to ensure it's demise would seem
> mandatory to me.

Computers (and many other things, like compilers or totally new
programming languages, as long as we already have old ones which
also have the power of the Turing-Machine) are never needed
theoretically, either. Most people could very well do without them.
But, since we have them, why don't we put them to sensible use?
Of course, sometimes, some things that appear to be new make things
harder - at first. But that should not keep you from learning and
then using them appropriately.

I think I totally agree with Stephen Tobies on this issue.

I, personally, even would explicitely fobid forward referencing
(even in the module declarations part) for constants/templates to
other constants/templates, as this can very well lead to
situations like:

module M {
const integer i := j * 2;
const integer j := i + 5;
}

which clearly shouldn't work (even though you could try to
tackle it by solving the equation system first :-)), so, if
you allowed such forward referencing, the ensurance that the
interdependence must be acyclic must be given, as well.
Forbidding forward referencing for these constructs avoids making
this check necessary (even though it is not very complex both to
implement and to compute).

For the declarations of all parameterizable and all purely
declarative constructs like data types, there needs to be no
such restriction untowards the mutual referencing, so there
should not be imposed one.

But, inside non-declarative constructs like function bodies where
the assignments are not simply interpreted as initializations
but as changes of the state of the running program, foward
references make no sense whatsoever in my view (as they would
ALWAYS reference uninitialized variables and in most cases try
to USE them at the same time, which in most languages would
automatically lead either to an error or to an indefinite state
of the program).

So, please, let's not go back to the stone-age, because everything
seemed so much simpler then, even though it was far more complicated. :-)

Cheers,

Jacob Wieland, Compiler Construction - TU-Berlin

In einer eMail vom 4/3/03 10:49:32 AM W. Europe Daylight Time schreibt
This email address is being protected from spambots. You need JavaScript enabled to view it.:

Hi Derek,

Forward references as you say are a proverbial 'pain in the you know what'.
I would be
for an all or nothing solution. Then again, how do you solve the problem of
mutually
recursive functions. Well, C solves it in a tidy way,and I would have
nothing against
having to declare labels, in fact that would provide a way for developers to
ensure that
only declared labels are being used, then again, I remember the seemingly
'useless'
addition of PCO Type Declarations proforma into the TTCN-2 standard. You can
still
process an ATS without this proforma, but when there, other static semantic
verifications
can be made which are not possible if it were not there. E.g. mistyping a
PCO Type
won't be flagged unless one writes code where PDUs and ASPs specified on a
send
or receive statement have a different PCO Type. But until one finds this
error, well,
it can take some time if you are not familiar with TTCN-2.

>
> Summary it is a complete pain in the **** to implement and use and is never
> theoretically needed. So taking steps to ensure it's demise would seem
> mandatory to me.
>

\cheers,

Claude.

PS: I'm always for simplification, without loss of expressiveness. I guess
we should
re-evaluation what forward referencing brings to us. Remember, that
ASN.1
allows forward referencing... But since both these notations (TTCN-3
and ASN.1)
have been cleanly separated from one another, and may only be used
through
the import statement, the need for forward referencing no longer
seems so
'necessary'.

Conformance Technologies Ltd. email: This email address is being protected from spambots. You need JavaScript enabled to view it.
685 Cedar Point Road phone: +1 705 533 23 94
Penetanguishene, Ontario
Canada
L9M 1R3

Solonplatz 3 phone: +49 30 9606 7986
13088 Berlin
Germany