comp.lang.ada
 help / color / mirror / Atom feed
* Does 3.9.3(10) apply to untagged private whose full view is tagged?
@ 2007-07-25 22:04 Adam Beneschan
  2007-07-26  5:08 ` AW: " Grein, Christoph (Fa. ESG)
  2007-07-26  8:58 ` anon
  0 siblings, 2 replies; 5+ messages in thread
From: Adam Beneschan @ 2007-07-25 22:04 UTC (permalink / raw)


I think the following is legal, but the version of GNAT I'm using
rejects it, citing 3.9.3(10):

package Pak1 is
   type T1 is private;
private
   type T1 is tagged record
      F1 : Integer;
  end record;
  function Func (X : Integer) return T2;
end Pak1;

3.9.3(10) says, in part, "For a tagged type declared in a visible
part, a primitive function with a controlling result shall not be
declared in the private part, unless it is overriding a function
implicitly declared in the visible part."  My interpretation, though,
is that it doesn't apply here, and that it only applies to types that
are *visibly* tagged in the visible part---not to untagged private
types whose full view is tagged.  The AARM reasoning for the rule has
to do with other packages that declare type extensions of the type
that wouldn't know that there's a private function that needs to be
overridden---but in this case, other packages (except for private
children, which have access to the entire private part of Pak1) can't
declare a type extension of T1; so it would make sense that the rule
wouldn't apply to this code.  Anyway, that's my interpretation, but it
seems within the realm of possibility to interpret it the other way.

So who's right?  Me or GNAT?

                           -- Adam




^ permalink raw reply	[flat|nested] 5+ messages in thread

* AW: Does 3.9.3(10) apply to untagged private whose full view is tagged?
  2007-07-25 22:04 Does 3.9.3(10) apply to untagged private whose full view is tagged? Adam Beneschan
@ 2007-07-26  5:08 ` Grein, Christoph (Fa. ESG)
  2007-07-26  8:58 ` anon
  1 sibling, 0 replies; 5+ messages in thread
From: Grein, Christoph (Fa. ESG) @ 2007-07-26  5:08 UTC (permalink / raw)
  To: comp.lang.ada

Adam,

I think your analysis is correct and GNAT has a bug here. Also another compiler compiles it without complaint.



Eurocopter Deutschland GmbH
Sitz der Gesellschaft/Registered Office: Donauwoerth
Registergericht/Registration Court: Amtsgericht Augsburg HRB 16508
Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: Dr. Lutz Bertling
Geschaeftsfuehrung/Board of Management:
Dr. Wolfgang Schoder, Vorsitzender/CEO; Friedrich-Wilhelm Hormel; Ralf Barnscheidt

CONFIDENTIALITY NOTICE 

This communication and the information it contains is intended for the addressee(s) named above and for no other persons or organizations. It is confidential and may be legally privileged and protected by law. The unauthorized use, copying or disclosure of this communication or any part of it is prohibited and may be unlawful. 
If you have received this communication in error, kindly notify us by return e-mail and discard and/or delete the communication. Thank you very much. 
It is possible for e-mails to be intercepted or affected by viruses. Whilst we maintain virus checks on our e-mails, we accept no liability for viruses or other material which might be introduced with this message. 
-----Ursprüngliche Nachricht-----
package Pak1 is
   type T1 is private;
private
   type T1 is tagged record
      F1 : Integer;
  end record;
  function Func (X : Integer) return T1;
end Pak1;





^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Does 3.9.3(10) apply to untagged private whose full view is tagged?
  2007-07-25 22:04 Does 3.9.3(10) apply to untagged private whose full view is tagged? Adam Beneschan
  2007-07-26  5:08 ` AW: " Grein, Christoph (Fa. ESG)
@ 2007-07-26  8:58 ` anon
  2007-07-26 10:40   ` Georg Bauhaus
  1 sibling, 1 reply; 5+ messages in thread
From: anon @ 2007-07-26  8:58 UTC (permalink / raw)


Compiling: pak1.ads (source file time stamp: 2007-07-25 03:45:40)

     1. package Pak1 is
     2.    type T1 is private ;
     3. 
     4. private
     5.    type T1 is tagged record
     6.       F1 : Integer ;
     7.   end record ;
     8.   function Func ( X : Integer ) return T2 ;
                                               |
        >>> "T2" is undefined

     9. end Pak1;
    10. 

T2 must be defined.  So, assume T2 is a typo for T1

Compiling: pak1.ads (source file time stamp: 2007-07-25 03:27:16)

     1. package Pak1 is
     2.    type T1 is private;
     3. 
     4. private
     5.    type T1 is tagged record
     6.       F1 : Integer;
     7.   end record;
     8.   function Func (X : Integer) return T1 ;
                   |
        >>> private function with tagged result must override visible-part function
        >>> move subprogram to the visible part (RM 3.9.3(10))

     9. end Pak1;
    10. 

GNAT is correct!  A better example of how to write is type 
of code is System.Storage_Pools package (RM 13.11) which 
uses the System.Storage_Elements package (RM 13.7.1).


Ada 95: RM 3.9.3 (10) says 
10   For an abstract type declared in a visible part, an abstract primitive
subprogram shall not be declared in the private part, unless it is overriding
an abstract subprogram implicitly declared in the visible part.  For a tagged
type declared in a visible part, a primitive function with a controlling
result shall not be declared in the private part, unless it is overriding a
function implicitly declared in the visible part.

In your code there is no function or abstract subprogram that is 
implicitly declared in the visible part! So the code result is a 
compiler error.


Note: AARM is for compiler developers, so it has changes which may 
or may not be valid in the L(RM). Also, since there are 3 current 
83/95/2005 specifications use should denote which version you are 
talking about. Because some things are valid in 83 that are not in 
95/2005, while others are only valid in 2005. And with GNAT 
inter-mixing specifications it can be confusing without using the 
GNAT language specifiction pragma.



In <1185401098.912519.245650@z28g2000prd.googlegroups.com>,  Adam Beneschan <adam@irvine.com> writes:
>I think the following is legal, but the version of GNAT I'm using
>rejects it, citing 3.9.3(10):
>
>package Pak1 is
>   type T1 is private;
>private
>   type T1 is tagged record
>      F1 : Integer;
>  end record;
>  function Func (X : Integer) return T2;
>end Pak1;
>
>3.9.3(10) says, in part, "For a tagged type declared in a visible
>part, a primitive function with a controlling result shall not be
>declared in the private part, unless it is overriding a function
>implicitly declared in the visible part."  My interpretation, though,
>is that it doesn't apply here, and that it only applies to types that
>are *visibly* tagged in the visible part---not to untagged private
>types whose full view is tagged.  The AARM reasoning for the rule has
>to do with other packages that declare type extensions of the type
>that wouldn't know that there's a private function that needs to be
>overridden---but in this case, other packages (except for private
>children, which have access to the entire private part of Pak1) can't
>declare a type extension of T1; so it would make sense that the rule
>wouldn't apply to this code.  Anyway, that's my interpretation, but it
>seems within the realm of possibility to interpret it the other way.
>
>So who's right?  Me or GNAT?
>
>                           -- Adam
>




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Does 3.9.3(10) apply to untagged private whose full view is tagged?
  2007-07-26  8:58 ` anon
