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 X-Received: by 10.180.20.239 with SMTP id q15mr467212wie.7.1364295071569; Tue, 26 Mar 2013 03:51:11 -0700 (PDT) Path: border1.nntp.dca3.giganews.com!border2.nntp.dca3.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!yt3no2499205wib.0!news-out.google.com!ex12ni4237wid.1!nntp.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!ecngs!feeder2.ecngs.de!78.46.240.70.MISMATCH!weretis.net!feeder4.news.weretis.net!rt.uk.eu.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Is this expected behavior or not Date: Tue, 26 Mar 2013 11:52:36 +0100 Organization: cbb software GmbH Message-ID: <1u72u7h5j4jg3$.wlxmaltyzqik.dlg@40tude.net> References: <87ec4b1d-f7cd-49a4-8cff-d44aeb76a1ad@googlegroups.com> <78103a2f-5d19-4378-b211-1917175d5694@googlegroups.com> <3p6p8k0yfly7.ctazdw7fc5so$.dlg@40tude.net> <1jtvzi1v65aqm.1k5ejsveno59f.dlg@40tude.net> <1hvv2kd9smnfx.6spgz9thd1mh$.dlg@40tude.net> <1raubw1sk48ca$.69rdgczvnnf.dlg@40tude.net> <2qwq2cdeuvhu$.qtnb8zyhuob9$.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: FbOMkhMtVLVmu7IwBnt1tw.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Original-Bytes: 8689 Xref: number.nntp.dca.giganews.com comp.lang.ada:180776 Date: 2013-03-26T11:52:36+01:00 List-Id: On Mon, 25 Mar 2013 17:58:26 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:a96esjwiniqy$.op3wh7x9wrsl.dlg@40tude.net... >> On Fri, 22 Mar 2013 21:33:02 -0500, Randy Brukardt wrote: > ... >>> That doesn't necessarily mean copying of the data. If the designer >>> of the abstraction, have put in enough smarts to share representations -- >>> after all, >> >> You should break your mental block. No shared representation, I want >> different representations for different string types. > > I was talking about sharing representations of *different* objects of the > same string type (for instance, a string variable and a slice of that > variable - that case, sharing the data might be preferred to copying it). OK, the representation would be for type-specific string objects: bounds + pointer and for class-wide string objects: tag + bounds + pointer >>>>> Slicing is already impossible for the case that we're talking about, >>>> >>>> ? >>>> >>>> Normal strings have slices and should continue to have them. >>> >>> Sure, but Root_String'Class is a separate type hierarchy. >> >> I see, yet another outhouse, also. Ada quickly becomes a shantytown... > > Unifying old junk it's possible without serious breakage of existing code, > which is intolerable. Why is it junk? There is nothing wrong with String, Wide_String, Wide_Wide_String. They should stay. Unbounded_String is indeed junk, but after adding an array interface to it = putting it into the same hierarchy it would perfectly serve the purpose. >> The way is to allow untagged T to have T'Class. This will preserve all >> semantics and all existing representations. Not even an explicit root type >> is needed, e.g. for char_array. The technique makes it possible to have >> ad-hoc supertypes, which would serve the purpose, e.g. you would define >> Put_Line on such a supertype and it will work for both String and >> char_array. Not a line changed in Standard or Interfaces.C. > > Sounds great, but it won't work in practice. You'd introduce a lot of > ambiguities and break existing code that way. Why? The effect is limited strictly to T'Class objects, which presently do not exist. > (That's why > Ada.Strings.Unbounded_String doesn't have string literals; we couldn't find > any way to add them without making most existing code using the package > ambiguous.) This is a different problem. I think the model is that string and other literals would become primitive operations. Upon inheritance in the class sense, they should be overridden or else dropped. There should be some syntax invented for handling literals, e.g, some factory operation etc. An alternative is having literals class-wide, which roughly corresponds to existing Universal_String approach. In both cases you might wish to add some preference rules [we already have some] to keep it compatible and slash ambiguities. It would be worth to consider a possibility for the user to control such preference rules and to have user-defined literals in general. > Secondly, the inheritance and overriding of untagged types is much looser > than the that of tagged types; you don't even have to use the same parameter > modes. Yes, but untagged types in the model I have in mind will remain independent types, they would not suddenly become Ada-subtypes, if you mean that. So subtype S is String ...; type Q is new String ...; would have different semantics, just like they do for tagged types already. > And dispatching is incompatible with untagged types, simply because Ada 83 > got inheritance horribly wrong, and we're stuck with that. I disagree. It seems fully compatible with Ada 83 because T'Class would be a distinct type with objects of that type. It is orthogonal to Ada-subtypes. You will not dispatch on Positive vs. Integer, these will reman specific [sub]types. In order to dispatch you will need a class-wide object of the type Integer'Class (which will be strictly same as Positive'Class, except, possibly, the constraint). That object will have the representation tag + value. For Integer and Positive objects nothing changes. We might consider redefining some existing operations to become class-wide in some arguments, but that is another story. >>>> You have a very specific use case in mind, namely containers. There is a >>>> whole world outside that, for which what you said is untrue, e.g. for >>>> smart pointers. The thing not only exposes access, it also exposes the >>>> target type. >>> >>> You have to expose the target type in order to have strong typing. How >>> could you hide it and still make type checks? >> >> Why should target type be public? > > How do you enforce strong typing without that being the case? If you don't > know what the target is, how do you determine how the resulting object can > be used? Target and handle types usually implement some public interface. E.g. type File_Access is limited interface; procedure Write (File : in out File_Access; Data : ...) is abstract; ... Somewhere else type File_Descriptor is ... limited ... and File_Access ...; Somewhere else type File_Handle is ... and File_Access ...; >>> If you really wanted to go this way, you'd put all of those types in the >>> same class. (Having every possible advantage without any disadvantages is >>> impossible.) You are right about multiple dispatch in some cases, >>> although it's usually possible to layer those: >>> >>> procedure Send (To : in out Register; Value : Data'Class); >>> >>> which is legal Ada. >> >> Sure, this is exactly how I do it. It bursts into dozens of generic >> packages and hundreds of their instances. Unless you propose to code all >> hundreds of combinations manually... How should I test THIS? > > Testing is close to worthless. But this is the only choice if your checks are dynamic. If you don't like testing then you should understand why I don't buy dynamic checks [mis]used to detect bugs. >>> That's my point about static analysis. Such a tool should be able to prove >>> that the majority of run-time checks can't happen, and give you a list of >>> those remaining. >> >> I don't need any list. Should I send it to my customers? I need the >> program fail to compile when writing analogue input. > > Treat the list as failures if you must, and insist that it be empty before > shipping. So, I need an AI system to parse compiler messages (of various vendors) on top? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de