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: border2.nntp.dca.giganews.com!nntp.giganews.com!news-in-01.newsfeed.easynews.com!easynews.com!easynews!news.glorb.com!news.ecp.fr!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Your wish list for Ada 202X Date: Mon, 31 Mar 2014 18:55:07 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <7f1c01c5-3563-4b94-9831-152dbbf2ecdc@googlegroups.com> <8bhozh836pyt$.1qctlysud0s2q$.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1396310107 19221 69.95.181.76 (31 Mar 2014 23:55:07 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 31 Mar 2014 23:55:07 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Received-Bytes: 5391 Xref: number.nntp.dca.giganews.com comp.lang.ada:185439 Date: 2014-03-31T18:55:07-05:00 List-Id: "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; I don't understand how you are thinking the class-wide operations would work if everything isn't primitive. That's the only way for an Ada class-wide type to even be useful. So, of course each type will define useful primitive operations, and all of the root string operations will be primitive. (Indeed, the language definition already makes that so in the case of "&".) > Root_String_Type would be an equivalent of Wide_Wide_String or UTF8_String > or any other full Unicode character set string. "Root_String_Type" would be abstract, and the other types would be derived from it. New types corresponding to each interesting representation would be defined. The existing types would still exist but be obsolescent. ... >> Right, but that manifests itself in duplicated and overly restrictive >> packages, which would have to be reworked in order to use a more general >> interfaces. (Ada.Strings.Bounded and Ada.Strings.Unbounded in particular >> have overloaded operations that would make everything ambiguous if not >> eliminated.) > > If all string types are members of single class, then all corresponding > overloaded operations are primitive operations on the class. Overloading > of > overridden operations in guaranteed unambiguous. That is when you build a > new hierarchy of string types. Yes, of course, this is what I've proposing. > Whether Unbounded_String should become a member of this new hierarchy or > be > replaced there with a new type is another question. 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. As such, all new types is the only possibility. That's what makes this idea politically messy. > 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.) 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). Indeed, that's the only reason that Ada doesn't have a way to define string literals for a private type -- we talked about it years ago but determined that it cannot be used with any of the existing string packages. As such, it would have been a weird thing to define. We can't get rid of these problematical operations -- it would be way too incompatible. So new packages is the only way to go. Randy.