With reference to core language spec. 4.3.1.

I am having some difficulty reconciling the relevant parts of 15.6.2
(Referencing record and set fields) and the description of the ispresent
predefined function (C.31). There is either a mistake in the spec. or ispresent
is supposed to function with special semantics.

Here is a concrete example of my observation.

Modified from C.31:

type record MyRecord
{
record {
boolean innerField1 optional,
integer innerField2 optional
} field1 optional,
integer field2
}

var MyRecord vl_MyRecord := {field1 := omit, field2 := 5}

ispresent(vl_MyRecord.field1.innerField1) // shall return false because
field1 is omitted

But if the following were written:

log(vl_MyRecord.field1.innerField1)

a runtime error should occur, as required by 15.6.2a (dereferencing omit).

Given the choice I would remove the line from the example in C.31, thereby
upholding the consistency of the behaviour stated in 15.6.2.

This issue becomes more important when considered in combination with the
Behaviour Types package:

type function F(in integer inpar) return boolean

var F f := ispresent

apply(f(vl_MyRecord.field1.innerField1))

It should be obvious that it becomes almost impossible to apply special
semantics to the ispresent predefined function when it is used in such a way.

I look forward to hearing the opinions of other list members.

--
Regards

Richard Spence
Under contract to Nokia Siemens Networks
Ulm, Germany

I don't think the behavior types package was intended to be used in such
a way, i.e. using non-fixed type functions like ispresent etc. (though
it is an interesting idea). But, if it was (allowed to be) used in such
a way, then apply(f(x)) would of course need to have the same semantics
as ispresent(x).

In general, the is-predefined-functions are behaving like (mathematical)
partial functions in that they also allow unbound input without causing
an error automatically (unlike other functions which also allow unbound
in-parameters but only cause an error if that unbound parameter is used
in certain ways). Conceptually, I would rather categorize these
"functions" as special operations. The changes to these operations were
intended to increase user-friendliness of the language so that the user
can avoid long ispresent/isvalue/ischosen cascades before using a
specific deeply-nested part of a variable or parameter, making TTCN-3
source code more readable and thus better maintainable and less error prone.

Am 25.11.2011 18:39, schrieb Richard Spence:
> With reference to core language spec. 4.3.1.
>
> I am having some difficulty reconciling the relevant parts of 15.6.2
> (Referencing record and set fields) and the description of the
> ispresent predefined function (C.31). There is either a mistake in the
> spec. or ispresent is supposed to function with special semantics.
>
> Here is a concrete example of my observation.
>
> Modified from C.31:
>
> type record MyRecord
> {
> record {
> boolean innerField1 optional,
> integer innerField2 optional
> } field1 optional,
> integer field2
> }
>
> var MyRecord vl_MyRecord := {field1 := omit, field2 := 5}
>
> ispresent(vl_MyRecord.field1.innerField1) // shall return false
> because field1 is omitted
>
> But if the following were written:
>
> log(vl_MyRecord.field1.innerField1)
>
> a runtime error should occur, as required by 15.6.2a (dereferencing omit).
>
> Given the choice I would remove the line from the example in C.31,
> thereby upholding the consistency of the behaviour stated in 15.6.2.
>
> This issue becomes more important when considered in combination with
> the Behaviour Types package:
>
> type function F(in integer inpar) return boolean
>
> var F f := ispresent
>
> apply(f(vl_MyRecord.field1.innerField1))
>
> It should be obvious that it becomes almost impossible to apply
> special semantics to the ispresent predefined function when it is used
> in such a way.
>
> I look forward to hearing the opinions of other list members.
>
> --
> Regards
>
> Richard Spence
> Under contract to Nokia Siemens Networks
> Ulm, Germany
>

On 28 Nov 2011, at 12:01, Jacob Wieland <This email address is being protected from spambots. You need JavaScript enabled to view it.> wrote:

> I don't think the behavior types package was intended to be used in such a
way, i.e. using non-fixed type functions like ispresent etc. (though it is an
interesting idea). But, if it was (allowed to be) used in such a way, then
apply(f(x)) would of course need to have the same semantics as ispresent(x).

Use of predefined functions is already implicitly standardised. See ES 202 785
V1.1.1 section 6.2.13.2 where the example references int2char. The various
standards make no clear assertion that some predefined functions are special.

Furthermore section 5.4 of the behaviour types spec states that modulepars can
be used to hold behaviour values which means that the following is then legal:

type function F(in template integer inpar) return boolean
modulepar F f

apply(f(42))

// and have the environment supply ispresent as the value.

How then is a tool to know that special semantics shall be applied?

>

Am 28.11.2011 13:38, schrieb Richard Spence:
> On 28 Nov 2011, at 12:01, Jacob Wieland<This email address is being protected from spambots. You need JavaScript enabled to view it.> wrote:
>
>> I don't think the behavior types package was intended to be used in such a
way, i.e. using non-fixed type functions like ispresent etc. (though it is an
interesting idea). But, if it was (allowed to be) used in such a way, then
apply(f(x)) would of course need to have the same semantics as ispresent(x).
> Use of predefined functions is already implicitly standardised. See ES 202 785
V1.1.1 section 6.2.13.2 where the example references int2char. The various
standards make no clear assertion that some predefined functions are special.
>
> Furthermore section 5.4 of the behaviour types spec states that modulepars can
be used to hold behaviour values which means that the following is then legal:
>
> type function F(in template integer inpar) return boolean
> modulepar F f
>
> apply(f(42))
>
> // and have the environment supply ispresent as the value.
>
> How then is a tool to know that special semantics shall be applied?
I think the restriction for the is-predefined-functions is implicit as
you are not capable of writing down a function type that matches the
signature of these functions (since, as I remember it, the types of the
parameters in the function type and the function need to be the same).

Otherwise, I would wholeheartedly agree that it would be difficult to
implement and would then propose a change request toward this restriction.

BR, Jacob Wieland