Re: How many Ada compiler bugs are here?

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:e8vqwjo7ify3.htkn2p8qs8lw$.dlg@40tude.net...
> On Fri, 13 Jan 2012 18:26:13 -0600, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:11extopcf5hsy.qk7psu30kjrp.dlg@40tude.net...
>>>>> BTW, I always wondered why cannot we have multiple parents of a 
>>>>> package
>>>>> in Ada?
>>>>
>>>> Sounds hugely complicated.
>>>
>>> Why? The only complicated thing would naming of the files.
>>
>> Because the parent's declarations are directly visible in the child. If
>> there are multiple parents, you'd have multiple scopes of declarations
>> directly visible, and we would have to worry about what happens when 
>> there
>> are conflicts. We don't have to do this in Ada today.
>
> Yes, but I want this feature in other form anyway. I want to have an
> ability to fuse several declaration scopes into a package to reuse 
> obtained
> direct visibility scope later. It is quite a problem now that packages 
> need
> large sets of "with" and "use" clauses in front of them as well as 
> multiple
> "use" clauses inside them (for generic instances). This stuff is repeated
> over and over again, which is a maintenance problem and a problem for the
> reader.

I agree with you, and in fact we tried to provide such a feature in Ada 
2012. (See AI05-0135-2.) We eventually gave up, mainly because any scheme 
for managing the conflicts caused unacceptable problems in maintenance.

>> There is a similar problem for package use clauses, but there is no
>> satisfactory solution to that problem. All of the solutions are dangerous
>> (Ada picks the least dangerous solution, but it still has lots of issues 
>> in
>> practice). I don't think we want more of these cases.
>
> I am not sure which solutions you have in mind. I would simply forbid any
> conflicts. The compiler must insist on explicit renaming of all 
> conflicting
> entities.

We tried rules on that line, but they caused the sorts of maintenance 
problems that aren't really acceptable. It should never be the case that 
adding a declaration to a package makes some other package illegal even 
though the other package does not use the new declaration. (Yes, I know 
there are cases where direct visibility and parent visibility violate this 
principle, but just because the language is already wrong doesn't mean it 
should be made wronger. :-)
[Keep in mind I'm talking about an *addition* and not a modification of a 
declaration. The principle is that adding new features to a package 
shouldn't cause clients that don't use those features to need modification.]

Another cause of problems was diamond inheritance, where an integrated 
package tries to add a declaration that is already directly visible by some 
other path. We definitely don't want those to conflict, but it is very hard 
to craft rules that have the right effect (in large part because visibility 
is based on "views", not "entities", and these clearly are different views).

> It is rather a perceived problem so long declaration scopes cannot be 
> named
> an reused. Once we would use them as named entities, construct and design
> them intentionally, the problem would disappear.

Maybe, but the evidence is that handling the conflicts is a major 
maintenance problem.

One thing that clearly would help would be to make all entities 
overloadable. In that case, there would be far fewer conflicts (objects 
would overload on their types, and could overload with functions and 
procedures as well), so perhaps we could live with the conflicts. But that 
would be hugely expensive in existing Ada compilers (pretty much all of the 
visibility mechanisms would have to be redone from scratch), and it is 
unlikely that it could be done compatibly with existing code.

I made a proposal to allow overloading of objects (only), which I believe 
could in fact be done compatibly, but it went nowhere. And there still would 
be problems with exceptions and packages and types (none of which can be 
overloaded currently or in any compatible way), so its probably not enough.

                                    Randy.