record extension aggregate for returned type legal?

record extension aggregate for returned type legal?

[Georg Bauhaus]

Using two different compilers, I get contradicting messages
for the following package, viz no message at all, and an
error message pointing to LRM 4.3.2(4). Which one is right?


package Ext is

   type T is tagged private;

   package B is
      function make return T;
   end B;

private
   type T is tagged record
      n: Natural;
   end record;
end Ext;



package body Ext is

   package body B is
      function make return T is
      begin
         return (T with n => 0);  -- here
         --return (n => 0);
      end make;

   end B;

end Ext;


-- TIA, georg

Re: record extension aggregate for returned type legal?

[Martin Krischik]

Georg Bauhaus wrote:

> Using two different compilers, I get contradicting messages
> for the following package, viz no message at all, and an
> error message pointing to LRM 4.3.2(4). Which one is right?
> 
> 
> package Ext is
> 
>    type T is tagged private;
> 
>    package B is
>       function make return T;
>    end B;
> 
> private
>    type T is tagged record
>       n: Natural;
>    end record;
> end Ext;
> 
> 
> 
> package body Ext is
> 
>    package body B is
>       function make return T is
>       begin
>          return (T with n => 0);  -- here

This syntax is for child classes which first initialise there parent class
and then there own data. Like in:

return Child'(Parent with n=> 0);

>          --return (n => 0);

Should that not be

      return T'(n => 0);

?

>       end make;
> 
>    end B;
> 
> end Ext;
> 

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: record extension aggregate for returned type legal?

[Georg Bauhaus]

Martin Krischik <krischik@users.sourceforge.net> wrote:
: Georg Bauhaus wrote:

:> package body Ext is
:> 
:>    package body B is
:>       function make return T is
:>       begin
:>          return (T with n => 0);  -- here
: 
: This syntax is for child classes which first initialise there parent class
: and then there own data.

Yes, but one compiler finds no fault with the line in question,
the other says No.

: 
:>          --return (n => 0);
: 
: Should that not be
: 
:      return T'(n => 0);

Same as (n => 0) in return expression?

Re: record extension aggregate for returned type legal?

[Georg Bauhaus]

Martin Krischik <krischik@users.sourceforge.net> wrote:
: T' (spoken T kick) tells the compiler that the next expression is of type T.
: i.E: Positive'(1) means that you want a Positive and not an Integer. If you
: won't say anything the compiler will choose automaticly.

In this case T is specific, and `make` is not a primitive operation
of T (because make is in child package B). So does the compiler
have a choice at all?

LRM 4.3.2, quoted in one compiler's error message, says,

  4. The expected type for an extension_aggregate shall be a single
     nonlimited type that is a record extension. If the ancestor_part
     is an expression, it is expected to be of any nonlimited tagged
     type.

Do I understand this phrase? The expected type in the return expression
for "function make return T" is the specific tagged type T.
In "return (n => 0)", there is no extension aggregate.
In "return (T with n => 0)", there is an extension aggregate,
the ancestor part being T.

T is not limited.
T is not an extension (a record extension?).
Does T have an ancestor (does T maybe count as an ancestor of T here?)


-- Georg

Re: record extension aggregate for returned type legal?

[Martin Krischik]

Georg Bauhaus wrote:

> Martin Krischik <krischik@users.sourceforge.net> wrote:
> : T' (spoken T kick) tells the compiler that the next expression is of
> : type T. i.E: Positive'(1) means that you want a Positive and not an
> : Integer. If you won't say anything the compiler will choose automaticly.
> 
> In this case T is specific, and `make` is not a primitive operation
> of T (because make is in child package B). So does the compiler
> have a choice at all?
> 
> LRM 4.3.2, quoted in one compiler's error message, says,
> 
>   4. The expected type for an extension_aggregate shall be a single
>      nonlimited type that is a record extension. If the ancestor_part
>      is an expression, it is expected to be of any nonlimited tagged
>      type.
> 
> Do I understand this phrase? The expected type in the return expression
> for "function make return T" is the specific tagged type T.
> In "return (n => 0)", there is no extension aggregate.
> In "return (T with n => 0)", there is an extension aggregate,
> the ancestor part being T.

