Hi!



Does anyone have an updated version of the current reserved words in TTCN-3?
I have looked in the current CN (2002-08) but I think that there might be
something I have missed in the updating (except for Modulepar which should
be modulepar). I also have a question on the keyword runs on (which maybe
have been discussed before). What is the reason for having all other
keywords as one word but keeping runs on in two? Why not use runson which
would comply to how the other keywords are outlined?



BR



/Stefan



...---...---...---...---...---...---...---...---...---...---...---...---...-
--...

Stefan Olofsson

Software & Methods Engineer, Telelogic Technologies AB

Kungsgatan 6, SE-20312, Malmö, Sweden

Phone: +46 40 176760

Mobile: +46 705 174710

This email address is being protected from spambots. You need JavaScript enabled to view it. <This email address is being protected from spambots. You need JavaScript enabled to view it.>

<www.telelogic.com/> www.telelogic.com

...---...---...---...---...---...---...---...---...---...---...---...---...-
--...

Tau Generation2 - Development Visualized. Productivity

Realized. Learn more about Telelogic's new system and

software development solution at: <www.taug2.com/>
www.taug2.com.

In einer eMail vom 1/20/03 3:04:32 PM W. Europe Standard Time schreibt
This email address is being protected from spambots. You need JavaScript enabled to view it.:


>
> Hi!
>
>

Hi Stefan,


>
> Does anyone have an updated version of the current reserved words in
> TTCN-3?
>
> They are referred to as TTCN-3 terminals in the standard.
>

You can have a look in ES 201 873-1 V2.2.1 which is the latest version.
All reserved
words are found in Table A.3 in section A.1.5 TTCN-3 terminals. That is
the latest
I know of.

Whether this list is complete, I don't know.

I have looked in the current CN (2002-08) but I think that there might be
something I have
> missed in the updating (except for Modulepar which should be modulepar).

Agreed, another strange anomaly. I think it is just a typo.
You also have to look at the accepted list of CRs due to be included in
V2.2.2 as
Anthony Wiles explained. Have a look at the ETSI URL:


www.etsi.org/ptcc/TTCN-3%20CR/ptccttcn3cr.htm


I also have a question on the keyword runs on (which maybe have been
discussed
> before). What is the reason for having all other keywords as one word but
> keeping runs on in two? Why not use runson which would comply to how the
> other keywords are outlined?
>
>
good point. There is ifpresent, verdicttype, getverdict, getreply,
getcall,...

I guess runs on reads better than runson. From a consistency point of view,
this might
make sense, furthermore it would reduce the number of keywords/reserved
words/terminals by 1!


>
>
> BR
>
>
>
> /Stefan
>
>
>
> Cheers,
>
>
> Claude.
>
>



Claude Desroches e-mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
Technical Architect This email address is being protected from spambots. You need JavaScript enabled to view it.
Strategic Test Solutions Ltd.
City Gate East.
Toll House Hill,
Nottingham.
NG1 5FS.

Tel: +44 115 958 6600
Fax: +44 115 958 6633
Mob: +44 796 648 2165

Hi,

before). What is the reason for having all other keywords as one word but keeping runs on in two? Why not use runson which would comply to how the other keywords are outlined?

good point. There is ifpresent, verdicttype, getverdict, getreply, getcall,...

I guess runs on reads better than runson. From a consistency point of view, this might
make sense, furthermore it would reduce the number of keywords/reserved words/terminals by 1!

I also prefer simplicity where it is possible and readable. Sometimes not only number of words may be reduced in the standard but also in the construct itself.

Example1:

select (...)
case (... , ...)
{
...
}
case (..., ...)
{
...
}
case else
{
...
}

Example2:

case (...) {
... , ... : {
...
}
... , ... : {
...
}

else: {
...
}
}


Last changes to keywords in v. 2.2.1 in 2.2.0 tracked by me:

- nonrecursive
- sut
- get
- verdict
- (get verdict) -> + getverdict
- (set verdict) -> + setverdict // 'set' keyword was not removed as 'get'
+ except
+ variant
+ recursive
+ subset
+ superset
- teststep -> + altstep
- parameters -> + modulepar

I hope it is complete list.

BR,
Mariusz Kupiec

Thanks Mariusz!



I guess you helped me find the one I missed/was longing for...;-)



BR



/Stefan

---

Original Message

---

From: Mariusz Kupiec [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: Monday, January 20, 2003 5:07 PM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Reserved words in TTCN-3



Hi,



before). What is the reason for having all other keywords as one word but
keeping runs on in two? Why not use runson which would comply to how the
other keywords are outlined?



good point. There is ifpresent, verdicttype, getverdict, getreply,
getcall,...

