Type Conversion in an Assignment Statement

Type Conversion in an Assignment Statement

[Carsten Freining]

Hello,

I have a problem I try to resolve with the Ada95 LRM. I have the
following lines of code:

   type IntegerAccessType is access Integer;
   subtype IntegerSubType is Integer range 1..100;
   Pointer: IntegerAccessType := new IntegerSubType;
begin
   Pointer.all :=105;
end;

This code is only to show the problem I have. It is not a real program
and it is not any recomended programming style.

This is a correct program. I thought it would raise a constraint_error,
because I created a new object of type IntegerSubType, so the
Accessvariable Pointer is accessing this specific subtype. But I can
assign any integer value to this object refered to by the pointer.

Here are my investigations so far in the Ada95 LRM:

4.8 Allocators
(3)  The expected type for an allocator shall be a single
access-to-object type whose designated type covers the type determined
by the subtype_mark of the subtype_indication or qualified_expression.

The result of the new operation is an access-to-object type. The
object-type of this accesstype shall cover the object-type of the new
created object. Since it should only cover the created object-type it is
allowed to choose the designated type larger.

(9)  If the designated type is elementary, an object of the designated
subtype is created and any implicit initial value is assigned;

Since the Designated Type is ELementary, the object has to be created
from the designated subtype. The LRM is talking about the subtype in any
case the 'type' can be assigned to a variable. Integer is first a type,
but if I want to define a variable of type integer, a general subtype of
type interger is first created. this subtype is then assigned to the
variable. This means first there is a subtype of the subtype from
integer created, the object is of type IntegerSubType.

5.2 Assignement Statement

(11)  The value of the expression is converted to the subtype of the
target. The conversion might raise an exception (see 4.6).

The Value or in this case the object Type of the AccessType will be
converted to the target type.

(13)  The value of the target becomes the converted value.

This seems the evidence, that the target of the assignment will have the
complete Type (means Object-Type of the Access-to-Object-Type).

We still want to look into 4.6 Type Conversion

And I can only find (14) and 16 here:
(14)  If the target type is an access-to-variable type, then the operand
type shall be an access-to-variable type;
(16)  If the target designated type is not tagged, then the designated
types shall be the same, and either the designated subtypes shall
statically match or the target designated subtype shall be discriminated
and unconstrained;

That is all I have found so far. I think it is already the evidence,
that the with the allocator operation new created object, of (with the
allocator) the designated type is converted into the object-type of the
Access-to-Object-Type for the access-variable that is the target of the
assignement statement. Is this correct, or did I miss something.

Regards,

Carsten Freining.


--
----------------------------------------------------------------------------

Carsten Freining

e-Mail:         freining@informatik.uni-jena.de
Tel.            03641 9 46344
Adresse:        Friedrich-Schiller-Universit�t Jena
                Fakult�t f�r Mathematik & Informatik
                Institut f�r Informatik
                Lehrstuhl f�r Programmiersprachen und Compiler
                D-07740 Jena, Germany

----------------------------------------------------------------------------

Re: [comp.lang.ada] Type Conversion in an Assignment Statement

[David C. Hoos, Sr.]

If you had declared Pointer to be an access to IntegerSubType, instead
of an Access to Integer, then constraint_error would have been raised.

Making the assignment to Pointer by means of the new operator does
not change the constraints of the access object "Pointer."
You did not create a new object with the new operator -- instead, you
assigned an access value designating a subytpe of Integer, so that
assignment is legal.

The Pointer object which was originally designating no value
(i.e. it was null), is still an access-to-Integer object.

So, the later assignment of 105 to the space designated by
Pointer is still legal.

----- Original Message -----
From: "Carsten Freining" <freining@informatik.uni-jena.de>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: June 18, 2001 3:15 AM
Subject: [comp.lang.ada] Type Conversion in an Assignment Statement


