On Mon, 3 Sep 2001, Michael Ebner wrote:

> > I think that type coercion is the way to go. Besides, we've done away
> > with STRONG TYPING, why not go all the way with type cooercion
> > (at one's own risk) :-).

I think then it would have to be defined what 'type coercion'
would actually _mean_. Since the definition of 'structural type
compatibility' in the revision draft of the standard, there is
an implicit type coercion existant. It is questionable, whether
an additional explicit coercion is needed - since the question
arises what a 'cast' into a non-compatible type should signify.

This has to do nothing with 'risk' (as in C). The situation in
TTCN-3 is very different from C, as the internal memory layout
of data is generally unspecified and thus can not be 'reinterpreted'
by casting like in C. The void-pointer which is a very special
case (as it removes any special interpretation), is an exception,
of course.

> Yes, that could be a solution for the any problem. It looks like the
> solution given by the C language mapping for CORBA IDL. It uses a void
> pointer to store the value and has to be cast to get the value.

It is not a solution, until you actually _have_ an explicit 'any'
type to coerce into. Otherwise, how do you specify syntactically
a function working on the 'any' type?

Actually, the 'any' type already exists 'kind of' in TTCN-3 --
for port message definitions. There, you can use the (up till now)
_keyword_ 'all' to specify messages of _all_ types (which is
equivalent to messages of 'any' type).

Thus, I would propose to introduce the type named 'all' which is
type compatible with all other types.

Jacob Wieland - Compiler-Construction, TU-Berlin