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!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Ada lacks lighterweight-than-task parallelism Date: Fri, 22 Jun 2018 20:53:18 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <993f28de-6a64-480b-9c6e-d9714bcdef0d@googlegroups.com> <167bec10-2a52-4c79-958d-91faadad915b@googlegroups.com> <2d6a5ab7-812f-47a9-a958-44177a3cf203@googlegroups.com> <4834588f-c891-4a34-a32d-007c91f27399@googlegroups.com> NNTP-Posting-Host: 3CrKQyqWAJZHy6zYVP/kUg.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 Content-Language: en-US X-Notice: Filtered by postfilter v. 0.8.3 Xref: reader02.eternal-september.org comp.lang.ada:53260 Date: 2018-06-22T20:53:18+02:00 List-Id: On 2018-06-22 19:06, Shark8 wrote: > On Thursday, June 21, 2018 at 10:07:01 AM UTC-6, Dmitry A. Kazakov wrote: >> On 2018-06-21 16:42, Shark8 wrote: >>> On Thursday, June 21, 2018 at 3:09:26 AM UTC-6, Dmitry A. Kazakov wrote: >>>> On 2018-06-21 02:19, Shark8 wrote: >>> Integration. >>> I don't mean "IDE" like the industry has come to think of it (editor + button-to-call-external-tool). / Think more like R-1000 on steroids, not GPS. >>> >>> The integration that you're proposing isn't going to be happening on this revision of the language, BUT we can integrate it as closely as possible in the form of an IDE, acting /as if/ there were a requirement for such integration. (And indeed, the Ada spec requires a degree of this WRT static analysis currently, so it certainly is possible to integrate these things.) >> >> I see what you mean. I think it would be difficult to do without proper >> integration. We need contracts properly inherited, e.g. in the case of >> exceptions, as well as all sorts of conditional contracts, this if that, >> I am OK if he is OK etc. Doing this outside the compiler would require >> lots of helper files gathering information from the parser, compiler, >> prover and redistributing it in all possible directions. My fear is that >> it will be impossible to handle. GPS, gprconfig, gprbuild already >> generate a dozen of such files, promptly to stumble upon. Recently I had >> a persistent compiler crash. Project cleanup didn't help. Only when I >> manually deleted all files except the sources it worked again. > > GPS, gprconfig, gprbuild, etc are irrelevant, I'm not saying we start with extant tools and methodologies. Besides the "dozens of such files" are only indicative of the lack of integration between these tools. (Arguably you could make a highly-integrated system that did use files intermediately between its tools; however, even if they were initially as a set of integrated tools, unless there was a central library handling these file-types, they would accumulate ad hock changes/improvements and thus have unbalanced development: much like dialects in real-world/natural-language.) -- Plus, as you saw these dozens of files require management. OK, it is possible to do, theoretically, but it would be a huge project and GCC is still relevant. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de