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

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Thu, 24 Nov 2011 14:48:46 -0800 (PST), Shark8 wrote:

> 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 still better than arbitrary slogans and advertising TMs and some RMs
tend to. If you want definitions, they should be from scientific sources,
peer reviewed, commonly accepted, [not funded by large vendors we all have
in mind...].

Then a definition must *define* some really existing phenomenon. It is
pointless to discuss DbC (TM) because it is not something which really
exists.

>> 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.

Executable code in declarations is. Dynamic contracts are.

> 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;

Passing null is not a contract violation.

If the goal was to extend composition means in Ada, .e.g. an ability to
compose new operation F as

   F = Epilogue o G o Prologue 

I am not against that because I proposed such stuff myself. Just do not
call Prologue precondition, because it is not.

BTW, precondition, postcondition etc were introduced by Dijkstra for
correctness proofs. It is DbC (TM) which misuses established terms, not me.

> By moving the null-exclusion logic "to the parameter" we can get rid
> of all the cases where, previously, we had to handle Null.

Only when provable, i.e. when the compiler and the program reader *know*
that the check is superfluous in the body.

Note that there is much more use in statically enforced Prologue and
Epilogue. E.g. it would allow to solve the notorious problem of handling
dimensioned values in Ada. It is also necessary to have broken Ada
constructors and destructors working.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de