But T in your example is a root class and therefore has no ancestor. T needs
an standart aggregate and not an extension aggregate.

> T is not limited.
> T is not an extension (a record extension?).
> Does T have an ancestor (does T maybe count as an ancestor of T here?)

Consider the other constructor pattern:

type P is abstract tagged private;
type C is new P with private;

function Create returns P'Class;

function Create
returns
    P'Class
is
begin
    return C'(P with ...);
end Create

With Regards.

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Is T an ancestor of T?

[Georg Bauhaus]

Bj�rn Persson <spam-away@nowhere.nil> wrote:

: - AARM 4.3.2(5)

Thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17985

-- Georg

Re: Is T an ancestor of T? (was: Re: record extension aggregate for returned type legal?)

[Martin Krischik]

Georg Bauhaus wrote:

> Martin Krischik <krischik@users.sourceforge.net> wrote:
> : Georg Bauhaus wrote:
> : 
> :> LRM 4.3.2, quoted in one compiler's error message, says,
> :> 
> :>   4. The expected type for an extension_aggregate shall be a single
> :>      nonlimited type that is a record extension. If the ancestor_part
> :>      is an expression, it is expected to be of any nonlimited tagged
> :>      type.
> :> 
> :> Do I understand this phrase? The expected type in the return expression
> :> for "function make return T" is the specific tagged type T.
> :> In "return (n => 0)", there is no extension aggregate.
> :> In "return (T with n => 0)", there is an extension aggregate,
> :> the ancestor part being T.
> : 
> : But T in your example is a root class and therefore has no ancestor.
> 
> T seems to have an ancestor, by the following statement form LRM
> 3.4.1(10): "A specific type T2 is defined to be a descendant of a type T1
> if T2 is the same as T1, or if T2 is derived (directly or indirectly) from
> T1."

Wow. Would not have thought that.

> So T can be T's ancestor (that's different from what I was used to
> in the real world ;-).

Well thinking about it: It's probably needed for dispatching calls.
 
> 'class as return type of constructor functions creates a number of
> not-so-nice conversion necessities that I'd like to avoid.

I thought as an example. Not to actually use this constructor pattern. 

> All issues are easily avoided using the constructor child package
> pattern.

If it suits your problem best.
 
> Now is GNAT right,
>  accepting return (T with n => 0), and
>  accepting return (n => 0)
> or is ObjectAda right,
>  rejecting return (T with n => 0), but
>  accepting return (n => 0)
> where T is the expected tagged return type (not classwide)?

I thing Object Ada is right. The aggregate allows you to move up the the
tree. i.E.

type R is tagged private;
type P  is new R with private;
type C is new P with private;

X : C := (R with P_Attribute => ..., C_Attribute => ...)

R is default initialised. P and C are specified. Now, if you move that line
of thought into the other direction you have just defined n twice. Look:

return (T with n => 0)

T is allready default initialised - and then you specify n again.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Is T an ancestor of T?

[Martin Krischik]

Georg Bauhaus wrote:

> Martin Krischik <krischik@users.sourceforge.net> wrote:
>  
> :> 'class as return type of constructor functions creates a number of
> :> not-so-nice conversion necessities that I'd like to avoid.
> : 
> : I thought as an example. Not to actually use this constructor pattern.
> 
> Interestingly, GNAT complains if T is derived from some other
> type Base. For example,
> 
>       function Make return T'Class is
>       begin
>          return T'(T with N => 42);
>       end Make;
> 
> 
>      7.          return T'(T with N => 42);
>                            |
>         >>> expect ancestor type of "T"
> 
> (Same for specific T.)

Well T is not an ancestor of T. T is T itself. You might want try the
example with a tagged type which actually has a parent to see the
difference.

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Is T an ancestor of T?

[Georg Bauhaus]

