Primitive Operations Question

Primitive Operations Question

[Vance Christiaanse]

Hello!

Much to my dismay, the following procedure compiles on the WebAda
(GNAT 3.04) compiler.  By my reading of RM95 3.2.3, A and B don't
fit any part of the definition of primitive operations, so I
don't see why iheritance seems to be occurring.  When I replace
all three types with a hierarchy of tagged types, both calls
fail to compile, as I would have expected.

Any insight would be much appreciated.

Thanks,

Vance Christiaanse
Cintech Consulting
cintech@ix.netcom.com


procedure Example is

  type My_Digit is range 0..7;
  procedure A (V : My_Digit);

  type New_Digit is new My_Digit;  -- is A inherited???

  procedure B (W : New_Digit);

  N : New_Digit := 1;

  type Newer_Digit is new New_Digit;  -- is B inherited???

  M : Newer_Digit := 1;

  procedure A (V : My_Digit) is
  begin
    null;
  end A;

  procedure B (W : New_Digit) is
  begin
    null;
  end B;

begin

   A(N);

   B(M);

end Example;

Re: Primitive Operations Question

[Samuel Tardieu]

>>>>> "Vance" == Vance Christiaanse <cintech@ix.netcom.com> writes:

Vance> Hello! Much to my dismay, the following procedure compiles on
Vance> the WebAda (GNAT 3.04) compiler.  By my reading of RM95 3.2.3,
Vance> A and B don't fit any part of the definition of primitive
Vance> operations, so I don't see why iheritance seems to be
Vance> occurring.  When I replace all three types with a hierarchy of
Vance> tagged types, both calls fail to compile, as I would have
Vance> expected.

The 6th paragraph on the section you cite (3.2.3):

  "For a specific type declared immediately within a
   package_specification, any subprograms (in addition to the
   enumeration literals) that are explicitly declared immediately
   within the same package_specification and that operate on the type;
  "

The only thing that bugs me is that "package_specification" is not
(from RM7.1(3)) supposed to match any declarative part.

  Sam
-- 
"La cervelle des petits enfants, ca doit avoir comme un petit gout de noisette"
                                                       Charles Baudelaire

Re: Primitive Operations Question

[Tucker Taft]

Vance Christiaanse (cintech@ix.netcom.com) wrote:


: Much to my dismay, the following procedure compiles on the WebAda
: (GNAT 3.04) compiler.  By my reading of RM95 3.2.3, A and B don't
: fit any part of the definition of primitive operations, so I
: don't see why iheritance seems to be occurring.  When I replace
: all three types with a hierarchy of tagged types, both calls
: fail to compile, as I would have expected.

: Any insight would be much appreciated.

Your reading is correct; GNAT must have a bug in this area.

Our AdaMagic front end flags both procedure calls as being in error
(see below).

: Thanks,

: Vance Christiaanse
: Cintech Consulting
: cintech@ix.netcom.com

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA
--------------------

: procedure Example is

:   type My_Digit is range 0..7;
:   procedure A (V : My_Digit);

:   type New_Digit is new My_Digit;  -- is A inherited???

:   procedure B (W : New_Digit);

:   N : New_Digit := 1;

:   type Newer_Digit is new New_Digit;  -- is B inherited???

:   M : Newer_Digit := 1;

:   procedure A (V : My_Digit) is
:   begin
:     null;
:   end A;

:   procedure B (W : New_Digit) is
:   begin
:     null;
:   end B;

: begin

:    A(N);

:    B(M);

: end Example;

-------------------- Output from AdaMagic(tm) ---------------

Source file: primprob.ada   Wed Jul 31 10:35:14 1996

  ...

   50 begin
   51 
   52    A(N);
         *
*****Error: LRM:6.4.1(3) Parameter mismatch in call, continuing
   53 
   54    B(M);
         *
*****Error: LRM:6.4.1(3) Parameter mismatch in call, continuing
   55 

 ...

Re: Primitive Operations Question

[Robert A Duff]

In article <31FE812C.7B3D@ix.netcom.com>,
Vance Christiaanse  <cintech@ix.netcom.com> wrote:
>Much to my dismay, the following procedure compiles on the WebAda
>(GNAT 3.04) compiler.  By my reading of RM95 3.2.3, A and B don't
>fit any part of the definition of primitive operations, so I
>don't see why iheritance seems to be occurring.

I agree.  Sounds like a compiler bug.

>...  When I replace
>all three types with a hierarchy of tagged types, both calls
>fail to compile, as I would have expected.

Strange.  The word "tagged" appears nowhere in the definition in of
"primitive subprogram" in 3.2.3, so it shouldn't make any difference.

- Bob

Re: Primitive Operations Question

[Vance Christiaanse]

Robert A Duff wrote:
> 
> In article <31FE812C.7B3D@ix.netcom.com>,
> Vance Christiaanse  <cintech@ix.netcom.com> wrote:
> >Much to my dismay, the following procedure compiles on the WebAda
> >(GNAT 3.04) compiler.  By my reading of RM95 3.2.3, A and B don't
> >fit any part of the definition of primitive operations, so I
> >don't see why iheritance seems to be occurring.
> 
> I agree.  Sounds like a compiler bug.
> 
> >...  When I replace
> >all three types with a hierarchy of tagged types, both calls
> >fail to compile, as I would have expected.
> 
> Strange.  The word "tagged" appears nowhere in the definition in of
> "primitive subprogram" in 3.2.3, so it shouldn't make any difference.
> 
> - Bob

Well, type extension of a tagged type in a procedure _could_ lead to
dangling references (see Rationale 4.3, package Outer).  I suspect
that's why a compiler would be more careful to prevent it.

Vance

Vance Christiaanse
Cintech Consulting
cintech@ix.netcom.com

Re: Primitive Operations Question

[Robert A Duff]

In article <31FFBFC8.32C9@ix.netcom.com>,
Vance Christiaanse  <cintech@ix.netcom.com> wrote:
>> Strange.  The word "tagged" appears nowhere in the definition in of
>> "primitive subprogram" in 3.2.3, so it shouldn't make any difference.
>> 
>> - Bob
>
>Well, type extension of a tagged type in a procedure _could_ lead to
>dangling references (see Rationale 4.3, package Outer).  I suspect
>that's why a compiler would be more careful to prevent it.

Umm, you can only create dangling refs if the derived type is more
nested than the parent type.  And this is illegal -- that's a language
rule, and has nothing to do with a particular compiler being careful.
It also has nothing to do with which subprograms are primitive.  See the
"accessibility rules".

On the other hand, it's perfectly legal to declare a root tagged type in
a procedure, and derive from it in the same procedure.  And this can't
cause dangling refs.  Of course, if you want any primitive ops, you will
need to nest packages within that procedure.  This is probably not
common -- *most* tagged types will be declared at library level.

- Bob

Re: Primitive Operations Question

[Vance Christiaanse]

Bob wrote:
> Strange.  The word "tagged" appears nowhere in the definition in of
> "primitive subprogram" in 3.2.3, so it shouldn't make any difference.

I wrote:
>Well, type extension of a tagged type in a procedure _could_ lead to
>dangling references (see Rationale 4.3, package Outer).  I suspect
>that's why a compiler would be more careful to prevent it.

Bob wrote: 
> Umm, you can only create dangling refs if the derived type is more
> nested than the parent type.  And this is illegal -- that's a language
> rule, and has nothing to do with a particular compiler being careful.
> It also has nothing to do with which subprograms are primitive.  See the
> "accessibility rules".

Right.  I wasn't thinking clearly.

Vance

Vance Christiaanse
Cintech Consulting
cintech@ix.netcom.com

Re: Primitive Operations Question

[Jon S Anthony]

In article <31FE812C.7B3D@ix.netcom.com> Vance Christiaanse <cintech@ix.netcom.com> writes:

> (GNAT 3.04) compiler.  By my reading of RM95 3.2.3, A and B don't
> fit any part of the definition of primitive operations, so I

Au contraire, see 3.2.3 in general and (6) in particular along with
3.4 in general and (17)&(23) in particular.  This sort of behavior
for non tagged types was in Ada83.


>   type My_Digit is range 0..7;
>   procedure A (V : My_Digit);
> 
>   type New_Digit is new My_Digit;  -- is A inherited???

Yes

>   procedure B (W : New_Digit);
> 
>   N : New_Digit := 1;
> 
>   type Newer_Digit is new New_Digit;  -- is B inherited???

Yes, and not only that, so is A.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Primitive Operations Question

[Jon S Anthony]

In article <DvEwtE.3Gz.0.-s@inmet.camb.inmet.com> stt@henning.camb.inmet.com (Tucker Taft) writes:

> : Much to my dismay, the following procedure compiles on the WebAda
> : (GNAT 3.04) compiler.  By my reading of RM95 3.2.3, A and B don't
> : fit any part of the definition of primitive operations, so I
> : don't see why iheritance seems to be occurring.  When I replace
> : all three types with a hierarchy of tagged types, both calls
> : fail to compile, as I would have expected.
> 
> : Any insight would be much appreciated.
> 
> Your reading is correct; GNAT must have a bug in this area.

OK, I stuck my foot in my mouth on this one.  I missed the fact that
the types are not defined in a _package specification_ so 3.2.3(6)
does not apply.  Or is there something more mysterious going on here?

BTW, I have wondered at times why there was this restriction as
opposed to allowing any operation within the same immediate scope of
the type declaration be primitive.  It does seem a little cleaner to
have these things restricted to package specs, but it is also
(paradoxically) a little more confusing.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Primitive Operations Question

[Robert A Duff]

In article <JSA.96Jul31212144@alexandria>,
Jon S Anthony <jsa@alexandria> wrote:
>...  Or is there something more mysterious going on here?

No.

>BTW, I have wondered at times why there was this restriction as
>opposed to allowing any operation within the same immediate scope of
>the type declaration be primitive. ...

If I remember correctly, the rules were slightly different in an earlier
version of Ada 9X, something along the lines of what you say.  I don't
remember all the reasons why we changed it, but here are some issues:

If you have a type declared in a package spec, you don't want to allow
adding new primitives in the body, even though spec and body together
form a single declarative region.  (The rules never allowed this, by the
way.)  This is so that the compiler can lay out the type descriptor at
compile time, and is explained in the AARM.

Allowing primitive ops in declarative parts isn't particularly useful,
so it shouldn't be allowed unless it's truly harmless.  Tagged types are
a powerful abstraction mechanism, so one would normally want to put them
in a library package spec anyway.  Also, the freezing rules don't allow
you to declare primitives using spec-less subprograms, so you need
explicit specs anyway, so it's not too onerous to require wrapping it
all in a package.  Also, the accessibility rules say that if a given
tagged type is in a procedure body, then the entire hierarchy must be in
that same procedure body, to prevent dangling references.  That is, we
never seriously considered allowing type extensions inside a procedure,
when the parent type is outside (although one distinguished reviewer did
push for that).

Although you can't declare new primitive ops except in a package spec,
you can override in a package body.  This allows, for example:

    type Whatever is new Limited_Controlled with null record;
    procedure Finalize(X: in out Whatever);
    X: Whatever;

in a library package body (without a wrapper spec).  Finalize will get
called just before program exit.

Wrapping the type and its primitives makes things look more
encapsulated, and makes it easier to find the primitives.  Note that
some folks who are used to the Eiffel or C++ way of doing things have
criticized Ada because they see even the current rule as not enough
(they want all the primitive ops to be *inside* the type/class).  I
don't really agree with that criticism, but making the rule even looser
would make that criticism a bit closer to the truth.

Ada 83 already had a notion of "derivable subprograms", which we now
call "primitive subprograms".  We wanted to keep that rule the same as
in Ada 83 for untagged types, for upward compatibility.  We wanted to
make the rules for tagged types as friendly as possible.  And we wanted
to make the rules for tagged and untagged types the same, for
uniformity.  These are conflicting goals, and we did end up changing the
rules for Ada 83 untagged types, but not as much as your suggestion
would imply (unless you suggest sacrificing uniformity between tagged
and untagged).

That's all I can think of right now.  Tucker can probably think of some
killer semantic anomoly that forced the issue.

- Bob