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=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,735c710b5e547bad X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.66.85.162 with SMTP id i2mr1775972paz.30.1343312935377; Thu, 26 Jul 2012 07:28:55 -0700 (PDT) MIME-Version: 1.0 Path: b9ni64759856pbl.0!nntp.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nx01.iad01.newshosting.com!newshosting.com!82.197.223.106.MISMATCH!feeder1.cambriumusenet.nl!feeder3.cambriumusenet.nl!feed.tweaknews.nl!94.232.116.13.MISMATCH!feed.xsnews.nl!border-3.ams.xsnews.nl!newsfeed.straub-nv.de!news.swapon.de!newsfeed.x-privat.org!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Ada 2005 puzzle Date: Mon, 23 Jul 2012 21:38:30 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <1arp60wtxes8h$.1qs6bt732ztgp.dlg@40tude.net> <030cde76-7435-405d-9f12-ac7f730ecab8@googlegroups.com> <1f9q6vk5z2r3t$.1hayo9rmxfwu7$.dlg@40tude.net> <1agfifqlayl3y.1bp09z5i37ewk$.dlg@40tude.net> <1nnq1oprn6h4f.1s5myl3oupdds$.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1343097519 3959 69.95.181.76 (24 Jul 2012 02:38:39 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 24 Jul 2012 02:38:39 +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 Date: 2012-07-23T21:38:30-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:1nnq1oprn6h4f.1s5myl3oupdds$.dlg@40tude.net... > On Fri, 20 Jul 2012 19:04:05 -0500, Randy Brukardt wrote: > >> "Dmitry A. Kazakov" wrote in message >> news:1agfifqlayl3y.1bp09z5i37ewk$.dlg@40tude.net... >>> On Thu, 19 Jul 2012 21:22:27 -0500, Randy Brukardt wrote: >> ... >>>> The ARG isn't going to do anything unless real users (like yourself) >>>> report >>>> reasonable examples that don't appear to be possible with the current >>>> rules. >>>> Generally, we're not interested in *solutions* from the public (we're >>>> happy >>>> to figure out the best solution for the language as a whole), but we >>>> are >>>> interested in *problems*. >>> >>> The problem is just same it was when ARG invented limited aggregates and >>> function returns. >> >> Sorry, I meant *specific* examples of useful things that you cannot find >> a >> legal way to write. > > The example I posted illustrates the problem as found in original code, > which is too large and proprietary anyway. The example you posted would be just fine as an example of a real-world problem. >> No one is likely to be that interested in philosophical concerns. > > Huh, what were *specific* examples caused ARG to accept limited aggregates > and functions? I couldn't tell you all of them off-hand (go look at the appropriate AIs). Certainly the problems I had defining the (constant) registry keys in Claw fed into it; I know that I showed the difficulty it detail where we started discussing the problem. And the original problem was the inability to define limited constants. The rest of it grew from there. >>>> So far as (most) of the ARG is aware, there is no problem with this >>>> feature, >>>> and in the absence of reports of real problems I doubt that anything >>>> will >>>> change. >>> >>> You could simply say that you agree/disagree with the principle. >> >> I actually see little wrong with the Ada model. > > Rightness here would mean conformance to the principle that a limited > aggregate were *always* possible to write when the nearest non-abstract > ancestor had visible constructing function, or something else? I'm not sure what exactly you mean by this principle. Please explain (and do so on Ada-Comment!). >> And the "problem" >> that you had was artifically introduced because some implementers thought >> implementing that would be hard. > > I don't understand that, I am not a language lawyer. You are. Is my > example > legal and GNAT wrong? In case it is illegal, then how do I change the > aggregate to make it legal. The example you have is illegal. But the reason it is illegal is not because there are any semantic problems with the construct -- it's illegal purely because it is difficult to implement on some compilers. That's why I want you to report this properly, because the only problem in allowing your example is to find an implementation model for those compilers. It's not at all like some problems that aren't possible in the Ada model (like a full redefinition of assignment); this one is probably easy to fix. But that won't happen if you don't complain!! >> So you need to work harder to convince me. And I'm not going to be able >> to >> do a very good job of convincing anyone else. > > Adam, another language lawyer, wrote that he was aware of the cases when > aggregates were impossible to write. That that point all alarm bells > should > start ringing, no? You can't write aggregates of private types, but those don't really make sense (you don't have visibility on the parts that you need to write an aggregate). My point being that there are plenty of aggregates that you can't write, but those don't make sense in Ada. We weren't aware of any *useful* aggregates that you can't write, but it seems that you have an example. But you're too darn bull-headed to report it appropriately. So forget it, you obviously don't really want Ada to be improved. >> As I said, we need realistic >> examples of problems that cannot be solved with the current rules. > > You would have plenty if you tried to make Claw objects limited. Working > around such aggregates is one of the worst Ada issues I have. On top of > that consider the case when the function is to return a class-wide object > constructed using such an aggregate. Actually, it was the limited registry keys that caused the existing facilities to be created. But Claw objects are not created with functions (they are initialized in an "invalid" state, and get created with procedures at some later point), so I don't think we would have run into those particular problems. The intractable problem we would have had would have been passing a window to another task. If windows were not copyable, you could only do that if you declare a library-level access type and used allocators. It would have been terrible to *require* that organization, so we went through a lot of work to make them "clone-able" instead. >> (And that isn't just addressed to you; it's really addressed to every >> user >> of Ada. Too many people work around problems without pointing out their >> language difficulties to us; we're never going to be able to fix language >> problems we don't know about!) > > People actually using Ada have deadlines to meet. The best we could do is > to record the issue and start working it around. If anybody had time to > report a problem, he would be asked for an AI. Should he spent even more > time and forged some AI, that would be discarded on whatever grounds. Not at all; we don't want feature proposals from users; we'd much rather get problem reports. And only ARG members can write AIs. As far as "discarding on whatever grounds", that happens for a variety of reasons: problem not important enough, easy workaround, proposed solution too complex for problem. We have to look at the complete picture of the effects on all Ada users, after all, not just your (or my) problems. > Don't get me wrong, I don't say this is wrong. Wrong is to expect us, Ada > programmers, doing ARG's job. We can only point out that something is > missing/wrong/difficult. The rest is up to ARG. Especially when it is > about > such fundamental issues as construction of limited objects. That's all I've asked you to do. Report the example that you posted here with some explanation as to how it came up. I'm tired of carrying everyone's elses problems to the ARG, especially when I don't understand them that well. Please do it youself. ... >>>> And if you expect me to take your problems to the ARG, let me say that >>>> they >>>> will have a lot more weight if they come from real Ada users and not >>>> just me >>>> (or Adam, or Bob, all of whom are "tainted" as implementors). >>> >>> You mean ARG is unaware that constructing functions cannot be written in >>> the cases like presented? Or that they would not believe you or Bob >>> telling >>> so? >> >> Definitely unaware -- I've never previously seen a case that couldn't be >> written with a bit of effort. > > Well, well, you knew that it did not work, but hoped that laymen could > never be able to discover that? (:-)) Not at all. You think that any human can figure out every possible use of Ada features? It's simply not possible. Some of you are using program construction patterns that we didn't think about. You need to tell us when those don't work, or we may never fund out. >> Anyway, spend a few minutes and send an example like your original one to >> Ada-Comment, and it will get discussed properly. Otherwise, don't gripe >> about it, because it surely isn't going to change. > > This is what I was afraid of, because the problem is not fixing this > particular example but to ensure that no other examples like this existed. That's of course completely impossible. Steve Baird has the role in the ARG of coming up with obscure interactions, and he very often amazes me by the things that ought to be unrelated that would have an effect. There is no way that anyone can think of every possible interaction, and those are were the trouble often lies. And we're not looking for problems; we have plenty of them that have been reported - we have plenty of work to do. If you're not willing to report problems, then they won't get fixed unless by some happy accident someone else reports the same problem. (This the same way that Janus/Ada compiler bugs get fixed; we aren't looking for them unless someone has a particular problem, or if we're rewriting something anyway. So if you don't report them, they'll never get fixed.) Randy.