> Hello,
>
> I have a problem I try to resolve with the Ada95 LRM. I have the
> following lines of code:
>
>    type IntegerAccessType is access Integer;
>    subtype IntegerSubType is Integer range 1..100;
>    Pointer: IntegerAccessType := new IntegerSubType;
> begin
>    Pointer.all :=105;
> end;
>
> This code is only to show the problem I have. It is not a real program
> and it is not any recomended programming style.
>
> This is a correct program. I thought it would raise a constraint_error,
> because I created a new object of type IntegerSubType, so the
> Accessvariable Pointer is accessing this specific subtype. But I can
> assign any integer value to this object refered to by the pointer.
>
> Here are my investigations so far in the Ada95 LRM:
>
> 4.8 Allocators
> (3)  The expected type for an allocator shall be a single
> access-to-object type whose designated type covers the type determined
> by the subtype_mark of the subtype_indication or qualified_expression.
>
> The result of the new operation is an access-to-object type. The
> object-type of this accesstype shall cover the object-type of the new
> created object. Since it should only cover the created object-type it is
> allowed to choose the designated type larger.
>
> (9)  If the designated type is elementary, an object of the designated
> subtype is created and any implicit initial value is assigned;
>
> Since the Designated Type is ELementary, the object has to be created
> from the designated subtype. The LRM is talking about the subtype in any
> case the 'type' can be assigned to a variable. Integer is first a type,
> but if I want to define a variable of type integer, a general subtype of
> type interger is first created. this subtype is then assigned to the
> variable. This means first there is a subtype of the subtype from
> integer created, the object is of type IntegerSubType.
>
> 5.2 Assignement Statement
>
> (11)  The value of the expression is converted to the subtype of the
> target. The conversion might raise an exception (see 4.6).
>
> The Value or in this case the object Type of the AccessType will be
> converted to the target type.
>
> (13)  The value of the target becomes the converted value.
>
> This seems the evidence, that the target of the assignment will have the
> complete Type (means Object-Type of the Access-to-Object-Type).
>
> We still want to look into 4.6 Type Conversion
>
> And I can only find (14) and 16 here:
> (14)  If the target type is an access-to-variable type, then the operand
> type shall be an access-to-variable type;
> (16)  If the target designated type is not tagged, then the designated
> types shall be the same, and either the designated subtypes shall
> statically match or the target designated subtype shall be discriminated
> and unconstrained;
>
> That is all I have found so far. I think it is already the evidence,
> that the with the allocator operation new created object, of (with the
> allocator) the designated type is converted into the object-type of the
> Access-to-Object-Type for the access-variable that is the target of the
> assignement statement. Is this correct, or did I miss something.
>
> Regards,
>
> Carsten Freining.
>
>
> --
> ----------------------------------------------------------------------------
>
> Carsten Freining
>
> e-Mail:         freining@informatik.uni-jena.de
> Tel.            03641 9 46344
> Adresse:        Friedrich-Schiller-Universit�t Jena
>                 Fakult�t f�r Mathematik & Informatik
>                 Institut f�r Informatik
>                 Lehrstuhl f�r Programmiersprachen und Compiler
>                 D-07740 Jena, Germany
>
> ----------------------------------------------------------------------------
>
>
>
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
>

Re: [comp.lang.ada] Type Conversion in an Assignment Statement

[Carsten Freining]

Thank you for your Answer,

That was my first try to explain this too. The problem is to find a proof for this
within the Ada95 LRM. As you have explained it, it seems that my proof with
Chapter 5.2 (11) and (13) and Chapter 4.6 (14) and (16), where the type conversion
of the Value of the Expression to the target subtype is explained.

Thanks again,

Carsten Freining.

"David C. Hoos, Sr." schrieb:

