Re: Why .ads as well as .adb?

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

On 2019-06-03 09:35, Maciej Sobczak wrote:
>> That is not possible. You cannot generate specification from
>> implementation and conversely.
> 
> Yes, you can. You can generate specs from implementations.

No. Specification describes a class of implementations. You cannot 
deduce class from its single member.

>> In both cases there is additional
>> information missing.
> 
> Why is it missing? What if we put all information in implementation? Then there is nothing missing and we can generate specs from it.

It is not possible as well. The language of specifications (to be 
useful) must have statements non-existing in the language of 
implementations.

> Your argument is not convincing. It can be expanded into:
> - I have separate spec and implementation files, so I can write my contracts in the spec and then I don't have to repeat them in bodies.

No. The right statement would be: I cannot write contract in the body.

Contract and an implementation of are in two different languages with 
two different domains. They cannot be spelt in a single language.

BTW, this is why Ada's dynamic constraints is not a contract. They are 
implementations of a contract to raise an exception when some Boolean 
expression yields False.

> - Well, I did not write my contracts in bodies, so they are not there and therefore something is missing, so I cannot generate specs from it.
>
> ?

Right.

>> Compare also Ada's declarative regions with C++'s
>> ad-hoc declarations:
>>
>>      declare
>>         X : Integer;
>>      begin
>>         ... -- Some code
>>         X := 1;
>>      end;
>>
>>      {
>>         ... // Some code
>>         int X;
>>         X = 1;
>>      }
> 
> When I compare these two examples, I see that C++ is more readable, because it allows me to minimize the scope of names that are not needed until in later parts of code, without messing with useless constructs like this:
> 
> begin
>     -- some code
>     declare
>        X : Integer;
>     begin
>        X := 1;
>     end;
> end;
> 
> There is *nothing* gained in this construct and it is equivalent to the C++ example above.

The gain is definition of the scope. C++ equivalent, which I would force 
in each C++ programming guideline, would be:

    {
       ... // Some code
       {
          int X;
          X = 1;
          ..
       }
       .. // Some code
    }

>> BTW when writing OS-dependent code it is very convenient
>> to have one *.ads file and several *.adb files.
> 
> I do that in C++, too.
> 
>> And, in the
>> tool-chain you just switch to another *.adb when changing the target.
> 
> And, in the tool-chain you just switch to another *.cpp when changing the target.
>   
>> Compare that with C++'s #ifdef infestations.
> 
> What? Why would anybody do that, apart from those few cases where this approach genuinely improves the readability of the code and where having separate compilation units would actually be more difficult to maintain?

Yes, why? There must be something contagious in #ifdef's, or maybe, it 
just what C/C++ inherently is?

My guess and my point is that this is what you inevitably get without 
proper contracts (=> separated specifications).

> In other words: for multiplatform development, C++ gives me 2 solutions and I can choose the one which is more beneficial in the given context. Ada offers only one. How is this better?

Choice is a burden. Would you can have a water tap with a third choice: 
hot, cold, sulfuric acid?

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