I guess runs on reads better than runson. From a consistency point of
view, this might
make sense, furthermore it would reduce the number of keywords/reserved
words/terminals by 1!

I also prefer simplicity where it is possible and readable. Sometimes not
only number of words may be reduced in the standard but also in the
construct itself.



Example1:



select (...)

case (... , ...)
{

...
}
case (..., ...)
{
...
}

case else
{
...
}



Example2:



case (...) {

... , ... : {

...
}

... , ... : {

...
}

else: {

...
}

}



Last changes to keywords in v. 2.2.1 in 2.2.0 tracked by me:



- nonrecursive
- sut
- get
- verdict
- (get verdict) -> + getverdict

- (set verdict) -> + setverdict // 'set' keyword was not removed as 'get'

+ except

+ variant
+ recursive
+ subset

+ superset
- teststep -> + altstep

- parameters -> + modulepar

I hope it is complete list.



BR,

Mariusz Kupiec

---

Poczta nowych mozliwosci >>> link.interia.pl/f16bc
<link.interia.pl/f16bc>

Just a short explanatory word on reserved words:
It was a problem to 'invent' new words, which do not have other or
similar, but not identical, meanings
in other areas. And in some case it was a matter of taste to use two
words instead of one word.

At least I can easily read 'runs on' but would have to think some time
when reading 'runson'. On the
other hand I have no problems to read (and understand intuitively)
'getverdict', 'setverdict', 'getcall',
etc. but may have problems with 'anytimer', 'alltimer', 'anyport',
'allport' etc.

I don't believe that it would be any step forward to introduce 'runson'
and save one reserved word.
It would be more confusing if someone says 'runs on' and the other
'runson' (spoken in one word
without break between 'runs' and 'on').

However, some keywords are a matter of taste, but if there are parsing
problems with the 'two word'
keywords, something has to be changed immediately.

Regards
Jens

---

Original Message

---

Betreff: Re: Reserved words in TTCN-3
Datum: Mon, 20 Jan 2003 17:17:49 +0100
Von: Stefan Olofsson <This email address is being protected from spambots. You need JavaScript enabled to view it.>
Rückantwort: "active_ttcn3 : mts stf133 ttcn version 3 - active members
only" <This email address is being protected from spambots. You need JavaScript enabled to view it.>
An: This email address is being protected from spambots. You need JavaScript enabled to view it.

Thanks Mariusz!

I guess you helped me find the one I missed/was longing for...;-)

BR

/Stefan

---

Original Message

---

From: Mariusz Kupiec [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: Monday, January 20, 2003 5:07 PM
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: Reserved words in TTCN-3

Hi,

> before). What is the reason for having all other keywords as
> one word but keeping runs on in two? Why not
> use runson which would comply to how the other keywords are
> outlined?
>
> good point. There is ifpresent, verdicttype, getverdict, getreply,
> getcall,...
>
> I guess runs on reads better than runson. From a consistency point
> of view, this might
> make sense, furthermore it would reduce the number of
> keywords/reserved words/terminals by 1!

I also prefer simplicity where it is possible and readable. Sometimes
not only number of words may be reduced in the standard but also in the
construct itself.
Example1:
select (...)
case (... , ...)

{
...

}
case (..., ...)
{
...
}
case else

{
...
}
Example2:
case (...) {
... , ... : {
...

}
... , ... : {
...

}
else: {
...

}
}
Last changes to keywords in v. 2.2.1 in 2.2.0 tracked by me:
- nonrecursive

- sut
- get
- verdict
- (get verdict) -> + getverdict
- (set verdict) -> + setverdict // 'set' keyword was not removed as
'get'
+ except
+ variant

+ recursive
+ subset
+ superset

- teststep -> + altstep
- parameters -> + modulepar
I hope it is complete list.
BR,
Mariusz Kupiec

---

Poczta nowych mozliwosci >>> link.interia.pl/f16bc

Hi,

There is no problem with parsing two words and 'runs on' is ok according
this criteria.
You have mentioned 'anytimer', 'alltimer', 'anyport', 'allport'.
These words would be good because expressions like:

'all timer.stop'

look really awfully.
It looks like calling procedure or method for only 'timer', not 'all timer'.
I was thinking about it without introduction of new keywords because timers,
ports and components share 'all' and 'any' concept.
Just something like:

'(all timer).stop'
'all(timer).stop'

or better:

'timer.all.stop

but the solutions does not seem object oriented.
The last one may be eventually discussed as it is quite clear and consistent
without new keywords and with consistent three-leveled hierarchy:

a) port/component/timer - identifies set of objects
b) all/any - identifies selection criteria for the set of objects
c) action - identifies kind of action to be performed on a selected set of
objects