Martin Krischik <krischik@users.sourceforge.net> wrote:
: Georg Bauhaus wrote:
: 
:> Martin Krischik <krischik@users.sourceforge.net> wrote:
:>  
:> :> 'class as return type of constructor functions creates a number of
:> :> not-so-nice conversion necessities that I'd like to avoid.
:> : 
:> : I thought as an example. Not to actually use this constructor pattern.
:> 
:> Interestingly, GNAT complains if T is derived from some other
:> type Base. For example,
:> 
:>       function Make return T'Class is
:>       begin
:>          return T'(T with N => 42);
:>       end Make;
:> 
:> 
:>      7.          return T'(T with N => 42);
:>                            |
:>         >>> expect ancestor type of "T"
:> 
:> (Same for specific T.)
: 
: Well T is not an ancestor of T.

Not in this example where it is derived from another type, named Base.

: T is T itself. You might want try the
: example with a tagged type which actually has a parent to see the
: difference.

This is exactly what I have been doing, the results above are
for a T that is derived from another type, named Base.
In this GNAT spits out this error message. Otherwise it doesn't.

I still don't know whether or not a type is an ancestor of itself,
given that it is a descendant of itself.


-- Georg

Re: Is T an ancestor of T?

[Martin Krischik]

Georg Bauhaus wrote:

> I still don't know whether or not a type is an ancestor of itself,
> given that it is a descendant of itself.

Well we discussed it long enough here and if you really want to know then
there is only one option left. A mail to:

ada-comment@ada-auth.org

This is the mail address of the Ada Authority. If they don't know knowbody
does. (Please note: While Ada Authority is open "for question from the
general public" one should allways ask at comp.lang.ada first).

Don't foreget to subscribe as well otherwise you will never see the answer:

listserv@ada-auth.org

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: record extension aggregate for returned type legal?

[Jean-Pierre Rosen]

Martin Krischik a écrit :

> i.E. "return (0)" might not work since the compiler could to choose
> Integer'(0). However T'(0) will work. You need to be a language lawyer to
> know what works and what does not. Normal people will have to experiment or
> just write down the T' all the time ;-). 
> 
Normal people trust the compiler, and just try it.

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: record extension aggregate for returned type legal?

[Martin Krischik]

Samuel Tardieu wrote:

>>>>>> "Jean-Pierre" == Jean-Pierre Rosen <rosen@adalog.fr> writes:
> 
> Jean-Pierre> Normal people trust the compiler, and just try it.
> 
> You're kidding, right? I can't believe you encourage people to code
> this way, by changing the code at random until it works.

Well in Ada thats quite Ok. If you do something syntacticly silly the
compiler will shout at you.

We where talking about syntax details here here. The use of "return
(n=> ...)" compared to "return T'(n => ...) ". Which is better which isn't.

And in Ada experiments like this give you an compiler error and not faulty
code like in some other languages ;-) .

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: record extension aggregate for returned type legal?

[Georg Bauhaus]

Jean-Pierre Rosen <rosen@adalog.fr> wrote:
 
: Unless I missed something, this thread was about *legality rules*.
: And yes, I find more efficient to ask the compiler rather than dig into 
: the ARM.

In the case of (T with T_Component => value) GNAT's answer
contradicts ObjectAda's answer if T is at the root of a hierarchy of
tagged types.


-- Georg

Re: record extension aggregate for returned type legal?

[Simon Wright]

Martin Krischik <krischik@users.sourceforge.net> writes:

> T' (spoken T kick)
               ^^^^  tick, surely?

Re: Is T an ancestor of T?

[Christoph Karl Walter Grein]

From: Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de>

> I still don't know whether or not a type is an ancestor of itself,
> given that it is a descendant of itself.

Looking into RM Index for ancestor, you'll find the reference to RM 3.4.1(10) with the definition of ancestor and descendant:
________________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt neu bei WEB.DE FreeMail: http://freemail.web.de/?mc=021193

Re: Is T an ancestor of T?

[Georg Bauhaus]

Christoph Karl Walter Grein <AdaMagica@web.de> wrote:
: From: Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de>
: 
:> I still don't know whether or not a type is an ancestor of itself,
:> given that it is a descendant of itself.
: 
: Looking into RM Index for ancestor, you'll find the reference to RM 3.4.1(10) with the definition of ancestor and descendant:

