Re: Type extension with GNAT

Re: Type extension with GNAT

[Robert Dewar]

I disagree with Robert Eachus' complaint about overloading and overriding.
The critical point here is that constructors of this type should not
be made primitive. THAT's the solution, and that's what we shold teach
people to understand.

Re: Type extension with GNAT

[Cyrille Comar]

dewar@cs.nyu.edu (Robert Dewar) writes:
: I disagree with Robert Eachus' complaint about overloading and overriding.
: The critical point here is that constructors of this type should not
: be made primitive. THAT's the solution, and that's what we shold teach
: people to understand.

Since this bug will be done and redone by every single Ada95 beginner
we ought to treat it specially in GNAT. I don't see a significantly
better error message that would solve the problem so maybe what we
could do is to add an additionnal message:

    See file "Gnat_Common_Mistakes" paragraph "inheriting functions"

and provide some more detailed explanation on this problem in the
specified file. How does it sound?

-- 
------------------------------------------------------------------------
Cyrille Comar,                                  E-mail: comar@cs.nyu.edu
Gnat Project                                    US phone: (212) 998-3489

Re: Type extension with GNAT

[Robert Dewar]

>dewar@cs.nyu.edu (Robert Dewar) writes:
>: I disagree with Robert Eachus' complaint about overloading and overriding.
>: The critical point here is that constructors of this type should not
>: be made primitive. THAT's the solution, and that's what we shold teach
>: people to understand.
>
>comar@cs.nyu.edu (Cyrille Comar) writes:
>
>Since this bug will be done and redone by every single Ada95 beginner
>we ought to treat it specially in GNAT. I don't see a significantly
>better error message that would solve the problem so maybe what we
>could do is to add an additionnal message:
>
>    See file "Gnat_Common_Mistakes" paragraph "inheriting functions"
>
>and provide some more detailed explanation on this problem in the
>specified file. How does it sound?

Robert replies:

putting in speerences like this is a mistake unless it is done
as part of an organized system, in other words just doing it for one
message does not make sense. What we should have is a general mechanism
for further information on error messages.

In fact I think the error message in GNAT is highly confusing, it talks
about abstract types, when most people reading it will not even know (or
need to know) what an abstract type is.

I would far prefer an error message that says something

   "function XYZ returns tagged type and must be overridden"
   "provide overriding, or declare original in inner package"

this does not explain the situation, but at least it gives the right
corrective action. Mentioning abstract types seems a mistake to me.

Re: Type extension with GNAT

[Robert I. Eachus]

In article <3iguhr$ai4@gnat.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes:

  > I disagree with Robert Eachus' complaint about overloading and
  > overriding.  The critical point here is that constructors of this
  > type should not be made primitive. THAT's the solution, and that's
  > what we shold teach people to understand.

   If the fact that users need to put constructors in nested packages
is the worst feature of Ada 95, then everyone involved did an
incredibly good job. (And even if there are a few other worse
blemishes discovered, Ada 95 turned out to be fantastically better
than we could have hoped when the process started.)  But given the
amount of traffic generated on the net, and the number of times I have
already had to explain this "feature" to naive users, I am going to
grow very, very tired of explaining this over the next decade.

   Hmmm, maybe I had better explain where I am coming from.  There was
obviously a lot that could be improved in Ada 83, but there were some
cases where judgement calls had to be made.  In some cases the choices
made were right for the time, but needed to be revisited in the
revision.  In many other cases history proved the decisions right.
But there were two decisions which obviously hurt the acceptance of
the language.

   I'm not sure, even in hindsight, whether the choice to leave the
elementary math functions out of Ada 83 was right or wrong.  (For Ada
9X, leaving them out was almost unthinkable--but that reflected the
results of lots of work by many dedicated people.  And the decision in
82 was that the work couldn't be done in time for that version of the
standard, and putting in a poorly specified package would have been a
mistake.  Fair enough.)

   But I have ALWAYS felt guilty about the wording in the manual on
expiration of delays.  I feel that I correctly pointed out to the
design team that the previous wording had unimplementable
requirements, but I should have realized how the proposed correction
would be read by non-language lawyers. (Robert Dewar should probably
feel some guilt as well, for pointing out publicly--and
correctly--that implementations without multple priority levels could
be more useless than most people thought.)  As the RM is written, if a
compiler supports more than one priority level, it must do expiration
of delays correctly.  However, the wording seems to say that compilers can
be lazy about restarting tasks after a delay, and this became a common
misperception about Ada in embedded programming circles.

   Now I don't feel any guilt associated with the derivation of
constructors in Ada 95.  Even if in ten years we discover a better
approach, that doesn't make the current design wrong.  But I intend to
work as hard as I can to make this a known design rule that gets into
all the style guides and all the textbooks, so that we don't lose
potential Ada users over this extremely minor seeming issue.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Type extension with GNAT

[David Wheeler]

Cyrille Comar (comar@cs.nyu.edu) wrote:
: dewar@cs.nyu.edu (Robert Dewar) writes:
: : I disagree with Robert Eachus' complaint about overloading and overriding.
: : The critical point here is that constructors of this type should not
: : be made primitive. THAT's the solution, and that's what we shold teach
: : people to understand.

: Since this bug will be done and redone by every single Ada95 beginner
: we ought to treat it specially in GNAT. I don't see a significantly
: better error message that would solve the problem so maybe what we
: could do is to add an additionnal message:

:     See file "Gnat_Common_Mistakes" paragraph "inheriting functions"

: and provide some more detailed explanation on this problem in the
: specified file. How does it sound?


I _strongly_ agree with this approach; it helps both the expert
and the novice.


--- David A. Wheeler
Net address: wheeler@ida.org

Type extension with GNAT

[Michael M. Bishop]

I want to thank everyone for their thoughtful replies to my original
post on this subject. I've finally figured out what you guys were trying
to tell me! I decided to replace my constructor function with a
procedure (Create), which solved my original problem. I also realized 
that when deriving from a tagged type, one does not say

type Three_D_Point_Type is private;

and then define the type extension in the private part, but rather

type Three_D_Point_Type is new Two_D_Point_Type with private;

and then elaborate the type extension in the private part. With that
little bit of business behind me, I was able to successfully code and
test my Two_D_Point_Package, Three_D_Point_Package, and even a
Four_D_Point_Package! This has been a good day.
-- 
| Mike Bishop              | The opinions expressed here reflect    |
| bishopm@source.asset.com | those of this station, its management, |
| Member: Team Ada         | and the entire world.                  |

Re: Type extension with GNAT

["Jim Wall"]

Erm,

I get the feeling that you've tried something like:

type One is tagged record
   A : ?
   B : ?
end record;

procedure A ( a : ?;
              b : ? );
              <new package>

type Two is new One with
   C : ?
end record

procedure A ( a : ?;
              b : ?;
              c : ? );
              ????

assuming this (and forgive the pseudo-code) then, then what you're after 
is simply

procedure A ( AA : One );
 
and

procedure B ( BB : Two );



Here B 

If this is so, I suggest that if your original 'point' procedure were to 
accept the actual type Two_D_Point and the version for Three_D_Point 
(being the extended Two_D_Point) then the problem wouldn't arise.