Re: class wide iterable (and indexable)

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

On 2019-01-10 00:38, Randy Brukardt wrote:
> "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).

Possibly.

> So there is no sharing that can be done between them other than that
> which comes directly from the generic unit itself.

If you design them specifically so, but why?

> 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?

You mean declaring an interface inside the generic?

>>> 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.)

Yes, but this is another roadblock. Elements of containers should be 
externally tagged by-value types. That would eliminate the overhead.

> 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.)

Sure. It is the same problem in both cases. The solution that would work 
for generics is exactly the interfaces (universal) I am talking about. 
Presently, it is only tagged contracts that are allowed (tagged type or 
Ada interface). And they work perfectly. If we introduced externally 
tagged contracts they would work out of the box just same. Ah, but we 
would not need generics then...

>> 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.

Then why interfaces are useless? Does it apply to #1 or #2.

>>> 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.

There is more than one type of sequences. Sounds like a tautology already.

> 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. :-)

You make it regular. There is no reason why arrays and containers must 
be treated differently by the language.

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

But you cannot have safety if you are going to expose all dirty clothes. 
Separation of interface and implementation trumps everything. If an 
instance is for implementation reasons only it must be hidden.

BTW, names of generic instances induce a huge mess in practice. Nobody 
ever remember what name which instance in both directions. You see a 
name with half a dozen dots in it, and struggle to guess what the hell 
is this.

>> 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.

Yes, it wouldn't be Ada 2012! (:-))

> 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. :-)

We have discussed that many times. I see no reason why it should be 
incompatible. Except, maybe, for a few obscure cases with generics, 
nobody really cares about. There is no more than a half-dozen people in 
the world who know how these must work while they all disagree with each 
other... (:-))

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