Yes, descendant seem clearly defined in this paragraph. However,
"The ultimate ancestor of a type is the
 ancestor of the type that is not a descendant of any other type."

(In the original example, there was a new tagged private type T
and an aggregate T'(T with n => ) which is o.K. by GNAT, not o.K.
by Object Ada. When T is derive via new from some tagged T0,
both compilers agree again.)

What is "any other type"? Likely it means any type other than the
descendant (which can be a descendant of itself according to the
first sentence of 3.4.1(10))? So by the descendant wording,

   T0 ==> {T0, T1, T1', T2, ...}.

Which of T0, ... is not a descendant of any other type?
And is an ultimate ancestor listed in the line above when ancestor
is "the reverse" of descendant?
That is too tricky for me :-)

-- Georg

Re: Is T an ancestor of T?

[Björn Persson]

Georg Bauhaus wrote:
> Christoph Karl Walter Grein <AdaMagica@web.de> wrote:
> : From: Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de>
> : 
> :> I still don't know whether or not a type is an ancestor of itself,
> :> given that it is a descendant of itself.
> : 
> : Looking into RM Index for ancestor, you'll find the reference to RM 3.4.1(10) with the definition of ancestor and descendant:
> 
> Yes, descendant seem clearly defined in this paragraph.

Then I'd say "ancestor" is also clearly defined: "If a type T2 is a 
descendant of a type T1, then T1 is called an ancestor of T2." So if T 
is a descendant of T, then T is an ancestor of T.

> However,
> "The ultimate ancestor of a type is the
>  ancestor of the type that is not a descendant of any other type."

The one ancestor that isn't a descendant of any type other than itself, 
that is, the one that isn't derived, is the ultimate ancestor. At least 
that's how I read that.

Are you reading the annotated or non-annotated manual? The annotated one 
has a lot more to say about this, including some examples:

10
A specific type T2 is defined to be a descendant of a type T1 if T2 is 
the same as T1, or if T2 is derived (directly or indirectly) from T1. A 
class-wide type T2'Class is defined to be a descendant of type T1 if T2 
is a descendant of T1. Similarly, the universal types are defined to be 
descendants of the root types of their classes. If a type T2 is a 
descendant of a type T1, then T1 is called an ancestor of T2. The 
ultimate ancestor of a type is the ancestor of the type that is not a 
descendant of any other type.

10.a
Ramification: A specific type is a descendant of itself. Class-wide 
types are considered descendants of the corresponding specific type, and 
do not have any descendants of their own.

10.b
A specific type is an ancestor of itself. The root of a derivation class 
is an ancestor of all types in the class, including any class-wide types 
in the class.

10.c
Discussion: The terms root, parent, ancestor, and ultimate ancestor are 
all related. For example:

10.d
     * Each type has at most one parent, and one or more ancestor types; 
each type has exactly one ultimate ancestor. In Ada 83, the term 
``parent type'' was sometimes used more generally to include any 
ancestor type (e.g. RM83-9.4(14)). In Ada 95, we restrict parent to mean 
the immediate ancestor.

10.e
     * A class of types has at most one root type; a derivation class 
has exactly one root type.

10.f
     * The root of a class is an ancestor of all of the types in the 
class (including itself).

10.g
     * The type root_integer is the root of the integer class, and is 
the ultimate ancestor of all integer types. A similar statement applies 
to root_real.

-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: Is T an ancestor of T?

[Georg Bauhaus]

Bj�rn Persson <spam-away@nowhere.nil> wrote:
: Georg Bauhaus wrote:

: 
: Then I'd say "ancestor" is also clearly defined: "If a type T2 is a 
: descendant of a type T1, then T1 is called an ancestor of T2." So if T 
: is a descendant of T, then T is an ancestor of T.
: 

So far so good. As a tree has a root at one and and 
trees at the other ends (so there is no end)
the definition cannot be mirrored so to speak.

:> However,
:> "The ultimate ancestor of a type is the
:>  ancestor of the type that is not a descendant of any other type."
: 
: The one ancestor that isn't a descendant of any type other than itself, 
: that is, the one that isn't derived, is the ultimate ancestor. At least 
: that's how I read that.

