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: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!mx05.eternal-september.org!feeder.eternal-september.org!nuzba.szn.dk!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Is this expected behavior or not Date: Mon, 25 Mar 2013 17:58:26 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <99929f93-b80f-47c3-8a37-c81002733754@googlegroups.com> <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> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1364252309 10183 69.95.181.76 (25 Mar 2013 22:58:29 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 25 Mar 2013 22:58:29 +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 Xref: news.eternal-september.org comp.lang.ada:14714 Date: 2013-03-25T17:58:26-05:00 List-Id: "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). Not talking about different types here; of course, the whole point of changing anything here is to allow different representations of the data. >>>> 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. It's better to start over and obsolete the old stuff. >>>> and >>>> interface to foreign language already has to be done through special >>>> types. >>> >>> Which should certainly be in the same class! There is no semantic reason >>> why char_array should not be considered string. >> >> It won't work, semantically or implementation-wise. This is a total >> restart >> of String semantics, and the old semantics will still exist (probably in >> Annex J). There is no way to make the existing array semantics work like >> a >> tagged type, and that is absolutely necessary for dispatching to work >> (even >> if it isn't a "tagged type" in Ada terms). > > 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. (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.) 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. That's not going to be compatible with dispatching, so you would have to make quite a bit of existing types illegal if you want to truly support Untagged'Class. (We had to introduce such an incompatibility when we "fixed" equality for untagged record types, and it was very controversal. I doubt that we would risk going further.) I'm also dubious that good code can be generated for such a model, but that's a secondary concern vs. the incompatibility. ... ... >>> This is a totally bogus argument. OO imposes no overhead on specific >>> types. >> >> That's kool-aid invented by the Ada 9x team. It's not remotely true, >> especially as all usable OOP types have to be controlled. > > See above. T'Class for all types! See above -- this model is likely impossible for Ada. (It might work fine in a new language, but that's irrelevant here.) ... >> Why go further down a path to nowhere? > > Not even single step made so far. I see a lot of ad-hocks added recently > which directly influence discrete types. All these aspects, attributes > ('Read) are defined on discrete types as well. You are dragged down the > path, looking backwards... No choice. We can *add* new stuff, but changes to old stuff isn't possible. And dispatching is incompatible with untagged types, simply because Ada 83 got inheritance horribly wrong, and we're stuck with that. >>> How do I put such a reference in an array, for example? 4.1.5 would be >>> extremely difficult to use for intended purpose. >> >> It's just a tagged object, do with it what you want. I don't see why you >> think there is a problem. > > We will see. My prediction is that 4.1.5 will be very rarely used. Those > who will try it, will have to fight with language limitations imposed by > the design and then will drop it. Libraries based on it, will in turn > become difficult to use for average programmers. Too much mental overhead, > too many helper types (a bad OO-fest), too much time to find the package > where the mess resides, too much efforts to understand why the compiler > rejected obvious code... Like generics, the expectation is that hardly anyone will need to understand how it works. Just use it and get the expected semantics. And the compiler shouldn't be rejecting any obvious code unless the definition is screwed up. (That's the fault of the guru who set it up, not the user.) There are large parts of Ada that aren't really expected to be used by "mere mortals". Generics, storage pools, generalized references and indexes, iterators, etc. In all of these cases, they really exist to make library packages easier to use; most users will use these things without worrying too much about how they're implemented. I originally had a different model for 4.1.5 (most custom rules), but we determined that most of rules we needed already existed in the language. So it ended up a bit more complex (using a discriminant) in order to have far fewer new rules. That's usually a preferred trade-off. ... >>> 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? (The type being public doesn't mean that the *contents* of the type are public -- of course the target could be an Ada private type.) The whole point of this construct is to *dereference* a referential access (no special feature is needed to define a handle, after all, we've been doing that since the beginning of Ada time). >> The ONLY reason that we need 4.1.5 is so that we can assign directly >> into the target type. > > Yes, it is a hack designed for single use case. There is no other need, everything else can be done with functions and procedures. Even this assignment can be done with a procedure, but such a procedure cannot compose or support extensions. ... .... >> 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. Ensure that the code is right in the first place (admittedly hard), and use a bit of testing for acceptance. Testing never proves any sort of correctness; all of the many thousands of hours of testing on our compiler never did anything to make it more reliable -- that all happened by better design. At best, the testing just prevented reintroduction of old 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. That's a reasonable approach in some environments. But I think you'll find it's too hard to accomplish, just like it's too hard to do complete code coverage (hard to test error handlers) and it's too hard to make everything generic. I'd rather prioritize such issues, and only worry about the ones in mainline code. Randy.