> If you had declared Pointer to be an access to IntegerSubType, instead
> of an Access to Integer, then constraint_error would have been raised.
>
> Making the assignment to Pointer by means of the new operator does
> not change the constraints of the access object "Pointer."
> You did not create a new object with the new operator -- instead, you
> assigned an access value designating a subytpe of Integer, so that
> assignment is legal.
>
> The Pointer object which was originally designating no value
> (i.e. it was null), is still an access-to-Integer object.
>
> So, the later assignment of 105 to the space designated by
> Pointer is still legal.
>
> ----- Original Message -----
> From: "Carsten Freining" <freining@informatik.uni-jena.de>
> Newsgroups: comp.lang.ada
> To: <comp.lang.ada@ada.eu.org>
> Sent: June 18, 2001 3:15 AM
> Subject: [comp.lang.ada] Type Conversion in an Assignment Statement
>
> > Hello,
> >
> > I have a problem I try to resolve with the Ada95 LRM. I have the
> > following lines of code:
> >
> >    type IntegerAccessType is access Integer;
> >    subtype IntegerSubType is Integer range 1..100;
> >    Pointer: IntegerAccessType := new IntegerSubType;
> > begin
> >    Pointer.all :=105;
> > end;
> >
> > This code is only to show the problem I have. It is not a real program
> > and it is not any recomended programming style.
> >
> > This is a correct program. I thought it would raise a constraint_error,
> > because I created a new object of type IntegerSubType, so the
> > Accessvariable Pointer is accessing this specific subtype. But I can
> > assign any integer value to this object refered to by the pointer.
> >
> > Here are my investigations so far in the Ada95 LRM:
> >
> > 4.8 Allocators
> > (3)  The expected type for an allocator shall be a single
> > access-to-object type whose designated type covers the type determined
> > by the subtype_mark of the subtype_indication or qualified_expression.
> >
> > The result of the new operation is an access-to-object type. The
> > object-type of this accesstype shall cover the object-type of the new
> > created object. Since it should only cover the created object-type it is
> > allowed to choose the designated type larger.
> >
> > (9)  If the designated type is elementary, an object of the designated
> > subtype is created and any implicit initial value is assigned;
> >
> > Since the Designated Type is ELementary, the object has to be created
> > from the designated subtype. The LRM is talking about the subtype in any
> > case the 'type' can be assigned to a variable. Integer is first a type,
> > but if I want to define a variable of type integer, a general subtype of
> > type interger is first created. this subtype is then assigned to the
> > variable. This means first there is a subtype of the subtype from
> > integer created, the object is of type IntegerSubType.
> >
> > 5.2 Assignement Statement
> >
> > (11)  The value of the expression is converted to the subtype of the
> > target. The conversion might raise an exception (see 4.6).
> >
> > The Value or in this case the object Type of the AccessType will be
> > converted to the target type.
> >
> > (13)  The value of the target becomes the converted value.
> >
> > This seems the evidence, that the target of the assignment will have the
> > complete Type (means Object-Type of the Access-to-Object-Type).
> >
> > We still want to look into 4.6 Type Conversion
> >
> > And I can only find (14) and 16 here:
> > (14)  If the target type is an access-to-variable type, then the operand
> > type shall be an access-to-variable type;
> > (16)  If the target designated type is not tagged, then the designated
> > types shall be the same, and either the designated subtypes shall
> > statically match or the target designated subtype shall be discriminated
> > and unconstrained;
> >
> > That is all I have found so far. I think it is already the evidence,
> > that the with the allocator operation new created object, of (with the
> > allocator) the designated type is converted into the object-type of the
> > Access-to-Object-Type for the access-variable that is the target of the
> > assignement statement. Is this correct, or did I miss something.
> >
> > Regards,
> >
> > Carsten Freining.
> >
> >
> > --
> > ----------------------------------------------------------------------------
> >
> > Carsten Freining
> >
> > e-Mail:         freining@informatik.uni-jena.de
> > Tel.            03641 9 46344
> > Adresse:        Friedrich-Schiller-Universit�t Jena
> >                 Fakult�t f�r Mathematik & Informatik
> >                 Institut f�r Informatik
> >                 Lehrstuhl f�r Programmiersprachen und Compiler
> >                 D-07740 Jena, Germany
> >
> > ----------------------------------------------------------------------------
> >
> >
> >
> > _______________________________________________
> > comp.lang.ada mailing list
> > comp.lang.ada@ada.eu.org
> > http://ada.eu.org/mailman/listinfo/comp.lang.ada
> >

--
----------------------------------------------------------------------------
Carsten Freining

e-Mail:         freining@informatik.uni-jena.de
Tel.            03641 9 46344
Adresse:        Friedrich-Schiller-Universit�t Jena
                Fakult�t f�r Mathematik & Informatik
                Institut f�r Informatik
                Lehrstuhl f�r Programmiersprachen und Compiler
                D-07740 Jena, Germany

----------------------------------------------------------------------------

Re: [comp.lang.ada] Type Conversion in an Assignment Statement

[Carsten Freining]