BR,
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: Monday, January 20, 2003 5:40 PM
Subject: Re: Reserved words in TTCN-3


> Just a short explanatory word on reserved words:
> It was a problem to 'invent' new words, which do not have other or
> similar, but not identical, meanings
> in other areas. And in some case it was a matter of taste to use two
> words instead of one word.
>
> At least I can easily read 'runs on' but would have to think some time
> when reading 'runson'. On the
> other hand I have no problems to read (and understand intuitively)
> 'getverdict', 'setverdict', 'getcall',
> etc. but may have problems with 'anytimer', 'alltimer', 'anyport',
> 'allport' etc.
>
> I don't believe that it would be any step forward to introduce 'runson'
> and save one reserved word.
> It would be more confusing if someone says 'runs on' and the other
> 'runson' (spoken in one word
> without break between 'runs' and 'on').
>
> However, some keywords are a matter of taste, but if there are parsing
> problems with the 'two word'
> keywords, something has to be changed immediately.
>
> Regards
> Jens
>
>
>
>
>

---

Original Message

---

> Betreff: Re: Reserved words in TTCN-3
> Datum: Mon, 20 Jan 2003 17:17:49 +0100
> Von: Stefan Olofsson <This email address is being protected from spambots. You need JavaScript enabled to view it.>
> Rückantwort: "active_ttcn3 : mts stf133 ttcn version 3 - active members
> only" <This email address is being protected from spambots. You need JavaScript enabled to view it.>
> An: This email address is being protected from spambots. You need JavaScript enabled to view it.
>
> Thanks Mariusz!
>
> I guess you helped me find the one I missed/was longing for...;-)
>
> BR
>
> /Stefan
>
>

---

Original Message

---

> From: Mariusz Kupiec [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Sent: Monday, January 20, 2003 5:07 PM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Reserved words in TTCN-3
>
> Hi,
>
> > before). What is the reason for having all other keywords as
> > one word but keeping runs on in two? Why not
> > use runson which would comply to how the other keywords are
> > outlined?
> >
> > good point. There is ifpresent, verdicttype, getverdict, getreply,
> > getcall,...
> >
> > I guess runs on reads better than runson. From a consistency point
> > of view, this might
> > make sense, furthermore it would reduce the number of
> > keywords/reserved words/terminals by 1!
>
> I also prefer simplicity where it is possible and readable. Sometimes
> not only number of words may be reduced in the standard but also in the
> construct itself.
> Example1:
> select (...)
> case (... , ...)
>
> {
> ...
>
> }
> case (..., ...)
> {
> ...
> }
> case else
>
> {
> ...
> }
> Example2:
> case (...) {
> ... , ... : {
> ...
>
> }
> ... , ... : {
> ...
>
> }
> else: {
> ...
>
> }
> }
> Last changes to keywords in v. 2.2.1 in 2.2.0 tracked by me:
> - nonrecursive
>
> - sut
> - get
> - verdict
> - (get verdict) -> + getverdict
> - (set verdict) -> + setverdict // 'set' keyword was not removed as
> 'get'
> + except
> + variant
>
> + recursive
> + subset
> + superset
>
> - teststep -> + altstep
> - parameters -> + modulepar
> I hope it is complete list.
> BR,
> Mariusz Kupiec
>
>

---

>
> Poczta nowych mozliwosci >>> link.interia.pl/f16bc
>
>

---

> Portal INTERIA.PL zaprasza... >>> link.interia.pl/f16ab
>
>
>

---

Poczta nowych mozliwosci >>> link.interia.pl/f16bc

Hi Mariusz,

your mail somehow repeats some discussions among Anthony, Colin and
myself in the beginning of the (short) TTCN-3 history. We started with
'anytimer', 'alltimer', 'anyport', 'allport', etc. and the table with
reserved words grows and grows and grows until we came to the conclusion
that this couldn't be the right way. We also experimented with
double (and triple and ...) dot notations (e.g., all.timer.stop) and
didn't like it (in fact we tried to avoid double, triple, etc. dot
notations whereever possible). At the end we agreed in a few cases on
double keywords.

That's all.

Regards
Jens

