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!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.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: Anonymous Access and Accessibility Levels Date: Mon, 13 May 2019 19:03:11 -0500 Organization: JSA Research & Innovation Message-ID: References: Injection-Date: Tue, 14 May 2019 00:03:12 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="24780"; 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; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader01.eternal-september.org comp.lang.ada:56306 Date: 2019-05-13T19:03:11-05:00 List-Id: "Jere" wrote in message news:a3d74466-9f8a-483f-bdd4-4752439d79f0@googlegroups.com... ... I know working in a lot of > non heap based designs (no heap on my chip), General access types > occasionally have to be used as part of the innards of some > complex type. This is reasonable... > Named access types are too restrictive and end up > requiring the use of Unchecked_Access ...and so is this. In my experience, accessibility checking buys nothing but headaches. (Static) accessibility checking was defined for the narrow case of building non-heap-based library-level structures out of a bunch of objects. It works well for that, and pretty much not at all for much else. (It has some benefit for class-wide operations where is prevents the use of non-existent types, but that's unrelated to access types at all.) > ... and in some other cases can > lead to bad designs when used. That leaves anonymous access types, > which seem incomplete. You mean "evil". :-) The problem with anonymous access types is that they require repeating important parts of the declaration over and over and over, and on top of which they can't have contracts or representation controlled. The fact that some capabilities are available *only* with them is a major fault of Ada, in my opinion, since it means that you have to chose between dynamic checking or contracts or representation control or closure ability (for subprograms). Blah! For access-to-object types, switching to anonymous access just gives you a mess of accessibility rules, the special ones for discriminants and parameters being the most interesting. The dynamic accessibility checks for parameters is primarily a hazard (if used) and useless oveerhead (if not used, which is the usual case). Moreover, dymanic accessibility checking is known not be to be implemented correctly by any existing compiler for Ada 2005 or later (a correct implementation is rather expensive). We actually considered eliminating it completely and just ruling some cases erroneous, since that is closer to actual practice, but that was eventually rejected as pushing Ada in the wrong direction. > Ada needs safe access types that are > more flexible than named access types. Sure, and we need strings that work perfectly and a bunch of other holy-grail-like things that are likely to be unacheviable in practice. Rust demonstrated that "safe access types" aren't very usable (especially as Ada already allows direct declaration of many objects that other languages only allow creating by allocation); they work for limited problems but not to build significant data structures. I'm skeptical that anything that works will be usable enough for the effort. I'd love for someone to prove me wrong on this, but I don't see it happening. The root problem is that the need for some sort of long-lived reference (critical for performance reasons, may be necessary for other reasons as well) is always going to be at odds with any sort of > They don't have to be > anonymous necessarily, but they are a gap in the language design, > especially when you are dealing with limited types, which have > no container support or similar, so the standard ways of avoiding > access types don't apply. Which of course begs the question of whether the problem really lies with limited types. Are they really worth the problems that they introduce? I know from experience (Claw makes almost all types non-limited specifically because limited types are so, well, limited) that making types non-limited that are naturally limited can be painful as well. So here I definitely don't know the right answer. (This is the case, where there are no internal access types, where a Rust-like solution does work. So perhaps it is worth having for dealing with limited objects?? But note that such a solution only works with *allocated*, pool-specific objects, so it seems unusable with environments that can't use pools.) Randy.