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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Your wish list for Ada 202X Date: Tue, 1 Apr 2014 10:20:41 +0200 Organization: cbb software GmbH Message-ID: <1cdsyxjzsfgzm.1synpaujysv21$.dlg@40tude.net> References: <7f1c01c5-3563-4b94-9831-152dbbf2ecdc@googlegroups.com> <8bhozh836pyt$.1qctlysud0s2q$.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: KX5nm0jf7du4gHjHR6mb/g.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:19069 Date: 2014-04-01T10:20:41+02:00 List-Id: On Mon, 31 Mar 2014 18:55:07 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:8bhozh836pyt$.1qctlysud0s2q$.dlg@40tude.net... >> On Fri, 28 Mar 2014 16:27:09 -0500, Randy Brukardt wrote: >> >>> "Dmitry A. Kazakov" wrote in message >>> news:o4o5ao9k7hz9.l7ebk8qxfv32.dlg@40tude.net... >>>> On Thu, 27 Mar 2014 16:50:20 -0500, Randy Brukardt wrote: >>> ... >>>> Real issue: Multi-methods (String vs String) and full multiple dispatch >>>> (String vs Character) >>> >>> That's an alternative, but the question is whether that can be implemented >>> with less overhead than the scheme I suggested. I believe the answer is no, >>> at least within generalized string packages (which hopefully will become >>> the norm for new string operations in Ada). >> >> If and only if the generalized packages would define operations class-wide. >> The idea is to rather make them primitive operations, so that a vendor (if >> he wanted to) could provide type-specific implementation for the cases of >> major interest, e.g. >> >> overriding function "&" (L, R : String) return String; >> >> instead of inheriting (covariantly) ineffective parent's >> >> function "&" (L, R : Root_String_Type) return Root_String_Type; > [...] > So, of course each type will define useful primitive > operations, and all of the root string operations will be primitive. In that case there will be no overhead when an operation is overridden. > It's not a question. There's no way to do that because the operations > already defined for Unbounded_String would make it ambigious if given string > literals (and all Root_String_Type'Class types would have string literals). > It would be completely unusable. When you inherit from a type you "define" inherited operations. It is not ambiguous since operations are primitive. So long there is no overloading there will be no ambiguity. >> Of course The former >> would be greatly preferable. This requires yet another feature Ada lacks - >> interface inheritance. Unbounded_String must drop parent's >> implementation/representation and inherit only the interface. > > That's not the problem at all. (The parent here would have no > representation, so there is nothing to drop.) Unbounded_String will be derived from String, or String derived from Unbounded_String. The point is to keep it a hierarchy. And the real problem with all that is that there is more than one vector of inheritance: 1. memory management (fixed, bounded, unbounded) 2. range (character, wide_character, wide_wide_character) 3. encoding (UCS-4, UCS-2, UTF-8, ASCII) > The problem is that Unbounded_String defines operations like > > function "&" (Left : Unbounded_String; Right : String) return > Unbounded_String; > > which would be ambiguous with the normal "&" if both String and > Unbounded_String had string literals (as they must for Root_String_Type to > work). No, it is unambiguous, because provided Unbounded_String is a descendant of String (or reversely) function "&" (Left : Unbounded_String; Right : String) return Unbounded_String; is a part of the implementation of the MD operation function "&" (Left, Right : Root_String_Type) return Root_String_Type; > We can't get rid of these problematical operations -- it would be way too > incompatible. So new packages is the only way to go. You can, and everything will stay compatible if the type system is fixed first (MD, MI etc). Within present type system it is indeed unfixable and moreover, new packages will likely become as messy as the old ones. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de