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: border2.nntp.dca3.giganews.com!backlog4.nntp.dca3.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!goblin3!goblin1!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Your wish list for Ada 202X Date: Sat, 5 Apr 2014 13:10:41 +0200 Organization: cbb software GmbH Message-ID: <1aa804jg9qq4o$.wdiq33yo621l.dlg@40tude.net> References: <7f1c01c5-3563-4b94-9831-152dbbf2ecdc@googlegroups.com> <8bhozh836pyt$.1qctlysud0s2q$.dlg@40tude.net> <1cdsyxjzsfgzm.1synpaujysv21$.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: AuYlnUSfTZrfhAkRjyySpQ.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 X-Original-Bytes: 7301 Xref: number.nntp.dca.giganews.com comp.lang.ada:185557 Date: 2014-04-05T13:10:41+02:00 List-Id: On Wed, 2 Apr 2014 17:39:06 -0500, Randy Brukardt wrote: > "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). The relationship is that you can mix Unbounded_String and String in operations like "&". > There is no opportunity to share implementations, which is the other > reason to inherit one from another. Most of implementations of String can be shared by Unbounded_String. This is what people do manually all the time converting Unbounded_String to String and back. > 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. You have just said that constrained types are useless. What is the advantage of using String (1..80). It does not add any capability... >> 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. Presently 1-3 are exposed, and I don't understand how you are you going to hide them: type A (Length : Positive) is record X : String (1..Length); end record; type B is record X : Unbounded_String; end record; Looks a quite visible difference to me. > Besides, 1 can totally be defined after the fact with packages. That's the > model that I'm suggesting. This is equivalent to deriving from fixed string, which is the common denominator. > "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. But then you necessarily loose all operations String cannot have, e.g. Append, Replace, etc. The idea is of course that Unbounded_String, Unbounded_Wide_Wide_String, Unbounded_UTF8_String share this interface. >>> 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 are mixing different issues. As I said, there is no ambiguity in "&". Literals is a completely different case. They are ambiguous already. > You would have > to qualify all string literals in an MD world, and that's something > programmers would never tolerate. Ambiguity of literals can be resolved using preference rules like ones invented for Universal_Integer. We could introduce Universal_String etc. Another method could be making Latin-1 literals contravariant String, i.e. package Dont_Make_Me_Primitive is function "A" return String; function "AB" return String; function "ABC" return String; ... end Dont_Make_Me_Primitive; not inherited by Unbounded_String, Wide_String etc. That will introduce desired preference. And, yes, you will be able to assign "ABC" to Unbounded_String because ":=" is a MD operation with one body dealing with that: procedure ":=" (Left : in out Unbounded_String; Right : String); Otherwise, yes, preference rules are necessary to resolve A & B & C Between String'(A & B) & C and Unbounded_String'(A & B) & C >>> 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. An MD operation needs an N-D array indexed by tags of controlling arguments. Dispatching is indexing the array. (However there are serious problems with implementation of MD which I have no idea how to resolve. MI is much simpler) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de