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!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: ADA.STRINGS.INDEX_ERROR : a-strunb.adb:782 Date: Mon, 22 Jan 2018 18:44:18 -0600 Organization: JSA Research & Innovation Message-ID: References: <7e895632-e0f9-4035-a0a3-1a31a262c8b3@googlegroups.com> <6e4679ff-6058-40ec-821a-791507313906@googlegroups.com> Injection-Date: Tue, 23 Jan 2018 00:44:18 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="3328"; mail-complaints-to="news@jacob-sparre.dk" 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.7246 Xref: reader02.eternal-september.org comp.lang.ada:50058 Date: 2018-01-22T18:44:18-06:00 List-Id: "Dmitry A. Kazakov" wrote in message news:p3v378$1mqo$1@gioia.aioe.org... > On 2018-01-20 01:42, Randy Brukardt wrote: ... >> A type parameter clearly would have to pass the subtype information as >> well, > > Yes, like it does with array bounds, *if* it were a subprogram proper. > This is irrelevant because it is not a subprogram, it only has a syntax of > a subprogram call. But for the compiler it is a special case exactly like > it is when the attribute syntax is used, or any other syntax. The > detection does not require special syntax, that is the point. Once the > compiler detects the case, the magic starts to work. Actually, a "special case" that uses typical syntax is not special at all, as a compiler has to start with recognizing and interpreting the normal syntax. In order to do that for Ada, one would have to have meta-types in order that the techniques would work with the resolution rules. It could be similar to the rules for universal_integer (needed to allow compile-time type-less expressions), but there would have to be something. Yes, of course such special cases are not a problem for code generation/execution -- indeed, a "subprogram call" is just a mess of special cases to the point that there hardly is a "normal" case. (Remember that operators are "subprogram calls" in Ada, so many programs have more special cases than they do usual calls.) ... >> (And I >> don't see why you don't think it is related, either. One has to have some >> mechanism for getting this information, and if you eliminate the special >> mechanism for that, some replacement is needed. In the proposed language, >> only a subprogram call is available, unless some other special syntax is >> invented, which is just kicking the can.) > > It is the same mechanism used to pass/eliminate array bounds. ??? For Janus/Ada, at least, the array bounds ARE the object; the compiler only pays attention to the array data when it is directly accessed. (There is a pointer to the data stored with the bounds.) There is no separate "array bounds" mechanism; it is all tied to the subtype conversion mechanism. One would need a separate mechanism to pass bounds by themselves -- not particular hard to do, but it would need a data type to represent "array bounds without any data". > It could be generalized for all types including non-tagged classes. The > type tag of a non-tagged type is a [sub]type constraint to be passed or > not. The same case is represented by dimensioned values. The dimension is > a constraint, again passed or not down to the subprogram, kept or not in > an instance. > > I think it is possible to design common rules for all this and make the > language quite simple. As before, I don't doubt this. I do doubt that it could be done with an acceptable level of compatibility. The additional overloading of subtypes needed would certainly cause ambiguities and care would have to be taken to avoid beaujolias effects. If one was abandoning compatibility here altogether, then of course you are right -- and objects/exceptions should be overloadable to greatly reduce the visibility issues that come from use clauses -- and probably a dozen other minor fixes (like redoing renames so that static matching is required rather than ignoring the subtypes) should be done too. But that's not very likely to happen. Randy.