Re: Legit Warnings or not

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:go2nk5b4odfy.fpdttridydu6$.dlg@40tude.net...
> On Wed, 27 Jul 2011 19:37:55 -0500, Randy Brukardt wrote:
...
>> Experience with containers shows that no one would use such things unless
>> they were part of the predefined libraries.
>
> What experience? It never was possible in Ada.

No one uses predefined libraries of any kind in Ada unless they either wrote 
them themselves or they are part of the standard. Otherwise, people claim 
that Ada cannot do X even though it is simple to write a package to do X.

That would absolutely be the result if we adopted your approach. Hardly 
anyone would use it, and Ada would be purceived as substantially less 
powerful.

>> Moreover, you cannot create a *better* implementation than the one
>> built-into the compiler
>
> See, this is where you approach leads.

The compiler can do virtually *anything* better than the programmer. The 
only question is where to draw the line.

>> (Keep in mind that hardly any compilers optimize finalization,
>> even though it is possible and reasonably practical, mainly because of 
>> the
>> difficulty of allowing arbitrary user code in such optimizations. The 
>> same
>> would be true for your sorts of abstractions.)
>
> Maybe because compiler vendors are too overwhelmed by implementing more 
> and
> more magical stuff?

Not at all. This is true because to build a better approach in a library 
form, you have to know every possible usage of the library (otherwise, you 
have to support the most general case which by definition would have lots of 
overhead unnecessary in your specific circumstances). That is not practical 
in a language that supports separate compilation and it is not possible at 
all if you support shared libraries.

When the compiler does it, it can share the overhead (for pools and 
finalization, just to take two examples) and in many cases eliminate it 
altogether, based on the form of the type declaration and other properties 
that cannot be available inside of a generic container.

>> You seem to want the
>> programmer to work harder (and apparently never want anyone to use 
>> dynamic
>> array objects in Ada, since those have the sort of implicit-reference
>> semantics that you claim to hate).
>
> No, I want that dynamic arrays were *arrays*. I want that Ada.Container
> could be selected as an implementation of that array by mere renaming or
> other kind of delegation:
>
>   type A is array (Positive range <>) of S'Class;
> private
>   package My_Arrays is
>      new Ada.Container.Indefinite_Vector (Positive, S'Class);
>   type A is new My_Array.Container_Type with null record;
>
> Is it too much?

Yes, for Ada it is too much. Anything implemented now has to be compatible 
with the existing language and implementations. For the "Dmitry" language, 
feel free.

After all, I'm probably tilting at windmills on this topic, and *the 
language already allows this approach*. You want a vastly different approach 
that would require massive language and implementation changes. (The above 
would be completely impossible with the Janus/Ada shared generic approach, 
for instance.) That's not happening any time soon.

                                Randy.