Yes, I think that too, but I don't see it in either in the RM nor in the
AARM sentences you quoted. (Which of course means I must be missing
something.)

: 10.b
: A specific type is an ancestor of itself.

o.K.

: 10.c
: Discussion: The terms root, parent, ancestor, and ultimate ancestor are 
: all related. For example:
: 
: 10.d
:     * Each type has at most one parent, and one or more ancestor types; 
: each type has exactly one ultimate ancestor.

So we know there is exactly one ultimate ancestor for each type T.
If T is at the root of a derivation hierarchy of height 0,
is there a named type that is the ultimate ancestor of T?
Is it T? By 10.d I would say yes. By the last sentence of (10),
the ultimate ancestor (T) "is not a descendant of any other type".
So if T is the ultimate ancestor, it is not a descendant of T.
Which it is by the first sentence of (10).
I must be missing something. Specific types?

Then if D is new T with ..., is T the ultimate ancestor of D?
(Again I would agree that it is.)

If T is the ultimate ancestor of T (and T is the ultimate
ancestor of D if D had been defined), can GNAT be right when
(T with n => 0) is accepted as an extension aggregate of specific
type T? I still don't think so.

 (type T is tagged record
     n: Natural;
  end record;)

Re: Is T an ancestor of T?

[Björn Persson]

Georg Bauhaus wrote:

> So we know there is exactly one ultimate ancestor for each type T.
> If T is at the root of a derivation hierarchy of height 0,
> is there a named type that is the ultimate ancestor of T?
> Is it T? By 10.d I would say yes.

Yes.

> By the last sentence of (10),
> the ultimate ancestor (T) "is not a descendant of any other type".
> So if T is the ultimate ancestor, it is not a descendant of T.
> Which it is by the first sentence of (10).
> I must be missing something. Specific types?

Maybe it's the word "other" you're missing? If it read "not a descendant 
of any type", then there would be a contradiction as you say, but it 
reads "not a descendant of any *other* type". "Other" must mean "other 
than itself".

> Then if D is new T with ..., is T the ultimate ancestor of D?
> (Again I would agree that it is.)

Yes.

> If T is the ultimate ancestor of T (and T is the ultimate
> ancestor of D if D had been defined), can GNAT be right when
> (T with n => 0) is accepted as an extension aggregate of specific
> type T? I still don't think so.

Me neither.

By the way, did you notice that class-wide types aren't ancestors or 
descendants of themselves?

-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: Is T an ancestor of T?

[Georg Bauhaus]

Bj�rn Persson <spam-away@nowhere.nil> wrote:
: Georg Bauhaus wrote:
: 
:> So we know there is exactly one ultimate ancestor for each type T.
:> If T is at the root of a derivation hierarchy of height 0,
:> is there a named type that is the ultimate ancestor of T?
:> Is it T? By 10.d I would say yes.
: 
: Yes.
: 
:> By the last sentence of (10),
:> the ultimate ancestor (T) "is not a descendant of any other type".
:> So if T is the ultimate ancestor, it is not a descendant of T.
:> Which it is by the first sentence of (10).
:> I must be missing something. Specific types?
: 
: Maybe it's the word "other" you're missing?

I don't speak English.  Is there a mix of defined (linguistic)
"ambiguity" (T descends from itself) and assumed clarity of "other"
in this paragraph? (Is there a well defined mathematical meaning of
"other" in general, not just in paragraph 3.4.1(10)? What is the set
of "not any other types"?)

Adding to the quote from Douglas Adams about the descendence
issue, here is one that I remembered when I thought about
"other" once more. It is by M. Kline, and is quoted in some other
book, so I don't know the reference details.

"When a twelfth century youth fell in love he did not take three paces
backward, gaze into her eyes, and tell her she was too beautiful to
live.  He said he would step outside and see about it.  And if, when
he got out, he met a man and broke his head--the other man's head, I
mean--then that proved that his--the firsts fellow's--girl was a
pretty girl. But if the other fellow broke _his_ head--not his own,
you know, but the other fellow's--the other fellow to the second
fellow, that is, because of course the other fellow would only be the
other fellow to him, not the first fellow who--well if he broke his
head, then _his_ girl--not the other fellow's, but the fellow who was
the--Look here, if A broke B's head, then A's girl was a pretty girl;
but if B broke A's head, then A's girl wasn't a pretty girl, but B's
girl was."

