Re: Ada++

[Optikos <ZUERCHER_Andreas@outlook.com>]

On Thursday, May 28, 2020 at 5:33:15 PM UTC-5, Jerry wrote:
> Ada++. YABL? Please discuss.
> http://www.adapplang.com/

Please forgive me for being from another planet, but for what does the B of YABL stand?
Yet Another ________ Language
botched?
fatherless-son -ized?

Quite honestly, I think it is a YAAL:  yet another Algol language like so many others because its roadmap so far seems to focus on yet another syntax for the same old stuff that we all have been regurgitating slightly differently since Algol60.

In mild support of their efforts, I would suggest that the Ada++ team go digging deep into old SIGADA and Tri-Ada academic papers at dl.acm.org (which are nearly all available at no-charge until 30 June 2020 due to Covid-19).  There are multiple old critiques and could-have would-have should-have alternative viewpoints of alternate Ada language variants that were passed over, including some variants that would have achieved another Steelman requirement or two that Ada chose not to do and that the Air Force's reviews trimmed out of Ichbiah's original more-expansive vision for Ada.  The article below is the biggest inventory of alternate variants of Ada that were discarded as proposed Green morphed into mil-standard Ada post-Steelman (and quite honestly before that and after that in this exhaustive inventory).  Plus the Ada++ team should search for the great multitude of mentionings here on c.l.a of what a next-gen Ada would fix in rusty musty crusty older parts of Ada that are less admired nowadays than Ichbiah & HOLWG considered crucial back in the 1970s.  Hint:  more radical semantic maturations than mere syntactic doo-dads here & there.  For example, greater amounts of orthogonality such as constant members of records as required in Steelman 3-3F.  As another example, resurrection of the old a.app Ada-interpreter-within-the-Ada-compiler that was in DEC/Sun Ada compilers (which itself was Ada's rethink of PL/I's #PL/I interpreter within PL/I compiler), then drastically extending a.app's capabilities for multistage programming beyond OCaml-P4's.

https://dl.acm.org/doi/pdf/10.1145/989791.989792