From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: class wide iterable (and indexable) Date: Tue, 15 Jan 2019 10:34:18 +0100 Organization: Aioe.org NNTP Server Message-ID: References: <2a6929c5-72fa-4d84-953a-44ea4597ab38@googlegroups.com> NNTP-Posting-Host: MyFhHs417jM9AgzRpXn7yg.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.8.3 Xref: reader01.eternal-september.org comp.lang.ada:55281 Date: 2019-01-15T10:34:18+01:00 List-Id: 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