@ 2007-07-26 10:40   ` Georg Bauhaus
  2007-07-26 15:07     ` Adam Beneschan
  0 siblings, 1 reply; 5+ messages in thread
From: Georg Bauhaus @ 2007-07-26 10:40 UTC (permalink / raw)


On Thu, 2007-07-26 at 08:58 +0000, anon wrote:

> Compiling: pak1.ads (source file time stamp: 2007-07-25 03:27:16)
> 
>      1. package Pak1 is
>      2.    type T1 is private;
>      3. 
>      4. private
>      5.    type T1 is tagged record
>      6.       F1 : Integer;
>      7.   end record;
>      8.   function Func (X : Integer) return T1 ;
>                    |
>         >>> private function with tagged result must override visible-part function
>         >>> move subprogram to the visible part (RM 3.9.3(10))
> 
>      9. end Pak1;
>     10. 

> Ada 95: RM 3.9.3 (10) says 
> ...  For a tagged
> type declared in a visible part, 

T1 is not visibly tagged nor abstract. The RM rule seems to apply
to visibly tagged types. I'd, too,  be interested in a continuation
of GNAT's first message: "must override visible-part function
for a type that is ...".







^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Does 3.9.3(10) apply to untagged private whose full view is tagged?
  2007-07-26 10:40   ` Georg Bauhaus
@ 2007-07-26 15:07     ` Adam Beneschan
  0 siblings, 0 replies; 5+ messages in thread
From: Adam Beneschan @ 2007-07-26 15:07 UTC (permalink / raw)


On Jul 26, 3:40 am, Georg Bauhaus <rm.tsoh+bauh...@maps.futureapps.de>
wrote:
> On Thu, 2007-07-26 at 08:58 +0000, anon wrote:
> > Compiling: pak1.ads (source file time stamp: 2007-07-25 03:27:16)
>
> >      1. package Pak1 is
> >      2.    type T1 is private;
> >      3.
> >      4. private
> >      5.    type T1 is tagged record
> >      6.       F1 : Integer;
> >      7.   end record;
> >      8.   function Func (X : Integer) return T1 ;
> >                    |
> >         >>> private function with tagged result must override visible-part function
> >         >>> move subprogram to the visible part (RM 3.9.3(10))
>
> >      9. end Pak1;
> >     10.
> > Ada 95: RM 3.9.3 (10) says
> > ...  For a tagged
> > type declared in a visible part,
>
> T1 is not visibly tagged nor abstract. The RM rule seems to apply
> to visibly tagged types. I'd, too,  be interested in a continuation
> of GNAT's first message: "must override visible-part function
> for a type that is ...".

The wording of GNAT's message is a bit sideways IMHO.  In general, for
a visibly tagged type, the rule is that you can't have a function with
a controlling result that returns that type in the private part; the
exception to the rule is in the case where the visible type is derived
and the function with a controlling result overrides an inherited
function.  The GNAT phrasing makes it seem like the "exceptional" case
here is the normal case, and that the mistake is not making the
function override something.  I think their message may be logically
equivalent to the real rule (using "logically equivalent" in a
mathematical sense), but the emphasis is wrong, which could cause
users to be confused.

                     -- Adam





^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2007-07-26 15:07 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-07-25 22:04 Does 3.9.3(10) apply to untagged private whose full view is tagged? Adam Beneschan
2007-07-26  5:08 ` AW: " Grein, Christoph (Fa. ESG)
2007-07-26  8:58 ` anon
2007-07-26 10:40   ` Georg Bauhaus
2007-07-26 15:07     ` Adam Beneschan

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox