Simple Question 3

Simple Question 3

[Stephen Cole]

Hi

Question 3.....

package MyTstTypes is
   type MyRcd is tagged
      record
         a: Integer;
         b: Float;
      end record;

   function Unit return MyRcd;

   type MyNewRcd is new MyRcd with
      record
         c: Integer;
      end record;

--   function Unit return MyNewRcd;

   type MyNewRcd2 is new MyNewRcd with
      record
         d: Float;
      end record;

end MyTstTypes;

The compiler complains with the following text....

"mytsttypes.ads:10:09: type must be declared abstract or "Unit" overridden"

It wants me to define a version of Unit() for each derived type?! Why?

Re: Simple Question 3

[tmoran]

>  function Unit return MyRcd;
>
>  type MyNewRcd is new MyRcd with
>     record
>        c: Integer;
>     end record;
>...
>It wants me to define a version of Unit() for each derived type?! Why?
  X : MyNewRcd;
begin
  X := Unit;
question: what is the value of X.c?

Re: Simple Question 3

[Stephen Cole]

I would have thought that the compiler should just through the assignment X
:= Unit() out, because it does not statically match. I do not see why the
compiler has the right to demand you write a Unit() function for the derived
type. Is there a deeper reason why it does?

<tmoran@acm.org> wrote in message
news:pepx7.4767$gT6.3058598@news1.rdc1.sfba.home.com...
> >  function Unit return MyRcd;
> >
> >  type MyNewRcd is new MyRcd with
> >     record
> >        c: Integer;
> >     end record;
> >...
> >It wants me to define a version of Unit() for each derived type?! Why?
>   X : MyNewRcd;
> begin
>   X := Unit;
> question: what is the value of X.c?

Re: Simple Question 3

[tmoran]

> >   X := Unit;
> > question: what is the value of X.c?
> I would have thought that the compiler should just through the assignment X
> := Unit() out, because it does not statically match.
  The compiler does indeed "throw out" the assignment statement.  It gives
you an error message saying it won't accept it.

> I do not see why the compiler has the right to demand you write a Unit()
> function for the derived type.  Is there a deeper reason why it does?
  The function Unit supplies values for everything in X except X.c
(the extension part).  The compiler thus has no way of knowing what
value it's supposed to give to X.c in the assignment.  Perhaps in
some languages the compiler would go ahead and let X.c take some
random value, but an Ada compiler is more helpful than that and tells
you that you are asking for garbage.  An Ada compiler is not a
dumb tool, like a hammer that can be used just as well on a thumb
as on a nail.  An Ada compiler is an assistant who helps you find
errors and won't deliver hammer blows to your thumb.

Re: Simple Question 3

[Jean-Marc Bourguet]

Stephen Cole wrote:
> 
> I would have thought that the compiler should just through the assignment X
> := Unit() out, because it does not statically match. I do not see why the
> compiler has the right to demand you write a Unit() function for the derived
> type. Is there a deeper reason why it does?

I think you did not understood what you did.  You created Unit as a primitive
operations of a tagged type which returns a value of this type.  The rules of
Ada imply that all non abstract derived types have to override the definition
of this function.

You probably didn't want to declare a primitive operation.  There are two
solutions: return a classwide type (so it will not return a value of the
type) or declare the function in another package (so it will not be a
primitive operation).

Declaring it in a nested package and providing a renaming will give you what
you though you had declared .

-- Jean-Marc

Re: Simple Question 3

[David C. Hoos]

----- Original Message -----
From: "Stephen Cole" <s_k_cole@yahoo.com>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: Thursday, October 11, 2001 9:28 AM
Subject: Simple Question 3


> Hi
>
> Question 3.....
>
> package MyTstTypes is
>    type MyRcd is tagged
>       record
>          a: Integer;
>          b: Float;
>       end record;
>
>    function Unit return MyRcd;
>
>    type MyNewRcd is new MyRcd with
>       record
>          c: Integer;
>       end record;
>
> --   function Unit return MyNewRcd;
>
>    type MyNewRcd2 is new MyNewRcd with
>       record
>          d: Float;
>       end record;
>
> end MyTstTypes;
>
> The compiler complains with the following text....
>
> "mytsttypes.ads:10:09: type must be declared abstract or "Unit"
overridden"
>
> It wants me to define a version of Unit() for each derived type?! Why?
>
Since the function Unit return MyRcd is not classwide, it can only return
values
of the type MyRcd.  If, instead, it were declared as
function Unit return MyRcd'Class, then it would be a classwide function
and it would return values of the type of the variable to which the function
result was being assigned, and the compiler would not complain.

Re: Simple Question 3

[Stephen Cole]

"Stephen Cole" <s_k_cole@yahoo.com> wrote in message
news:9q49v5$6dj$1@trog.dera.gov.uk...
> Hi
>
> Question 3.....
>
> package MyTstTypes is
>    type MyRcd is tagged
>       record
>          a: Integer;
>          b: Float;
>       end record;
>
>    function Unit return MyRcd;
>
>    type MyNewRcd is new MyRcd with
>       record
>          c: Integer;
>       end record;
>
> --   function Unit return MyNewRcd;
>
>    type MyNewRcd2 is new MyNewRcd with
>       record
>          d: Float;
>       end record;
>
> end MyTstTypes;
>
> The compiler complains with the following text....
>
> "mytsttypes.ads:10:09: type must be declared abstract or "Unit"
overridden"
>
> It wants me to define a version of Unit() for each derived type?! Why?
>
>

Look....people...my confusion is deeper than that. Its about this whole
question of what a primitive operation is! Is it a function/procedure which
takes a derived type parameter and/or returns a derived type? Or is it just
functions which return a derived type only? Or what? The rules seem a bit
fuzzy and inconsistent here. Why does returning a derived type seem to have
more rules about what must be later declared in a derived type, than
function/procedures that just take that derived type as a parameter?

Example
Look at the following code....

package MyTest is

   type MyTestType1 is tagged
      record
         a: Integer;
         b: Float;
      end record;

   function UnitA(a: MyTestType1) return Integer;
   function UnitB(a: MyTestType1) return MyTestType1;
   function UnitC return MyTestType1;

   type MyTestType2 is new MyTestType1 with
      record
         c: Integer;
      end record;

end MyTest;

UnitA() does not get flagged by the compiler as needing to be declared for
MyTestType2. But UnitB() and UnitC() do! But they all hold enough type
information for the compiler to be "intelligent" enough to know where static
matching takes place or not. The way the compiler is behaving, its as if it
only takes into account "out" parameters and does not care what "in"
parameters look like. My case is futher confussed by the use of class wide
types. But I'll come back to that if you can answer this static-only case
for me first.

Thanks.

Re: Simple Question 3

[Vincent Marciante]

I don't remember the RM paragraph reference but the
"problem" is not to do with the definition of what
a primative subprogram is, it is that primative 
functions derived from a tagged type that return a value 
of the derived type do not/can not _inherit_ their 
implementation from the ancestor type.  A new 
implementation must be provided - that is made 
explicit by forcing the declaration of those 
functions to appear for any derived types.

(or something like that ;)

Vinny


Stephen Cole wrote:
> 
> "Stephen Cole" <s_k_cole@yahoo.com> wrote in message
> news:9q49v5$6dj$1@trog.dera.gov.uk...
> > Hi
> >
> > Question 3.....
> >
> > package MyTstTypes is
> >    type MyRcd is tagged
> >       record
> >          a: Integer;
> >          b: Float;
> >       end record;
> >
> >    function Unit return MyRcd;
> >
> >    type MyNewRcd is new MyRcd with
> >       record
> >          c: Integer;
> >       end record;
> >
> > --   function Unit return MyNewRcd;
> >
> >    type MyNewRcd2 is new MyNewRcd with
> >       record
> >          d: Float;
> >       end record;
> >
> > end MyTstTypes;
> >
> > The compiler complains with the following text....
> >
> > "mytsttypes.ads:10:09: type must be declared abstract or "Unit"
> overridden"
> >
> > It wants me to define a version of Unit() for each derived type?! Why?
> >
> >
> 
> Look....people...my confusion is deeper than that. Its about this whole
> question of what a primitive operation is! Is it a function/procedure which
> takes a derived type parameter and/or returns a derived type? Or is it just
> functions which return a derived type only? Or what? The rules seem a bit
> fuzzy and inconsistent here. Why does returning a derived type seem to have
> more rules about what must be later declared in a derived type, than
> function/procedures that just take that derived type as a parameter?
> 
> Example
> Look at the following code....
> 
> package MyTest is
> 
>    type MyTestType1 is tagged
>       record
>          a: Integer;
>          b: Float;
>       end record;
> 
>    function UnitA(a: MyTestType1) return Integer;
>    function UnitB(a: MyTestType1) return MyTestType1;
>    function UnitC return MyTestType1;
> 
>    type MyTestType2 is new MyTestType1 with
>       record
>          c: Integer;
>       end record;
> 
> end MyTest;
> 
> UnitA() does not get flagged by the compiler as needing to be declared for
> MyTestType2. But UnitB() and UnitC() do! But they all hold enough type
> information for the compiler to be "intelligent" enough to know where static
> matching takes place or not. The way the compiler is behaving, its as if it
> only takes into account "out" parameters and does not care what "in"
> parameters look like. My case is futher confussed by the use of class wide
> types. But I'll come back to that if you can answer this static-only case
> for me first.
> 
> Thanks.

Re: Simple Question 3

[Jeffrey Carter]

Stephen Cole wrote:
> 
> Look....people...my confusion is deeper than that. Its about this whole
> question of what a primitive operation is!

A primitive operation of a type is declared in the same package
specification as the type declaration, and has a parameter of the type
or returns a value of the type.

> Example
> Look at the following code....
> 
> package MyTest is
> 
>    type MyTestType1 is tagged
>       record
>          a: Integer;
>          b: Float;
>       end record;
> 
>    function UnitA(a: MyTestType1) return Integer;
>    function UnitB(a: MyTestType1) return MyTestType1;
>    function UnitC return MyTestType1;
> 
>    type MyTestType2 is new MyTestType1 with
>       record
>          c: Integer;
>       end record;
> 
> end MyTest;

We could perhaps be of more assistance if you could define what you
expect the compiler to do for

X : Mytesttype2 := Unitc;

What is the value of X after initialization? Specifically, what is the
value of X.C?

-- 
Jeff Carter
"I fart in your general direction."
Monty Python & the Holy Grail

Re: Simple Question 3

[Stephen Cole]

"Jeffrey Carter" <jrcarter@acm.org> wrote in message
news:3BC9FD23.ACEB872A@acm.org...
>
> We could perhaps be of more assistance if you could define what you
> expect the compiler to do for
>
> X : Mytesttype2 := Unitc;
>
> What is the value of X after initialization? Specifically, what is the
> value of X.C?
>
> --
> Jeff Carter
> "I fart in your general direction."
> Monty Python & the Holy Grail

I would have thought that the compiler would have looked for a function
called UnitC() that would return a type MyTesttype2. If it could not find
one then it would flag a static match failure and so the whole problem of
X.C being initialised would not have occured as it would not be allowed.

HOWEVER

if it had been...

X: MyTestType1'class := UnitC

I would have expected it to have accepted it as there is only one UnitC()
function in existence (in my Ada world). If there were two then it would be
refused as ambiguouse. But this not the case as Ada will not accept the
derivation of a new type without also requiring that all base type functions
that return a base type value, be redeclared in terms of the new type. Which
may be proper but I don't see why?!

Sorry. Maybe I'm just being thick. I'll try an read the ARM95 manual. There
must be a good reason as I have not come across anything yet in Ada which
does not have a good reason.

Re: Simple Question 3

[Jeffrey Carter]

