From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-2.9 required=3.0 tests=BAYES_00,NICE_REPLY_A autolearn=ham autolearn_force=no version=3.4.6 Path: eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: "J-P. Rosen" Newsgroups: comp.lang.ada Subject: Re: How to challenge a GCC patch? Date: Thu, 30 Sep 2021 08:44:49 +0200 Organization: Adalog Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Thu, 30 Sep 2021 06:44:50 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="7d29f4097bec0e630d98e9ca211f2b2a"; logging-data="23285"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+x7m0sQq5pK1Xz/Cc/WBH4" User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 Cancel-Lock: sha1:IR6TWvHp/nh3J4zcsQTukO7OT7w= In-Reply-To: Content-Language: fr Xref: reader02.eternal-september.org comp.lang.ada:62878 List-Id: Le 28/09/2021 à 08:55, Emmanuel Briot a écrit : > I must admit I fail to see your point in this thread: as far as I know, ASIS has never worked for recent versions of the language (standard was never updated), and AdaCore doesn't not evolve it anymore. Your information is not up-to-date. AdaCore has evolved its ASIS implementation to fully support up to Ada 2012, and there will be a proposal to renew the ASIS standard at ISO. Claiming that ASIS is obsolete and has not evolved since 95 is pure FUD propagated by AdaCore. Anybody can download AdaCore's latest implementation and check that Ada 2012 is fully supported. > Yes, that unfortunately means that tools like AdaControl will stop working at some point (you can certainly distribute prebuilt binaries for a while, but for anyone using new language constructs, what happens ?). AdaControl fully supports Ada 2012. Many new features of Ada 202x use aspects, which are fully supported. The main syntactic addition is the "parallel" constructs, but few people will need it, and AdaCore said once that they would not support it. > This being open-source software, you could adopt the maintenance of ASIS yourself (or ask other people in the Ada community to help with that). But this is of course a significant endeavor (then again, if you are not ready to do that yourself, why would you expect a commercial company like AdaCore to do it on your behalf ?) Because that commercial company has customers who pay for that. [...] > Going to back to a more technical discussion, would you highlight why a library like libadalang is not appropriate for AdaControl. I have developed a few code-generation tools based on it. To me, the main issue is the bad documentation, which leaves a lot of trial-and-error to find which nodes are relevant when. Besides that, it seems to be fine with any code I have sent its way. 1) the typing system. Yes, the typing system of ASIS is surprising at first sight, but extremely convenient to use. I suspect that the designers of LibAdalang never studied the rationale behind ASIS choices when they decided to make that huge hierarchy of tagged types that brings no more static checks (you still need checks at run-time that elements are appropriate for their usage), but makes a lot of things more difficult. As an example, there are plenty of simple loops in AdaControl that would need to be changed to recursive calls of special functions (one for each loop). 2) Missing features. A casual look-up showed a number of queries that I could not find. I reported to AdaCore, the response was: "yes, that's a good idea, we'll add that later". 3) Unfriendly interface. It's not only lack of documentation, the "P_" and "F_" convention makes everything harder to read, and is of no benefit to the user. Moreover, it is a matter of implementation that surfaces to the specification - very bad. Where ASIS follows strictly the terms and structure of the ARM, LibAdalang uses abbreviated names that do not even correspond the usual Ada vocabulary. And this cannot be fixed without a major, incompatible, rework. -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52 https://www.adalog.fr