Mariusz Kupiec schrieb:
>
> Hi,
>
> There is no problem with parsing two words and 'runs on' is ok according
> this criteria.
> You have mentioned 'anytimer', 'alltimer', 'anyport', 'allport'.
> These words would be good because expressions like:
>
> 'all timer.stop'
>
> look really awfully.
> It looks like calling procedure or method for only 'timer', not 'all timer'.
> I was thinking about it without introduction of new keywords because timers,
> ports and components share 'all' and 'any' concept.
> Just something like:
>
> '(all timer).stop'
> 'all(timer).stop'
>
> or better:
>
> 'timer.all.stop
>
> but the solutions does not seem object oriented.
> The last one may be eventually discussed as it is quite clear and consistent
> without new keywords and with consistent three-leveled hierarchy:
>
> a) port/component/timer - identifies set of objects
> b) all/any - identifies selection criteria for the set of objects
> c) action - identifies kind of action to be performed on a selected set of
> objects
>
> BR,
> 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: Monday, January 20, 2003 5:40 PM
> Subject: Re: Reserved words in TTCN-3
>
> > Just a short explanatory word on reserved words:
> > It was a problem to 'invent' new words, which do not have other or
> > similar, but not identical, meanings
> > in other areas. And in some case it was a matter of taste to use two
> > words instead of one word.
> >
> > At least I can easily read 'runs on' but would have to think some time
> > when reading 'runson'. On the
> > other hand I have no problems to read (and understand intuitively)
> > 'getverdict', 'setverdict', 'getcall',
> > etc. but may have problems with 'anytimer', 'alltimer', 'anyport',
> > 'allport' etc.
> >
> > I don't believe that it would be any step forward to introduce 'runson'
> > and save one reserved word.
> > It would be more confusing if someone says 'runs on' and the other
> > 'runson' (spoken in one word
> > without break between 'runs' and 'on').
> >
> > However, some keywords are a matter of taste, but if there are parsing
> > problems with the 'two word'
> > keywords, something has to be changed immediately.
> >
> > Regards
> > Jens
> >
> >
> >
> >
> >

---

Original Message

---

> > Betreff: Re: Reserved words in TTCN-3
> > Datum: Mon, 20 Jan 2003 17:17:49 +0100
> > Von: Stefan Olofsson <This email address is being protected from spambots. You need JavaScript enabled to view it.>
> > Rückantwort: "active_ttcn3 : mts stf133 ttcn version 3 - active members
> > only" <This email address is being protected from spambots. You need JavaScript enabled to view it.>
> > An: This email address is being protected from spambots. You need JavaScript enabled to view it.
> >
> > Thanks Mariusz!
> >
> > I guess you helped me find the one I missed/was longing for...;-)
> >
> > BR
> >
> > /Stefan
> >
> >

---

Original Message

---

> > From: Mariusz Kupiec [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> > Sent: Monday, January 20, 2003 5:07 PM
> > To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > Subject: Re: Reserved words in TTCN-3
> >
> > Hi,
> >
> > > before). What is the reason for having all other keywords as
> > > one word but keeping runs on in two? Why not
> > > use runson which would comply to how the other keywords are
> > > outlined?
> > >
> > > good point. There is ifpresent, verdicttype, getverdict, getreply,
> > > getcall,...
> > >
> > > I guess runs on reads better than runson. From a consistency point
> > > of view, this might
> > > make sense, furthermore it would reduce the number of
> > > keywords/reserved words/terminals by 1!
> >
> > I also prefer simplicity where it is possible and readable. Sometimes
> > not only number of words may be reduced in the standard but also in the
> > construct itself.
> > Example1:
> > select (...)
> > case (... , ...)
> >
> > {
> > ...
> >
> > }
> > case (..., ...)
> > {
> > ...
> > }
> > case else
> >
> > {
> > ...
> > }
> > Example2:
> > case (...) {
> > ... , ... : {
> > ...
> >
> > }
> > ... , ... : {
> > ...
> >
> > }
> > else: {
> > ...
> >
> > }
> > }
> > Last changes to keywords in v. 2.2.1 in 2.2.0 tracked by me:
> > - nonrecursive
> >
> > - sut
> > - get
> > - verdict
> > - (get verdict) -> + getverdict
> > - (set verdict) -> + setverdict // 'set' keyword was not removed as
> > 'get'
> > + except
> > + variant
> >
> > + recursive
> > + subset
> > + superset
> >
> > - teststep -> + altstep
> > - parameters -> + modulepar
> > I hope it is complete list.
> > BR,
> > Mariusz Kupiec
> >
> >

---

> >
> > Poczta nowych mozliwosci >>> link.interia.pl/f16bc
> >
> >

---

> > Portal INTERIA.PL zaprasza... >>> link.interia.pl/f16ab
> >
> >
> >
>
>

---

> Poczta nowych mozliwosci >>> link.interia.pl/f16bc

--

======================================================================
Dr. Jens Grabowski
Institute for Telematics phone: +49 451 500 3723
University of Luebeck fax: +49 451 500 3722
Ratzeburger Allee 160 eMail: This email address is being protected from spambots. You need JavaScript enabled to view it.
D-23538 Luebeck or This email address is being protected from spambots. You need JavaScript enabled to view it.
(Germany) WWW: www.itm.mu-luebeck.de
======================================================================