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.dca3.giganews.com!backlog3.nntp.dca3.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!news.alt.net!news.mixmin.net!newsfeed.fsmpi.rwth-aachen.de!reality.xs3.de!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: Wed, 2 Apr 2014 17:39:06 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <7f1c01c5-3563-4b94-9831-152dbbf2ecdc@googlegroups.com> <8bhozh836pyt$.1qctlysud0s2q$.dlg@40tude.net> <1cdsyxjzsfgzm.1synpaujysv21$.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1396478347 12060 69.95.181.76 (2 Apr 2014 22:39:07 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 2 Apr 2014 22:39: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-Original-Bytes: 6630 Xref: number.nntp.dca.giganews.com comp.lang.ada:185465 Date: 2014-04-02T17:39:06-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:1cdsyxjzsfgzm.1synpaujysv21$.dlg@40tude.net... ... >>> 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. Why? There is no interesting relationship between String and Unbounded_String other than the interface (which is inherited from the root type). There is no opportunity to share implementations, which is the other reason to inherit one from another. Just inheriting things because something *thinks* they should be related is silly. There is no advantage to using String'Class (if such a thing existed) rather than Root_String'Class, since all the former does is restrict what your subprogram can do; it doesn't add any capability. (In any case, in my model [which is designed for minimum change to the existing Ada language], String, Wide_String, and Wide_Wide_String stay untagged array types; they have no relationship to the hierarchy of Root_String'Class, possibly other than being defined in conversions.) > 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) 1 and 3 are irrelevant, because they shouldn't have any effect on the interface -- they're things that should be totally hidden outside of streaming for 3. Perhaps 2 should have some affect on the interfaces, but that's easily handled with a second level of abtsract types defining those interfaces. Besides, 1 can totally be defined after the fact with packages. That's the model that I'm suggesting. "Unbounded_String" is a container for a Root_String'Class type; it adds unbounded memory management to whatever the string type does. There is no reason that one has to do that as part of the string abstraction. >> 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; That doesn't help at all. We still don't know which body to execute when a string literal is used, because it matches all string types. You would have to qualify all string literals in an MD world, and that's something programmers would never tolerate. >> 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. As I said before, I am skeptical that an MD system (even ignoring MI) could be implemented efficiently enough to be used in critical operations like strings. As soon as you go to MD, the linear tag model has to ba abandoned, and some sort of search mechanism used for finding bodies to dispatch to. (Why? Consider "&". There are three types involved, at least 15 variations of those types [encoding * range; many more if one thinks storage has to be involved], giving 15**3 possibilities just for that operation alone. It's obviously impractical to store that as a flat data structure, especially as most slots will be empty.) The flat tag dispatching model involves a single index into a tag data structure, almost always using a compile-time known offset [only univerally shared generics have to do something at runtime, and even that's simple]. That adds the cost of just a handful instructions and one or two extra memory reads [one to get the tag address, one to get the body address] for a dispatching call. That's almost never going to be significant, as it is dwarfed by parameter passing and the execution of the body. OTOH, if dispatching requires looking in various lookup tables to figure out where the body address is, that overhead is substantially more expensive and at least potentially begins to be a significant part of call overhead. It's possible that there are things one could do at link-time to cut such overhead (there is for MI, for instance), but that would require an all-Ada system (which is a rarity these days). I'm skeptical, but I'm not certain so I could be convinced otherwise. Randy.