Thank you for your Answer,

That was my first try to explain this too. The problem is to find a proof for this
within the Ada95 LRM. As you have explained it, it seems that my proof with
Chapter 5.2 (11) and (13) and Chapter 4.6 (14) and (16), where the type conversion
of the Value of the Expression to the target subtype is explained.

Thanks again,

Carsten Freining.

"David C. Hoos, Sr." schrieb:

> If you had declared Pointer to be an access to IntegerSubType, instead
> of an Access to Integer, then constraint_error would have been raised.
>
> Making the assignment to Pointer by means of the new operator does
> not change the constraints of the access object "Pointer."
> You did not create a new object with the new operator -- instead, you
> assigned an access value designating a subytpe of Integer, so that
> assignment is legal.
>
> The Pointer object which was originally designating no value
> (i.e. it was null), is still an access-to-Integer object.
>
> So, the later assignment of 105 to the space designated by
> Pointer is still legal.
>
> ----- Original Message -----
> From: "Carsten Freining" <freining@informatik.uni-jena.de>
> Newsgroups: comp.lang.ada
> To: <comp.lang.ada@ada.eu.org>
> Sent: June 18, 2001 3:15 AM
> Subject: [comp.lang.ada] Type Conversion in an Assignment Statement
>
> > Hello,
> >
> > I have a problem I try to resolve with the Ada95 LRM. I have the
> > following lines of code:
> >
> >    type IntegerAccessType is access Integer;
> >    subtype IntegerSubType is Integer range 1..100;
> >    Pointer: IntegerAccessType := new IntegerSubType;
> > begin
> >    Pointer.all :=105;
> > end;
> >
> > This code is only to show the problem I have. It is not a real program
> > and it is not any recomended programming style.
> >
> > This is a correct program. I thought it would raise a constraint_error,
> > because I created a new object of type IntegerSubType, so the
> > Accessvariable Pointer is accessing this specific subtype. But I can
> > assign any integer value to this object refered to by the pointer.
> >
> > Here are my investigations so far in the Ada95 LRM:
> >
> > 4.8 Allocators
> > (3)  The expected type for an allocator shall be a single
> > access-to-object type whose designated type covers the type determined
> > by the subtype_mark of the subtype_indication or qualified_expression.
> >
> > The result of the new operation is an access-to-object type. The
> > object-type of this accesstype shall cover the object-type of the new
> > created object. Since it should only cover the created object-type it is
> > allowed to choose the designated type larger.
> >
> > (9)  If the designated type is elementary, an object of the designated
> > subtype is created and any implicit initial value is assigned;
> >
> > Since the Designated Type is ELementary, the object has to be created
> > from the designated subtype. The LRM is talking about the subtype in any
> > case the 'type' can be assigned to a variable. Integer is first a type,
> > but if I want to define a variable of type integer, a general subtype of
> > type interger is first created. this subtype is then assigned to the
> > variable. This means first there is a subtype of the subtype from
> > integer created, the object is of type IntegerSubType.
> >
> > 5.2 Assignement Statement
> >
> > (11)  The value of the expression is converted to the subtype of the
> > target. The conversion might raise an exception (see 4.6).
> >
> > The Value or in this case the object Type of the AccessType will be
> > converted to the target type.
> >
> > (13)  The value of the target becomes the converted value.
> >
> > This seems the evidence, that the target of the assignment will have the
> > complete Type (means Object-Type of the Access-to-Object-Type).
> >
> > We still want to look into 4.6 Type Conversion
> >
> > And I can only find (14) and 16 here:
> > (14)  If the target type is an access-to-variable type, then the operand
> > type shall be an access-to-variable type;
> > (16)  If the target designated type is not tagged, then the designated
> > types shall be the same, and either the designated subtypes shall
> > statically match or the target designated subtype shall be discriminated
> > and unconstrained;
> >
> > That is all I have found so far. I think it is already the evidence,
> > that the with the allocator operation new created object, of (with the
> > allocator) the designated type is converted into the object-type of the
> > Access-to-Object-Type for the access-variable that is the target of the
> > assignement statement. Is this correct, or did I miss something.
> >
> > Regards,
> >
> > Carsten Freining.
> >
> >
> > --
> > ----------------------------------------------------------------------------
> >
> > Carsten Freining
> >
> > e-Mail:         freining@informatik.uni-jena.de
> > Tel.            03641 9 46344
> > Adresse:        Friedrich-Schiller-Universit�t Jena
> >                 Fakult�t f�r Mathematik & Informatik
> >                 Institut f�r Informatik
> >                 Lehrstuhl f�r Programmiersprachen und Compiler
> >                 D-07740 Jena, Germany
> >
> > ----------------------------------------------------------------------------
> >
> >
> >
> > _______________________________________________
> > comp.lang.ada mailing list
> > comp.lang.ada@ada.eu.org
> > http://ada.eu.org/mailman/listinfo/comp.lang.ada
> >

