Re: Ada to Ada Translator ?

[Optikos <optikos@verizon.net>]

On Friday, May 17, 2019 at 9:21:57 AM UTC-5, foo wong wrote:
> Hi Everyone
> 
> My name is Patrick. I have been posting here for years, I am just keep deleting my google accounts because I don't like being spied on.
> 
> It's pretty obvious by now that Adacore is trying to make their free, open source offerings commercially unfriendly, demo-ware only.
> 
> There has also been a lot of discussion about compiler bugs.
> 
> You probably already know about this but I just found Ada yacc and flex tools:
> 
> https://github.com/Ada-France
> 
> 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.
> 
> 
> Why not use ayacc and aflex to create an Ada source to Ada source translator.
> 
> Is there a bug Adacore won't attend to?  Why not re-implement that part of the runtime yourself.
> 
> I don't think there are any problems with nested subprograms but let's just say there was. Your could run your source through a translator that re-implemented these using trampolines in pure Ada without using nested sub-programs and then you could send the output to gnat.
> 
> If we all worked together, over time, we might be able to create a new Ada compiler that had a BSD/LGPL runtime and no more license games.
> 
> I will start this if I can, check back with me in 10 years :)
> 
> -Patrick

There is OneWingedShark/Shark8's Byron partially-completed top-down LL(k) Ada-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 purported to be more difficult to craft meaningful error messages in LR parsers, because LL parsers can explain in detail what was expected but, without care in crafting the grammar, LR parsers can lack the context to make “hmmm, it looks like you were trying to do /this/, but I found troublesome /that/ instead” type of error messages.  Writing an LR-based (i.e., yacc-based) parser can create an awesome fast parser, but to do so requires a generous amount of expanding the base language's grammar to consider all the commonplace mistakes to build up enough context to emit that aforementioned 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 trouble 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 scratch it.  Go forth & prosper, because Ada will be better off due to your efforts.

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=88610

2) You could lead up a team that expands the battery of ACATS tests to which Ada compilers are subjected.  You could tighten the screws on quality control 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 GNAT to fix the bugs in #1's bug database above (so that your add-on work is based on the latest FSF output from AdaCore, not latest GPL Community Edition).  Then submit pull requests to your bug fixes to official FSF GNAT.  Of course, AdaCore personnel are the vast majority of the FSF official maintainers, so they might not accept your pull requests, but that would be too bad so sad for them, not you, because you would just keep building out your the-better-Ada-is-over-here reputation, which by its mere existence causes your star to shine brighter than theirs.  Over time your forks could be perceived as the higher-quality FSF GNAT, which would cause some form of rectification 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 demonstrable evidence & bug fixes.  This is likely to produce drastically quicker results in drastically improving open-source Ada-compiler quality than building 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 little control away from them by being co-pilot.