I think the issue (or my problem if you wish) might have to do with the
non-natural semantics of mathematical usage (descendant of self etc ...).
Here is one that has caused headaches many times (it's even reported
in well know standard works of math "basics", like in Halmos'). "It"
has also caused an internal assertion failure in ObjectAda when I
"misspelled" part of the following procedure, writing some text that
was not an extension aggregate ;-)
In one of my favorite programming books the authors tell their readers
that a datatype shish_kebab =
Skewer
| Onion of shish_kebab
| Lamb of shish_kebab
| Tomato of shish_kebab.

They go on that if you have just a Skewer, there are only Onions on
this particular shish_kebab which is just a Skewer. Well... There are
no Onions at all and therefore there are only Onions on a shish_kebab?
(Felleisen/Friedman, The Little MLer, Sec. 2) Anyway,


with Answer;  use Answer;

procedure answer_test is

begin

   if
     true = only_onions(Skewer'
                        (null record)) and

     true = only_onions(Onion'
                        (on => new Skewer)) and

     not true = only_onions(Lamb'
                            (on => new Skewer)) and

     not true = only_onions(Onion'
                            (on => new Lamb'
                             (on => new Onion'
                              (on => new Skewer))))
   then
      raise Mathematical_Reasoning;
   end if;

end answer_test;



package Answer is


   type Skewer is tagged null record;
   type Shish_Kebab is access all Skewer'class;

   function only_onions (s: Skewer) return Boolean;

   type Onion (on: Shish_Kebab) is new Skewer with null record;
   function only_onions (s: Onion) return Boolean;

   type Lamb (on: Shish_Kebab) is new Skewer with null record;
   function only_onions (s: Lamb) return Boolean;

   type Tomato (on: Shish_Kebab) is new Skewer with null record;
   function only_onions (s: Tomato) return Boolean;

end Answer;


package body Answer is


   function only_onions (s: Skewer) return Boolean is
   begin
      return true;
   end only_onions;


   function only_onions (s: Onion) return Boolean is
   begin
      return only_onions(s.on.all);
   end only_onions;


   function only_onions (s: Lamb) return Boolean is
   begin
      return false;
   end only_onions;


   function only_onions (s: Tomato) return Boolean is
   begin
      return false;
   end only_onions;

end Answer;

-- Georg Bauhaus

 
: By the way, did you notice that class-wide types aren't ancestors or 
: descendants of themselves?

Yes, and class-wide types don't have parents or ancestors at all,
do they?

Re: Is T an ancestor of T?

[Björn Persson]

Georg Bauhaus wrote:
> Björn Persson <spam-away@nowhere.nil> wrote:
> : Georg Bauhaus wrote:
> : 
> :> By the last sentence of (10),
> :> the ultimate ancestor (T) "is not a descendant of any other type".
> :> So if T is the ultimate ancestor, it is not a descendant of T.
> :> Which it is by the first sentence of (10).
> :> I must be missing something. Specific types?
> : 
> : Maybe it's the word "other" you're missing?
> 
> I don't speak English.  Is there a mix of defined (linguistic)
> "ambiguity" (T descends from itself) and assumed clarity of "other"
> in this paragraph? (Is there a well defined mathematical meaning of
> "other" in general, not just in paragraph 3.4.1(10)? What is the set
> of "not any other types"?)

Oh come on! I'm sure German has the same construct. "Other" implies 
"other than X", and X has got to be mentioned or otherwise apparent from 
the context. The sentence is as follows:

"The ultimate ancestor of a type is the ancestor of the type that is not 
a descendant of any other type."

There are two types mentioned that are possible candidates for X. One, 
T1, is being defined as "the ultimate ancestor". The other, T2, is 
spoken of as "a type" and "the type". It is stated that T1 is an 
ancestor of T2, which means that T2 is a descendant of T1. It is also 
stated that T1 is not a descendant of any type except X. So which of T1 
and T2 is X?