Stephen Cole wrote:
> 
> "Jeffrey Carter" <jrcarter@acm.org> wrote in message
> news:3BC9FD23.ACEB872A@acm.org...
> >
> > We could perhaps be of more assistance if you could define what you
> > expect the compiler to do for
> >
> > X : Mytesttype2 := Unitc;
> >
> > What is the value of X after initialization? Specifically, what is the
> > value of X.C?
> >
> > --
> > Jeff Carter
> > "I fart in your general direction."
> > Monty Python & the Holy Grail
> 
> I would have thought that the compiler would have looked for a function
> called UnitC() that would return a type MyTesttype2. If it could not find
> one then it would flag a static match failure and so the whole problem of
> X.C being initialised would not have occured as it would not be allowed.

Unitc is a primitive operation of the root type. Primitive operations
are inherited by the child type if they are not overridden. However, the
inherited version of Unitc cannot know about the additional components
of the child type, so it must be overridden. Therefore, Ada requires the
function to be overridden.

The problem arises because a call to Unitc can still be a dispatching
call. You cannot guarantee that all calls will be determinable at
compile time. Therefore, a version of the function must exist for the
child type.

Of course, if you use composition rather than type extension and
dispatching you can obtain the same effect but deal with these details
however you like. The resulting software will be easier to read, as
well.

-- 
Jeff Carter
"I wave my private parts at your aunties."
Monty Python & the Holy Grail

Primitive operations and derived types (Was: Simple Question 3)

[Jacob Sparre Andersen]

Stephen:

> Look....people...my confusion is deeper than that. Its about this whole
> question of what a primitive operation is! Is it a function/procedure which
> takes a derived type parameter and/or returns a derived type? Or is it just
> functions which return a derived type only? Or what? The rules seem a bit
> fuzzy and inconsistent here. Why does returning a derived type seem to have
> more rules about what must be later declared in a derived type, than
> function/procedures that just take that derived type as a parameter?
> 
> Example
> Look at the following code....
> 
> package MyTest is
> 
>    type MyTestType1 is tagged
>       record
>          a: Integer;
>          b: Float;
>       end record;
> 
>    function UnitA(a: MyTestType1) return Integer;
>    function UnitB(a: MyTestType1) return MyTestType1;
>    function UnitC return MyTestType1;

If I have understood the concept of primitive operations
correctly, then all of the three functions above are
primitive operations [RM 3.2.3(6)].

>    type MyTestType2 is new MyTestType1 with
>       record
>          c: Integer;
>       end record;
> 
> end MyTest;
> 
> UnitA() does not get flagged by the compiler as needing to be declared for
> MyTestType2. But UnitB() and UnitC() do! But they all hold enough type
> information for the compiler to be "intelligent" enough to know where static
> matching takes place or not. The way the compiler is behaving, its as if it
> only takes into account "out" parameters and does not care what "in"
> parameters look like.

No. The common element of UnitB and UnitC is that they
_return_ objects of type MyTestType1. It appears to have
something to do with UnitB and UnitC being "constructors"
for type MyTestType1. I suspect that the explanation is
hidden somewhere in RM 3.4, but I have not been able to find
it.

Jacob
-- 
http://www.ldraw.org/download/start/linux/
                         Get started with LEGO CAD on Linux.

Re: Simple Question 3

[tmoran]

> question of what a primitive operation is! Is it a function/procedure which
> takes a derived type parameter and/or returns a derived type? Or is it just
> functions which return a derived type only?
  The former.
> Why does returning a derived type seem to have
> more rules about what must be later declared in a derived type, than
> function/procedures that just take that derived type as a parameter?
> ...
> The way the compiler is behaving, its as if it only takes into account
> "out" parameters and does not care what "in" parameters look like.
  If an object of MyTestType1 is an input parameter to a function or
procedure, it's safe to inherit since the function/procedure will simply
not know about, and thus ignore, any later extensions in objects of
type MyTestType2.  If it's an output result, however, the function
or procedure needs to be able to create an object with all of its
extensions values.  That is only possible if the function/procedure
is declared after MyTestType2 is declared, so it knows about those
extensions and can set them to appropriate values.

