Re: Legit Warnings or not

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

On Mon, 1 Aug 2011 17:12:23 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:gfjkj1eowd8x.1q86rn9zvkfd.dlg@40tude.net...
>> On Fri, 29 Jul 2011 19:17:25 -0500, Randy Brukardt wrote:
> ...
>>> Interfaces require multiple inheritance. Multiple inheritance is
>>> unimplementable (at least efficiently). It's completely unimplementable 
>>> in
>>> Janus/Ada which is based on fixed, statically sized objects and 
>>> components.
>>> (Generic code sharing is a lot easier.)
>>
>> 1. Ada 2005 has interfaces.
> 
> Ada 2005 interfaces are unimplementable in Janus/Ada. (That's a tiny bit 
> strong, there is a way to implement them, but no one would ever want to use 
> the result.)

It is sad. Ada needs a compiler diversity. There is a huge niche which GNAT
didn't gnaw - the microcontrollers. A reasonably priced Ada compiler could
be a hit there, because the alternatives are either C (unbearable
developing costs) or Java (catastrophic performance). The customer
mentality is: buy the processor first, search for a compiler afterwards.

>> 2. The case I gave is fully static, without classes (of arrays or records).
>> This is not a dynamic interface it is just same thing as "type X is
>> private;" Private and limited private were interfaces already in Ada 83.
> 
> If you have a generic sharing compiler,  there is nothing that is not a 
> dynamic interface. *All* properties of a type are dynamic.

> The presence or absence of array manipulations is pretty much the only 
> exception, which makes it reasonably efficient. Changing that would make a 
> decent implementation impossible.

As you know, I don't value generics in whatever implementation.

>> 3. It was you arguing for objects which size were indeterminable and
>> components dynamically allocated. And now?
> 
> No, I was arguing for "non-contiguous objects". I *am* guilty of mixing up 
> Janus/Ada terminology with Ada's, however; for Janus/Ada, all top-level 
> objects are contiguous and statically allocated. They may, however, have 
> implicitly managed sub-parts that are neither. That's why Janus/Ada 
> considers the array descriptor (which is static sized) the object and not 
> the data. That's not quite the meaning of "object" in Ada, and presumably 
> you read it to mean something closer to that definition - sorry.
> 
> So far as I can tell, it is impossible to come up with anything reasonable 
> which would allow multiple inheritance in this scheme, because the compiler 
> has to know in advance how many parts there are and where to find them --  
> and that is not possible with multiple inheritance.

The language needs a scheme to support "an instance of the type S viewed as
the type T".

>  > 4. Why a built-in implementation of array of S'Class (what you seemed to be
>> arguing for) should be easier/more efficient/more compatible to Ada than an
>> implementation trough Ada.Container only publicly visible as an array?
> 
> There is no new magic needed to allow S'Class as a component type -- only 
> the removal of a single legality rule (much like Ada 2005 eliminated the 
> library-level requirement on derived tagged types).

That is because your compiler already implements this magic. Other
compilers may have problems with that.

And for a programmer the problem is to have control over the constraints
(when the tag can be changed and when not) and over copying (when dynamic
components get copied, when shared). You will need a lot of new keywords
and syntax constructs to specify all possible and needed combinations of
these, plus terrible rules about how these constraints are propagated upon
composition and inheritance. What happens in generics etc.

To me it is just an overkill. Ada already suffers a plethora of unorganized
special cases of types instead of a clean and *small* type system.

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