Re: Ada lacks lighterweight-than-task parallelism

[Shark8 <onewingedshark@gmail.com>]

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.