Re: Generic-Package Elaboration Question / Possible GNAT Bug.

[Shark8 <onewingedshark@gmail.com>]

On Nov 24, 4:10 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Wed, 23 Nov 2011 19:07:55 -0800 (PST), Shark8 wrote:
> > On Nov 22, 10:23 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
> >> I don't care about trade marks and definitions given by reference
> >> manuals...
>
> > Why not; definitions are essential to understanding each other.
> > If someone saying 'hammer' means 'shotgun' then what does "I need a
> > hammer." mean?
>
> That is the reason. TM and RM are inclined to name hammer shotgun.
>
> DbC (TM) considerably deviates from design by contract (common sense),

Unfortunately "common sense" is not intuitively obvious to everyone;
furthermore, "common sense" is hampered by the fact that natural-
language tends to contain connotations not within the actual
definitions of the words. It is because of this that there must be a
set of definitions wherewich to have a common ground. (i.e. relying on
'common sense' you tend to argue about the definition-content rather
than the problem itself.)


> as
> Georg has explained willingly or not. For example disregarding separation
> of interface and implementation is not how things are designed by contract.

I actually fail to see exactly where the interface/implementation
separation is an issue in Ada 2012.
Consider this:
The ARM allows a compiler to treat PROCEDURE P( EXTERNAL_PARAM : IN
OUT SOME_TYPE ) IS [SUBPROGRAM_TEXT] END P; as the following:

PROCEDURE P( EXTERNAL_PARAM : IN OUT SOME_TYPE ) IS
INTERNAL_PARAM : SOME_TYPE:= EXTERNAL_PARAM;
[SUBPROGRAM_TEXT] (renaming EXTERNAL_PARAM to INTERNAL_PARAM)
EXTERNAL_PARAM := INTERNAL_PARAM;
END P;

Now, with the pre- and post-conditions we may expand this PROCEDURE
P( EXTERNAL_PARAM : IN OUT SOME_TYPE ) WITH PRE => PRECONDITION, POST
=> POSTCONDITION IS ... conceptually to:


PROCEDURE P( EXTERNAL_PARAM : IN OUT SOME_TYPE ) IS
IF NOT PRECONDITION RAISE CONSTRAINT_ERROR;
INTERNAL_PARAM : SOME_TYPE:= EXTERNAL_PARAM;
[SUBPROGRAM_TEXT] (renaming EXTERNAL_PARAM to INTERNAL_PARAM)
IF NOT POSTCONDITION RAISE CONSTRAINT_ERROR;
EXTERNAL_PARAM := INTERNAL_PARAM;
END P;

In other words, it seems to me to be the natural progression of Ada
2005's Null Exclusion.
Procedure Delete( Param : Not Null Access Link_List_Node ) is
 begin
   [Deletion operation] -- Hey, we can get rid of checking for Param =
Null here!
 end Delete;

By moving the null-exclusion logic "to the parameter" we can get rid
of all the cases where, previously, we had to handle Null. Likewise,
the pre- and post- conditions allow us to do the same on a more
generalized level. Just like, in simple terms, we can disregard
worrying about division-by-zero errors in the following code:

If Input_2 = 0 Then
 -- If Input_2 is Zero here we have a BIG PROBLEM.
 Return Input_1 / Input_2;  -- Return the division, if it is
possible...
Else
  Return Input_1'Base'Last; -- Otherwise, return the maximum value.
End If;