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 X-Received: by 2002:a05:6602:214c:: with SMTP id y12mr37580967ioy.245.1558269671038; Sun, 19 May 2019 05:41:11 -0700 (PDT) X-Received: by 2002:aca:ba56:: with SMTP id k83mr5434762oif.7.1558269670810; Sun, 19 May 2019 05:41:10 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!i2pn.org!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!i64no480361iti.0!news-out.google.com!p73ni482itp.0!nntp.google.com!i64no480357iti.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 19 May 2019 05:41:10 -0700 (PDT) In-Reply-To: <100ad407-090e-4316-9746-a4469568b53e@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.234.171; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.234.171 References: <100ad407-090e-4316-9746-a4469568b53e@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <64883feb-3e49-4c6a-855c-6673068e970c@googlegroups.com> Subject: Re: Ada to Ada Translator ? From: Optikos Injection-Date: Sun, 19 May 2019 12:41:11 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:56334 Date: 2019-05-19T05:41:10-07:00 List-Id: On Friday, May 17, 2019 at 9:21:57 AM UTC-5, foo wong wrote: > Hi Everyone >=20 > My name is Patrick. I have been posting here for years, I am just keep de= leting my google accounts because I don't like being spied on. >=20 > It's pretty obvious by now that Adacore is trying to make their free, ope= n source offerings commercially unfriendly, demo-ware only. >=20 > There has also been a lot of discussion about compiler bugs. >=20 > You probably already know about this but I just found Ada yacc and flex t= ools: >=20 > https://github.com/Ada-France >=20 > I only have 1 to 2 hours a week to program so I won't be able to do very = much but I think I might have a useful idea and I wanted to share it, maybe= people with more programming time will accomplish more than I can. >=20 >=20 > Why not use ayacc and aflex to create an Ada source to Ada source transla= tor. >=20 > Is there a bug Adacore won't attend to? Why not re-implement that part o= f the runtime yourself. >=20 > I don't think there are any problems with nested subprograms but let's ju= st say there was. Your could run your source through a translator that re-i= mplemented these using trampolines in pure Ada without using nested sub-pro= grams and then you could send the output to gnat. >=20 > If we all worked together, over time, we might be able to create a new Ad= a compiler that had a BSD/LGPL runtime and no more license games. >=20 > I will start this if I can, check back with me in 10 years :) >=20 > -Patrick There is OneWingedShark/Shark8's Byron partially-completed top-down LL(k) A= da-compiler parser named Byron over on GitHub. https://github.com/OneWingedShark/Byron Conversely, if you utilize Yacc & Flex, it would be LR(k) bottom-up parser,= which would be an admirable accomplishment in its own right. It is purpor= ted to be more difficult to craft meaningful error messages in LR parsers, = because LL parsers can explain in detail what was expected but, without car= e in crafting the grammar, LR parsers can lack the context to make =E2=80= =9Chmmm, it looks like you were trying to do /this/, but I found troublesom= e /that/ instead=E2=80=9D type of error messages. Writing an LR-based (i.e= ., yacc-based) parser can create an awesome fast parser, but to do so requi= res a generous amount of expanding the base language's grammar to consider = all the commonplace mistakes to build up enough context to emit that aforem= entioned type of useful error message. Without that expansion of the base = grammar into all the commonplace mistakes that the compiler-user can make, = LR grammars tend to emit low-level-detail errors that some people have trou= ble deciphering due to speaking in terms of the compiler internals instead = of speaking in terms of the language definition in the ARM. Please don't let anyone rain on your parade. If you feel an itch, go scrat= ch it. Go forth & prosper, because Ada will be better off due to your effo= rts. Conversely, there might be less-effort ways of addressing your GNAT problem= than building a new Ada compiler. 1) You could intentionally maintain your own bug database so that this kind= of condescension does not occur: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D88610 2) You could lead up a team that expands the battery of ACATS tests to whic= h Ada compilers are subjected. You could tighten the screws on quality con= trol of FSF GNAT: more ACATS tests in this #2 beget more bug reports in #1= above that get fixed in #3 below. 3) You could lead up a team that mildly forks each point release of FSF GNA= T to fix the bugs in #1's bug database above (so that your add-on work is b= ased on the latest FSF output from AdaCore, not latest GPL Community Editio= n). Then submit pull requests to your bug fixes to official FSF GNAT. Of = course, AdaCore personnel are the vast majority of the FSF official maintai= ners, so they might not accept your pull requests, but that would be too ba= d so sad for them, not you, because you would just keep building out your t= he-better-Ada-is-over-here reputation, which by its mere existence causes y= our star to shine brighter than theirs. Over time your forks could be perc= eived as the higher-quality FSF GNAT, which would cause some form of rectif= ication to occur regarding official FSF GNAT at the top-brass level (e.g., = Richard Stallman). 4) By doing #1 and #2 and #3 you could prove your claims regarding FSF GNAT= quality control by laying out your claims in meticulous detail with demons= trable evidence & bug fixes. This is likely to produce drastically quicker= results in drastically improving open-source Ada-compiler quality than bui= lding a new compiler from scratch (if LLVM backend and BSD-esque licensing = were not the top-priority goals). Or in fewer words, you could stand up to AdaCore as an equal to wrest a lit= tle control away from them by being co-pilot.