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: Teaching C/C++ from Ada perspective? Date: Thu, 5 Jul 2018 14:12:35 -0500 Organization: JSA Research & Innovation Message-ID: References: <856189aa-fa00-4960-929e-174f352310ad@googlegroups.com> <2718c8d4-5f35-4fd8-a1aa-1e60069a7a5d@googlegroups.com> <39fce60c-9f56-42fb-b679-fa08810b00ee@googlegroups.com> <3701bf07-89a5-4cb0-a704-5aebb589ca79@googlegroups.com> <2f5e4ce0-94e8-4b94-9da7-045ec90a9b22@googlegroups.com> <18554067-1382-4b43-a832-2d27aa5117d7@googlegroups.com> <8dc19505-b68a-403c-a164-f1de1864f3f1@googlegroups.com> <559657f8-bbf4-4a70-9449-f85bc98d6c6b@googlegroups.com> <590d4672-4aef-42a5-823c-57ccd291115a@googlegroups.com> <8de6b5ba-25ab-4d46-b80c-1544f43a9b05@googlegroups.com> Injection-Date: Thu, 5 Jul 2018 19:12:36 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="24674"; 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:53666 Date: 2018-07-05T14:12:35-05:00 List-Id: > On 2018-07-05 07:49, Maciej Sobczak wrote: > It's not about storage, it's about modularity of the tool set. Compiling > is not the only thing I want to do to with the source code. I need > reliable configuration management, too, and most often than not, it is > imposed on me independently on the language. Like, say, I'm told to use > Git. It does not matter whether I like Git or not, but what does matter to >me is whether I can use it seamlessly. I need to run an independent static >analysis tool, too, and if my source lives in some nebulous "library" and >needs to be regenerated only ... You're seriously confused as to how a "library" works in Ada. It has *nothing* to do with source code. Take Janus/Ada, for example. The source code lives wherever the programmer wants it, it's not in the library (unless the programmer is sloppy and uses the same direectory for both). It is given to the compiler, and it converts it to code and an Ada symboltable. The compiler *never* uses the source again; it only cares about one source file at a time and *never* uses it after the initial parsing. The information saved in the library is the semantic information needed to compile other units; it's not possible to regenerate any form of source from it (all of these steps are one way only). You keep the original source for use of other tools and possibly to modify and recompile again. Janus/Ada does keep the original source name, solely for the use of other tools (build management, debugging, etc.) None of those tools have anything to do with implementing the Ada language as described in the Standard -- they're about adding some ease-of-use to the system. You could of course put the source into such a library system (Rational did so, I think). Since Rational's system included configuration management and modeling, there wasn't a whole lot of reason to leave it. But of course that was possible if necessary. (I think that's likely for any such system - configuration management needs to be integrated with the IDE, and static analysis should [IMHO] be an integral part of any Ada compiler. So leaving it would be rare - maybe for modeling if your management is dumb enough to think there is anything to be gained there). Randy.