--
----------------------------------------------------------------------------
Carsten Freining

e-Mail:         freining@informatik.uni-jena.de
Tel.            03641 9 46344
Adresse:        Friedrich-Schiller-Universit�t Jena
                Fakult�t f�r Mathematik & Informatik
                Institut f�r Informatik
                Lehrstuhl f�r Programmiersprachen und Compiler
                D-07740 Jena, Germany

----------------------------------------------------------------------------

Re: Type Conversion in an Assignment Statement

[Ted Dennison]

In article <3B2DB8B9.1A26F90F@informatik.uni-jena.de>, Carsten Freining says...
>This is a correct program. I thought it would raise a constraint_error,

You shouldn't ever *count* on a constraint check for proper operation of your
code. They can be unexpectedly removed or moved around on the whim of the
compiler or user (via pragma suppress or a command-line parameter).

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Type Conversion in an Assignment Statement

[Carsten Freining]

Ted Dennison schrieb:

> In article <3B2DB8B9.1A26F90F@informatik.uni-jena.de>, Carsten Freining says...
> >This is a correct program. I thought it would raise a constraint_error,
>
> You shouldn't ever *count* on a constraint check for proper operation of your
> code. They can be unexpectedly removed or moved around on the whim of the
> compiler or user (via pragma suppress or a command-line parameter).

I usually wouldn't. I am the Tutor of an Ada-course. Just simple things and I
needed some Exercises for accesstypes. This Example is really interesting and
tricky, because it is not that obvious. But then, as long as there is no proof for
this in the Ada LRM it could possibly be the Compiler with a bug.
So you can't *count* on anything, without a proof that makes the facts clear. But
we don't have to teach this stuff to the next Generation, well, not from the start.

Carsten Freining.
--
----------------------------------------------------------------------------
Carsten Freining

e-Mail:         freining@informatik.uni-jena.de
Tel.            03641 9 46344
Adresse:        Friedrich-Schiller-Universit�t Jena
                Fakult�t f�r Mathematik & Informatik
                Institut f�r Informatik
                Lehrstuhl f�r Programmiersprachen und Compiler
                D-07740 Jena, Germany

----------------------------------------------------------------------------

Re: Type Conversion in an Assignment Statement

[Robert A Duff]

Carsten Freining <freining@informatik.uni-jena.de> writes:

>    type IntegerAccessType is access Integer;
>    subtype IntegerSubType is Integer range 1..100;
>    Pointer: IntegerAccessType := new IntegerSubType;
> begin
>    Pointer.all :=105;
> end;

> This is a correct program. I thought it would raise a constraint_error,

No, it will not raise C_E.  The designated subtype of IntegerAccessType
is Integer.  When you allocate with "new IntegerSubType", it does *not*
remember the bounds of IntegerSubType.  In the assignment "Pointer.all
:= 105;", it's checking that 105 is within the bounds of Integer,
not within the bounds of IntegerSubType.

This is how elementary types work.  Composite types work differently: if
you allocate an array or record on the heap, it *does* remember the
bounds or discriminants of what you allocated, and it will check that
they don't change, and raise C_E if you try.

Anyway, it's probably better to write "new Integer" above, to avoid this
confusion.

I'm too lazy to quote chapter and verse here.  If you really want to
understand the RM wording, remember that the name in a type_declaration
is the name of a subtype (the "first subtype").  A type_declaration
also creates a type, but types in Ada do not have names.  Integer and
IntegerSubType are both subtypes (of the same underlying type).  This
terminology is admittedly a bit confusing, so most people are happy to
say "the type Integer", when strictly speaking they really mean "the
type of subtype Integer".