If T1 and T2 are the same type, then they are both X, and the sentence 
says that the ultimate ancestor T of a type T is the ancestor T of the 
type T that is not a descendant of any type except T. No problem.

If T1 and T2 are not the same, and T1 is X, then it says that in order 
to be the ultimate ancestor, T1 must not be a descendant of any type 
except T1. That is, "other" means "other than itself".

If T1 and T2 are not the same, and T2 is X, then it says that in order 
to be the ultimate ancestor, T1 must not be a descendant of any type 
except T2. But T1 is an ancestor of T2 so it can't be a descendant of 
T2, and then T1 isn't allowed to be a descendant of any type at all. Not 
  only does this cause a contradiction, but it's also terribly 
convoluted. Why would anyone write "any other type" if "any type" would 
mean the same thing? Obviously they don't mean that T2 is X.

> : By the way, did you notice that class-wide types aren't ancestors or 
> : descendants of themselves?
> 
> Yes, and class-wide types don't have parents or ancestors at all,
> do they?

Yes they have. T is an ancestor of T'Class. I'd assume it's the parent 
too, but I haven't found a proof for that.

-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: Is T an ancestor of T?

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3125 bytes --]

It's nice to see other people doing language-laywering. :-)
Bjorn's interpretation is exactly right. Note that the meaning of words in
the standard is the same as their conventional English meaning if they are
not otherwise defined, and that certainly applies to "other".

              Randy Brukardt.

"Bj�rn Persson" <spam-away@nowhere.nil> wrote in message
news:g2wed.6882$d5.58654@newsb.telia.net...
Georg Bauhaus wrote:
> Bj�rn Persson <spam-away@nowhere.nil> wrote:
> : Georg Bauhaus wrote:
> :
> :> By the last sentence of (10),
> :> the ultimate ancestor (T) "is not a descendant of any other type".
> :> So if T is the ultimate ancestor, it is not a descendant of T.
> :> Which it is by the first sentence of (10).
> :> I must be missing something. Specific types?
> :
> : Maybe it's the word "other" you're missing?
>
> I don't speak English.  Is there a mix of defined (linguistic)
> "ambiguity" (T descends from itself) and assumed clarity of "other"
> in this paragraph? (Is there a well defined mathematical meaning of
> "other" in general, not just in paragraph 3.4.1(10)? What is the set
> of "not any other types"?)

Oh come on! I'm sure German has the same construct. "Other" implies
"other than X", and X has got to be mentioned or otherwise apparent from
the context. The sentence is as follows:

"The ultimate ancestor of a type is the ancestor of the type that is not
a descendant of any other type."

There are two types mentioned that are possible candidates for X. One,
T1, is being defined as "the ultimate ancestor". The other, T2, is
spoken of as "a type" and "the type". It is stated that T1 is an
ancestor of T2, which means that T2 is a descendant of T1. It is also
stated that T1 is not a descendant of any type except X. So which of T1
and T2 is X?

If T1 and T2 are the same type, then they are both X, and the sentence
says that the ultimate ancestor T of a type T is the ancestor T of the
type T that is not a descendant of any type except T. No problem.

If T1 and T2 are not the same, and T1 is X, then it says that in order
to be the ultimate ancestor, T1 must not be a descendant of any type
except T1. That is, "other" means "other than itself".

If T1 and T2 are not the same, and T2 is X, then it says that in order
to be the ultimate ancestor, T1 must not be a descendant of any type
except T2. But T1 is an ancestor of T2 so it can't be a descendant of
T2, and then T1 isn't allowed to be a descendant of any type at all. Not
  only does this cause a contradiction, but it's also terribly
convoluted. Why would anyone write "any other type" if "any type" would
mean the same thing? Obviously they don't mean that T2 is X.

> : By the way, did you notice that class-wide types aren't ancestors or
> : descendants of themselves?
>
> Yes, and class-wide types don't have parents or ancestors at all,
> do they?

Yes they have. T is an ancestor of T'Class. I'd assume it's the parent
too, but I haven't found a proof for that.

--
Bj�rn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu