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: border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!gegeweb.org!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: Thu, 27 Mar 2014 16:50:20 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <7f1c01c5-3563-4b94-9831-152dbbf2ecdc@googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1395957020 3600 69.95.181.76 (27 Mar 2014 21:50:20 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 27 Mar 2014 21:50:20 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: number.nntp.dca.giganews.com comp.lang.ada:185381 Date: 2014-03-27T16:50:20-05:00 List-Id: "Shark8" wrote in message news:x9RYu.3020$XJ3.767@fx09.iad... > On 26-Mar-14 13:41, Randy Brukardt wrote: ... >> I've played with some ideas based on an abstract Root_String'Class, and >> pretty much everything necessary can be done with existing Ada 2012 >> features, and the few things that can't have a fairly obvious language >> feature that could be defined to provide them (for instance, a mechanism >> to >> support string literals). > > Hm, Really? Care to share your findings? Of course really. The rough sketch is in the !discussion of AI12-0021-1. Please note that we've never discussed this AI within the ARG, so I might be the only one interested in persuing this idea. I've fleshed it out further mentally; in particular, one could imagine supporting conversions through a common type (in this case Wide_Wide_String). The primary "problem" is that in this model, most strings become tagged and communicate using Wide_Wide_Character and Wide_Wide_String. That probably seems more inefficient than it actually is (after all, Unbounded_Strings are already tagged -- controlled, actually -- and this couldn't be less efficient than that, so long as the language-defined types stick to single inheritance). For the characters, the representation doesn't matter much (and on a 32-bit machine, they're all the same performance anyway). So the main issue is the cost of converting to-from Wide_Wide_String. Perhaps there is some other way to ensure universal convertability which doesn't require performance-sapping multiple inheritance or multidispatching. After all, if storage space is not a concern, Wide_Wide_String is the most universal (and efficient) representation. It seems that it makes the most sense to do operations in terms of that type and convert for storage -- since that's what will happen naturally most of the time. (Presuming you're not so American-centric that you don't care about anything beyond type String. :-) Anyway, lots more thought needed. Randy.