Re: Ada Successor Language

["Dan'l Miller" <optikos@verizon.net>]

On Friday, June 1, 2018 at 11:43:52 PM UTC-5, Shark8 wrote:
> It occurs to me that in order to design a successor to Ada, there’s not merely one language that ought to be defined — but five — and the reason is that Ada is several languages all at once: there’s a language for generics, a language for proofs [SPARK], low-level hardware, and a language for tasking in addition to the Ada that maps to “normal” programming languages.
> 	One of the frustrations about Ada as-it-is is that there is a lot that seems like it could be “folded together”, things like (eg) all the Ada.[Wide_[Wide_]]Strings packages. Or, some sort of mechanism for [explicitly] showing the relationships between types.
> 	In order to do that we would need some sort of meta-language, wherein all the rest of the languages (ideally both syntactic and semantic) could be defined.
> 
> (1)	The Meta language
> (2)	The Generic Language
> (3)	The Concurrent/Parallelism language
> (4)	The Proving language [SPARK]
> (5)	The HW/Representation language

On Saturday, June 2, 2018 at 3:12:25 AM UTC-5, Dmitry A. Kazakov wrote:
> (6)  The language of type declarations

The successor to Ada should be hypoAda
a) that allows writing today's Ada as a library/personality
and
b) that allows writing a somewhat different Ada as an alternate personality.
That way all the backwards compatibility issues can be merely labeled as historical legacy in today's Ada, not brought over to hyperAda, but expressible in hypoAda so as to support today's Ada in the same compiler.

Note that something like hyperAda would be a better working name than succAda (successor to Ada) or even Ada++ (unless the next-gen Ada was to import much of C/C++'s symbol syntax:  ++, --, &, &&, {}, and so forth).  Btw, today's Ada needs a nickname too—perhaps Ada8652 from the ISO standard number.

Seed7 (a somewhat-Ada derivative) and Alphard (Carnegie-Mellon's 1970's research language) have already explored some of these hypoAda topics.  Alphard even had a sublanguage way of writing the syntax of various language's looping constructs;  Seed7 approaches the topic differently, but accomplished much the same result.

There should be some sort of ground-rules for hyperAda so that it doesn't go far afield with, say, C-family syntax as merely being a cousin of Rust.

Byron seeks to be modular in the backend to permit LLVM or libFirm or GIMPLE-RTL.  Byron could also be modular in the ‘lower-front-end’ so to speak to permit alternative Ada-esque personalities of front-end ••in the same compiler••, choosable on the compiler's command-line, as if the Ada-esque personality ‘upper-frontend’ were a pluggable DLL to the compiler:
A) today's Ada8652
B) Ada-merged-with-SPARK
C) Pascal-family-syntaxed hyperAda, leaving backwards compatibility behind in choices A and/or B
D) even Ada(-or-hyperAda)-semantics-expressed-C-crypto-syntax instead of Pascal syntax:  Ada with braces instead of begin/end, and a hundred other syntactic transliterations
E) and so forth.