Re: class wide iterable (and indexable)

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

On 2019-01-14 23:59, Randy Brukardt wrote:

> Perhaps, but then you can't build anything really generic (like the
> containers or Direct_IO).

Especially them! Generics have no place in containers and I/O. It is 
pure insanity.

> Forcing everything into a class just for the sake
> of that just replaces one set of problems with a different set.

Generics types form classes. You cannot avoid classes, you only can 
change the means of building them.

>> It is the same mechanism that is used for passing array bounds. And if
>> statically known (and all parents are abstract) the constraint can be
>> eliminated altogether, again like with arrays. You might be required to
>> adjust inherited operations, but again, this is no different from what you
>> do with shared generic bodies.
> 
> Sure, but passing array bounds is pretty expensive. It's certainly more
> expensive than having a tag component, at least unless the number of objects
> number of calls. Again, you're just trading one set of costs for a
> different set.

I mean that when array is statically constrained bounds are removed. The 
case with containers that the element type is constrained and the same 
mechanism can be used to avoid overhead.

>>> Ada probably can't use the separate tag model because of its insistence
>>> on
>>> supporting redispatching, even in inherited routines. I think you've
>>> convinced me that model was a mistake, but like many things in existing
>>> Ada,
>>> we're stuck with it short of a drastic (not completely compatible)
>>> redesign.
>>
>> There is no view conversions for such types, they are by-value. Thus no
>> way to even spell re-dispatch. Conversion to Parent'Class will create a
>> new object.
> 
> Not necessarily, since we're also talking about untagged composite types.
> One hopes that we're not going to force strings or coordinates to be passed
> by copy (that would cause a lot of extra copying).

It is OK. But that would not bring view conversion back. The tag will be 
taken from the designated data type and tag + reference will passed as 
class-wide. It is tag + value or tag + reference, the semantics will be 
same.

>> Interfaces should be allowed to be additive with the corresponding rules
>> to resolve conflicting implementations. There is an obvious contradiction
>> between invisibility and idempotence, e.g. if one entity is visible and
>> other is not. Let them add up and require conflict resolution in the
>> contexts where both become visible.
> 
> What would that look like? Currently, you can only resolve conflicts with
> type names, and that certainly would not be enough in this case (the name of
> the interface being the same for every copy, as well as the type that has
> all of these interfaces). Numbering isn't going be reliable (the number of
> copies could differ for every view). So how could you deal with such
> conflicts?

I don't know. There should be some nice syntax invented to replace 
conflicting names (of interfaces + their operations and members) at the 
type declaration point.

>> No, I don't believe that either. See how people keep on creating C. There
>> is a dozen of C-like languages redesigned from scratch, but the warts are
>> all there.
> 
> The people doing that like a lot of about C already (why the mass hysteria
> on that, I don't know. Perhaps they don't even know that you can do
> better?). If I personally redesigned Ada, it would be a lot like the current
> Ada with some warts removed (strings and arrays in particular).

See, that is the same mindset! (:-))

> I generally
> like the way Ada works, as I'm sure you know; I don't think a lot needs to
> be done to the type system. Clearly your vision is rather different.

I think that the type system must be generalized and extended, not 
changed. What you say about strings and arrays is what I would as well. 
But I would simply make them library-level things because the extended 
type system would be capable to make them such.

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