Re: class wide iterable (and indexable)

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:q159mg$1q6k$1@gioia.aioe.org...
> On 2019-01-09 00:26, Randy Brukardt wrote:
>
>> But that's the point: there aren't any significant tagged classes here, 
>> just
>> generic classes, because there is only one instance of each class (use of
>> formal packages can't change that).
>
> This is what I do not understand. Instance of a class is a type. Do you 
> mean the depth of the hierarch,y probably? Because the number of sibling 
> instances is usually large.

But the siblings are incompatible with each other (different types, as you 
say). So there is no sharing that can be done between them other than that 
which comes directly from the generic unit itself. That makes any interfaces 
(again, Ada interface feature) involved useless, as they're necessarily 
different than any other such interfaces, which means there isn't anything 
that you can do with them. So why have them at all?

...
>> No, I argue that given that there is no realistic alternative (other than 
>> to
>> abandon strong static typing by deriving everything from a common type, 
>> then
>> store Object'Class).
>
> It cannot be Object'Class because that includes limited types etc. There 
> are lots of constraints on the elements depending on the container, like 
> ordering, hashes. These constraints must be spelled in the language, not 
> silently assumed. A named interface is a language to spell such 
> constraints. #1.

Making the elements much more expensive (because of the need to manage an 
expensive tag) than they otherwise would be. There's a lot of pushback on 
even making language-defined units tagged, because of overhead concerns. 
(Don't buy that myself, but that's the mindset.)

Anyway, #1 has to be part of the contract of the generic. Doesn't make sense 
otherwise. And packaging all of the contracts into a single entity has been 
tried in many ways (that's the original reason for formal packages, the 
so-called signature package) -- and it's always too inflexible. Best to just 
have the individual requirements clearly stated in the profile of the 
generic. (I'd have said "interface", meaning the concept, not the feature, 
but that gets too confusing.)

> The instances must be further constrained by the user from his side. Just 
> like we declare an array type, it does not mean that it can hold any 
> elements from the class of definite types. #2.
>
> It seems that you mix constraints #1 with #2.

#1 has to be part of the contract of the generic; #2 clearly is not. Don't 
see any mixing there.

>> If there was a way to have a universal container interface independent of
>> the element type (and have that be useful), then the concept would be a 
>> lot
>> more useful. But that isn't possible in any Ada-like language and retain
>> static typing.
>
> I do not understand why. Create an anonymous instance, clone the 
> hierarchy, constrain Element'Class to the concrete type T. Everything must 
> be done by the compiler in one step as it does for array types.

Well, separate array types are a mistake given that there are many 
implementations for a sequence. It would be better for them to be a 
container just like all of the others. I.e. I'd make it harder to declare an 
array rather making it easier to declare a container. :-)

I discussed anonymous instances elsewhere; they do great damage to the Ada 
model that everything has a place and to readability.

...
>> Which makes sense to me, since the primary benefit of inherited types is
>> implementation reuse. Which interfaces don't allow. I'd surely support 
>> this
>> position, but I think it is impractical to implement (as well as define
>> properly rules for).
>
> Right, this is our main conceptual disagreement. You want to stick to 
> generics though they have proven not working. The only alternative is 
> inheritance (advanced type system). If only one percent of mental efforts 
> were invested into the type system instead, we could have a different and 
> IMO better Ada today.

A different language, but it wouldn't be Ada. There's no way it could be 
compatible enough, to do so would be to do great violence to that "advanced 
type system". Because most of the details of Ada types aren't advanced in 
any sense. :-)

...
>>> I would gladly use Janus/Ada or ObjectAda if I could. I was a happy user
>>> of the latter long ago. Unfortunately cross-platformity is a requirement
>>> in these days.
>>
>> Understood. As you know, that costs $$$, and there aren't enough of those 
>> to
>> go around.
>
> Sure, we need another crazy billionaire who would invest some bits of his 
> unearned wealth into Ada rather than in digging tunnels in seismically 
> active zones... (:-))

Agreed. :-)

               Randy.