On Wed, 23 Jul 2014, Randy Brukardt wrote:

> I think you miss the point. This isn't something that one intentionally
> writes (and "Error" is a terrible name just used for an example). But if one
> intends to reuse code, the client has no control over the naming of the
> entities in the reused code. Moreover (and more important), the client
> shouldn't break due to unrelated maintenance on some third-party code.
> Especially if that third-party code decides to add something with the same
> name as something that you are already using. How could they know to avoid
> it?

It would be nice if Ada had a selective "use" clause, a bit like MODULA2's 
import:

   from Ada.Text_IO use Put, New_Line;

Now the programmer could write Put("Hello"); New_Line; but would have to 
resort to prefix notation for Ada.Text_IO.Put_Line("Hello").

This would keep your namespace free from any new identifiers the 
maintainer of Ada.Text_IO can add to the package. (Yes, Ada.Text_IO isn't 
the best example for this issue ...)

> One could imagine a rule "no use clauses of any kind, anywhere", but that's
> not really practical (especially as it means no infix operator usage).

What about allowing "use type <id>" and "use all type <id>", but 
not "use <id>"?

> In
> the absence of that, you're going to be at risk for problems. Moreover, even
> if "prefixes are good", they also make code unreadable (particularly if you
> have lots of child packages).

What about using rename?

   package PFS renames My_Project.Abstract_IO.Persistent_File_Storage;

> SPARK avoids overloading because the original authors of the tools didn't
> have enough knowledge of how to implement it.

Claiming them not to "have enough knowledge" is unfair!

SPARK has originally been written for Pascal, which doesn't support 
overloading (or didn't at that time). So the designed their tools such 
that they did heavily depend on subprogram's unique names. E.g., the 
information the toolset did generate for a subprogram was stored in a file 
with the subprogram's name.

When they changed to Ada, they didn't start from scratch, but used the 
back-end they had originally written for Pascal. Adaption to beyond-Pascal 
properties of Ada clearly had a low priority for them.

You could see that even in the output: When a hypothesis (i.e, a 
precondition) required two entities to be different, the SPARK toolset's 
output would use the Pascal symbol for not equal, rather than Ada'S "/=".

While changing the output symbol would not have been a big issue, adapting 
to overloading clearly would imply a huge amount of work, with things 
breaking all over the toolset.

> They then explained that as a
> "benefit", but the only benefit is that it simplified their tools.

Agreed!


------  I  love  the  taste  of  Cryptanalysis  in  the morning!  ------
     <http://www.uni-weimar.de/cms/medien/mediensicherheit/home.html>
--Stefan.Lucks (at) uni-weimar.de, Bauhaus-Universität Weimar, Germany--