- Bob

P.S. You ought to use the generally accepted Ada style, and call it
Integer_Access_Type, rather than IntegerAccessType.

Re: Type Conversion in an Assignment Statement

[Carsten Freining]

Thanks for your Answer.

First of all I wouldn't write such a Program in real. This Programmpart was
part of an Exercise I had to create for an Ada starter Course. Since the
moment I found out it wouldn't raise an esception as I thought I had to proof
it with the Ada LRM, since giving out an Exercise where the Compiler might be
buggy is dangerous. It would have been a great point for an excersise now,
that it has been proofen (with the Chapters I quoted in the first message). I
wasn't just sure if this is the proper proof or if I have to look further
things up.

> I'm too lazy to quote chapter and verse here.  If you really want to
> understand the RM wording, remember that the name in a type_declaration
> is the name of a subtype (the "first subtype").  A type_declaration
> also creates a type, but types in Ada do not have names.  Integer and
> IntegerSubType are both subtypes (of the same underlying type).  This
> terminology is admittedly a bit confusing, so most people are happy to
> say "the type Integer", when strictly speaking they really mean "the
> type of subtype Integer".

Yes, that is from the Rational, where this has been made clear. It is
sometimes a little confusing, but I will have to get used to it.

> P.S. You ought to use the generally accepted Ada style, and call it
> Integer_Access_Type, rather than IntegerAccessType.

That is something, where Professor Winkler has another opinion. Talkng about
a Program, the 'Underscore' is a problem. Telling somebody that Integer
'Underscore' Access 'Underscore' Type is more confusing. So he set the rule,
that the Names in the program should be without the 'underscore'. It makes
the Program a little less readable, but better 'talkable' what is for
Exercises or courses a little better to work with.
The Style is something intern, there is not the one perfect Style and well we
chose the Style without an 'underscore'. I am aware that usually if everybody
knows that the Words in an identifier are separated by an 'underscore' you
can stil talk about it and the other person will know where the 'underscore'
belongs in the identifier, but this is a departement of Programminglanguage
and Compiler, so we work with many different languages like Java, Modula3,
Pascal, C++, C, Fortran. For the course Programming languages you have to
show the differences with as many PS as possible.

Thanks again for your answer, it helped to make sure that the found Chapters
are the proof of my problem.

Carsten Freining.

--
----------------------------------------------------------------------------
Carsten Freining

e-Mail:         freining@informatik.uni-jena.de
Tel.            03641 9 46344
Adresse:        Friedrich-Schiller-Universit�t Jena
                Fakult�t f�r Mathematik & Informatik
                Institut f�r Informatik
                Lehrstuhl f�r Programmiersprachen und Compiler
                D-07740 Jena, Germany

----------------------------------------------------------------------------

Underscore Usage (was: Type Conversion in an Assignment Statement)

[Wilhelm Spickermann]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 1394 bytes --]


On 19-Jun-01 Carsten Freining wrote:
> That is something, where Professor Winkler has another opinion. Talkng about
> a Program, the 'Underscore' is a problem. Telling somebody that Integer
> 'Underscore' Access 'Underscore' Type is more confusing. So he set the rule,
> that the Names in the program should be without the 'underscore'. It makes
> the Program a little less readable, but better 'talkable' what is for
> Exercises or courses a little better to work with.

I think this is a problem depending on the language used to build the variable
names. In english you can simply say "Integer Access Type" without mentioning
underscores -- this will not cause any problems. The rule to put underscores
between words _is_ confusing using languages like german (or AFAIK swedish):
Some people will write "Programming_Language" as "Programmiersprache" and some
will write "Programmier_Sprache" -- the first one is a correct german word
(containing two words) and the second one has underscores between the words (in
swedish "Programspr�k" or "Program_Spr�k").

Personally, I like to replace blanks and hyphens by underscores but never put
additional underscores into the variable name. So we have something in common
as far as "Programmiersprache" is concerned -- but I wouldn�t write
"BesteProgrammierSprache" or "Beste_Programmier_Sprache" but
"Beste_Programmiersprache".

Wilhelm