>    function UnitA(a: MyTestType1) return Integer;
>    function UnitB(a: MyTestType1) return MyTestType1;
>    function UnitC return MyTestType1;
> UnitA() does not get flagged by the compiler as needing to be declared for
> MyTestType2. But UnitB() and UnitC() do! But they all hold enough type
> information for the compiler to be "intelligent" enough to know where static
> matching takes place or not.
  Yes indeed, the compiler does know whether static matching takes place.
It sounds like you want the compiler to flag any *use* of UnitB or UnitC
where the left side of the assignment statement does not match, but
you want the compiler to allow the *declaration*.  Right?
  If you were painting the floor in a room, you might like to paint a
thin part just inside the doorway, knowing that you could step over it
and get out of the room.  The compiler is saying, "whoa, you can't
start your painting from just inside the doorway because you'll paint
yourself into a corner".  It's easy enough to avoid the problem by
standing outside the doorway to do your painting.  Similarly, as
pointed out by Jean-Marc Bourguet, there are easy ways to declare Unit
as a non-primitive operation.

Re: Simple Question 3

[Stephen Cole]

<tmoran@acm.org> wrote in message
news:2Fny7.17385$gT6.10077588@news1.rdc1.sfba.home.com...
> > question of what a primitive operation is! Is it a function/procedure
which
> > takes a derived type parameter and/or returns a derived type? Or is it
just
> > functions which return a derived type only?
>   The former.
> > Why does returning a derived type seem to have
> > more rules about what must be later declared in a derived type, than
> > function/procedures that just take that derived type as a parameter?
> > ...
> > The way the compiler is behaving, its as if it only takes into account
> > "out" parameters and does not care what "in" parameters look like.
>   If an object of MyTestType1 is an input parameter to a function or
> procedure, it's safe to inherit since the function/procedure will simply
> not know about, and thus ignore, any later extensions in objects of
> type MyTestType2.  If it's an output result, however, the function
> or procedure needs to be able to create an object with all of its
> extensions values.  That is only possible if the function/procedure
> is declared after MyTestType2 is declared, so it knows about those
> extensions and can set them to appropriate values.

Why does it need to create them all? I would understand this if it was
returning a class wide type, but not a concrete defined type. One function
should be enough. And any calls for this "missing" function should cause a
dynamic or static error to occur.

>
> >    function UnitA(a: MyTestType1) return Integer;
> >    function UnitB(a: MyTestType1) return MyTestType1;
> >    function UnitC return MyTestType1;
> > UnitA() does not get flagged by the compiler as needing to be declared
for
> > MyTestType2. But UnitB() and UnitC() do! But they all hold enough type
> > information for the compiler to be "intelligent" enough to know where
static
> > matching takes place or not.
>   Yes indeed, the compiler does know whether static matching takes place.
> It sounds like you want the compiler to flag any *use* of UnitB or UnitC
> where the left side of the assignment statement does not match, but
> you want the compiler to allow the *declaration*.  Right?

Not really. What I mean is Why the separate ruling for UnitA() and UnitB(),
UnitC() when it comes to what must be redeclared in terms of the derived
type? This question all started for me with asking whether a function needed
to be fully decleared for all future derived types if it was declared as
abstract in the base type. But now I see another situation where you *must*
redeclare a function, and it looks like you must declare it for the full
hierarchy rooted at the base type. This seems odd. And I'd just like to
understand the reason why this is.

>   If you were painting the floor in a room, you might like to paint a
> thin part just inside the doorway, knowing that you could step over it
> and get out of the room.  The compiler is saying, "whoa, you can't
> start your painting from just inside the doorway because you'll paint
> yourself into a corner".  It's easy enough to avoid the problem by
> standing outside the doorway to do your painting.  Similarly, as
> pointed out by Jean-Marc Bourguet, there are easy ways to declare Unit
> as a non-primitive operation.

I think you are talking about where function/procedures are declared
(painted) relative to the derived record types themselves. Are you? This
must be after the type as the compiler *sees* things sequentially from top
to bottom. This makes sense. Its just the *demand* by the compiler for me to
redeclare a function/procedure just for reason of what type it returns,
which is throwing me.