Ada programmers: Edward Fish - interview

Ada programmers: Edward Fish - interview

[Tomek Wałkuski]

The new interview is up! Enjoy!

https://tomekw.com/ada-programmers-edward-fish/

The list of all interviews to date can be found here: https://tomekw.com/tag/interview/

Re: Ada programmers: Edward Fish - interview

[Optikos]

On Wednesday, April 10, 2019 at 2:47:31 AM UTC-5, Tomek Wałkuski wrote:
> The new interview is up! Enjoy!
> 
> https://tomekw.com/ada-programmers-edward-fish/
> 
> The list of all interviews to date can be found here: https://tomekw.com/tag/interview/

Ed/Shark8, what will it take to resume development of Byron, as mentioned in this interview?

Re: Ada programmers: Edward Fish - interview

[Shark8]

On Thursday, April 25, 2019 at 9:17:34 PM UTC-6, Optikos wrote:
> On Wednesday, April 10, 2019 at 2:47:31 AM UTC-5, Tomek Wałkuski wrote:
> > The new interview is up! Enjoy!
> > 
> > https://tomekw.com/ada-programmers-edward-fish/
> > 
> > The list of all interviews to date can be found here: https://tomekw.com/tag/interview/
> 
> Ed/Shark8, what will it take to resume development of Byron, as mentioned in this interview?

Not much: I need to finish the design document, then review and restructure/refactor (or rewrite) my archived source to be compliant with the new document.

On Thursday, April 25, 2019 at 8:47:59 PM UTC-6, Optikos wrote:
> On Wednesday, April 24, 2019 at 6:27:54 PM UTC-5, Randy Brukardt wrote:
> > "Jere" wrote in message 
> > news:ce96c027-79d6-4185-96ce-95823f637d8f of googlegroups.com...
> > ...
> > >I'm definitely aware of the HoD and its reputation.  I am a bit
> > >discourage that there is not any resource (person or written)
> > >available to help newcomers (or heck even somewhat experienced
> > >Ada programmers) with issues like these.
> > 
> > It takes quite of bit of mental effort for even an ARG member like Tucker or 
> > myself to want to even open 3.10.2. We even have a standing joke about 
> > sending in a search party if someone doesn't come back from the trip.
> > 
> > The main problem is that even an experienced hand can get confused by all of 
> > the rules and special cases, and one minor mistake can snowball into a 
> > completely wrong conclusion. It's simply not for the faint of heart.
> > 
> > I suspect that accessibility implemented by compilers is essentially 
> > whatever the ACATS tests require. I know that I've never spent time on it in 
> > Janus/Ada beyond that -- it simply isn't worth self-inflicted pain. Thus, my 
> > advice is that accessibility works like one would expect in basic cases, and 
> > do not go beyond basic cases unless you like pain.
> > 
> >                                      Randy.
> 
> It sure seems like this is a problem:  when the language definition is so complex in English prose that even standardization-committee members and compiler-authors have immense difficulty utilizing it, then perhaps that is an A#1 indicator that English prose is itself the problem.  Perhaps Algol68's two-level grammar (or analogous different programmatically-readable specification 51 years later) specifying the rich semantic behavior as mapped into syntax was a step in the right direction after all, despite blowing everyone's minds at the time 51 years ago.
> 
> Although Ada's primary problem is lack of equal-sized* or greater-sized* competitor to GNAT, Ada's second-most problem is a specification that is in natural-language prose.
> 
> * as measured by mindshare in the marketplace
> 
> Ed/Shark8, this is the niche for Byron to chart new territory (as a 2019 total rethink of what the two-level grammar tried to do in Algol68) to make a major contribution.

There's [most of] a W-Grammar for Ada83, here: https://apps.dtic.mil/docs/citations/ADA177802

A purported Semanol [Semantics Oriented Language] specification here: https://apps.dtic.mil/docs/citations/ADA091682

In addition to these, there's a paper on incremental static semantic analysis here: https://apps.dtic.mil/docs/citations/ADA604432

So, obviously, the idea isn't new — this invites some questions though:
 (a) why didn't any of these take off?
 (b) what difficulties did they encounter that may still be extant?
 (c) how much work would it be to build on any of these as opposed to all-new development?
 (d) what impacts would later standards (95, 2005, 2012, 2020) have on both the extant work as well as the ability for the underlying designs to address it?
 (e) are there modern techniques that would work better? [Note: "newer" ≠ "better".]
 (f) what *is* the best way to engineer/design a compiler for Ada?

Re: Ada programmers: Edward Fish - interview

[Optikos]

On Friday, April 26, 2019 at 11:21:00 AM UTC-5, Shark8 wrote:
> On Thursday, April 25, 2019 at 9:17:34 PM UTC-6, Optikos wrote:
> > On Wednesday, April 10, 2019 at 2:47:31 AM UTC-5, Tomek Wałkuski wrote:
> > > The new interview is up! Enjoy!
> > > 
> > > https://tomekw.com/ada-programmers-edward-fish/
> > > 
> > > The list of all interviews to date can be found here: https://tomekw.com/tag/interview/
> > 
> > Ed/Shark8, what will it take to resume development of Byron, as mentioned in this interview?
> 
> Not much: I need to finish the design document, then review and restructure/refactor (or rewrite) my
> archived source to be compliant with the new document.
> 
> On Thursday, April 25, 2019 at 8:47:59 PM UTC-6, Optikos wrote:
> > On Wednesday, April 24, 2019 at 6:27:54 PM UTC-5, Randy Brukardt wrote:
> > > "Jere" wrote in message 
> > > news:ce96c027-79d6-4185-96ce-95823f637d8f of googlegroups.com...
> > > ...
> > > >I'm definitely aware of the HoD and its reputation.  I am a bit
> > > >discourage that there is not any resource (person or written)
> > > >available to help newcomers (or heck even somewhat experienced
> > > >Ada programmers) with issues like these.
> > > 
> > > It takes quite of bit of mental effort for even an ARG member like Tucker or 
> > > myself to want to even open 3.10.2. We even have a standing joke about 
> > > sending in a search party if someone doesn't come back from the trip.
> > > 
> > > The main problem is that even an experienced hand can get confused by all of 
> > > the rules and special cases, and one minor mistake can snowball into a 
> > > completely wrong conclusion. It's simply not for the faint of heart.
> > > 
> > > I suspect that accessibility implemented by compilers is essentially 
> > > whatever the ACATS tests require. I know that I've never spent time on it in 
> > > Janus/Ada beyond that -- it simply isn't worth self-inflicted pain. Thus, my 
> > > advice is that accessibility works like one would expect in basic cases, and 
> > > do not go beyond basic cases unless you like pain.
> > > 
> > >                                      Randy.
> > 
> > It sure seems like this is a problem:  when the language definition is so complex in English prose that
> > even standardization-committee members and compiler-authors have immense difficulty utilizing it,
> > then perhaps that is an A#1 indicator that English prose is itself the problem.  Perhaps Algol68's two
> > level grammar (or analogous different programmatically-readable specification 51 years later)
> > specifying the rich semantic behavior as mapped into syntax was a step in the right direction after all,
> > despite blowing everyone's minds at the time 51 years ago.
> > 
> > Although Ada's primary problem is lack of equal-sized* or greater-sized* competitor to GNAT, Ada's
> > second-most problem is a specification that is in natural-language prose.
> > 
> > * as measured by mindshare in the marketplace
> > 
> > Ed/Shark8, this is the niche for Byron to chart new territory (as a 2019 total rethink of what the
> > two-level grammar tried to do in Algol68) to make a major contribution.
> 
> There's [most of] a W-Grammar for Ada83, here: https://apps.dtic.mil/docs/citations/ADA177802
> 
> A purported Semanol [Semantics Oriented Language] specification here:
> https://apps.dtic.mil/docs/citations/ADA091682
> 
> In addition to these, there's a paper on incremental static semantic analysis here:
> https://apps.dtic.mil/docs/citations/ADA604432
> 
> So, obviously, the idea isn't new — this invites some questions though:
>  (a) why didn't any of these take off?

Two-level grammars did not take off because they incompletely capture the entire semantic meaning of the AARM.  (Conversely, just because primary/elementary school incompletely captures entirety of mathematics doesn't mean that trigonometry and calculus don't exist or are impractical or are useless or that mathematics should be abandoned; it just means that further study is needed to get to those levels of sophistication.)

>  (b) what difficulties did they encounter that may still be extant?

Two-level grammars are unnatural for human beings to think in.  Other approaches such as Z/Zed travel a different avenue.  Other avenues might exist too.

>  (c) how much work would it be to build on any of these as opposed to all-new development?

Much effort.  But then again, GNAT expended an immense amount of effort doing it twice:
1) one transliteration of the prose into an Ada-centric semantically-annotated syntax tree written in Ada language
then once again:
2) one transliteration of the Ada-centric semantically-annotated syntax tree tree-transducer into C/C++-centric semantically-annotated tree written in C.

It seems that human beings manually transliterating the AARM twice is once too many.  (It was expedient in 1994 for GNAT because the GPL was mandated in the Air Force's contract, hence the natural conclusion of doing whatever was expedient to bolt Ada onto already-C/C++-focused GCC.  It wasn't a bad technique, given the circumstances, but Byron has no such analogous circumstances.)

>  (d) what impacts would later standards (95, 2005, 2012, 2020) have on both the extant work as well as the ability for the underlying designs to address it?

Conversely, which other languages that have analogous features (e.g., covariant OO polymorphism; parameterized types) have similar semantic definition of behavior—including academic research languages?

>  (e) are there modern techniques that would work better? [Note: "newer" ≠ "better".]

Two-level grammars seem to lack enough stepwise refinement.  Languages such as MetaOCaml embrace stepwise refinement via generators of source code (to generators of source code to … of source code, recursively).  What if Byron would take as input a) the AARM transliterated to a machine-readable encoding of its semantics in some stepwise-refinement language and b) your design document transliterated to a machine-readable encoding of its semantics in some stepwise-refinement language, and then the compiler generator stitched the 2 together, not entirely unlike AOP weavers (on steroids).  The question is:  what is that machine-readable encoding of semantics that begets several stages of stepwise refinement via programmatic-transform multistage programming á la MetaOCaml?  Is it Z/Zed on the front-end driving MetaOCaml programs as some sort of automated Vienna development method (VDM)?

Or is it TRW's SEMANOL?  Would SEMANOL+Ada sufficiently approximate Z+MetaOCaml as a stepwise-refinement multistage-programming environment for generator of code generator of … of code generator?  (What makes building GCC a pain in the patoot is that GCC has some degree of generator of code generator within its stages of compilation.  Multistage programming seems to be the nature of the beast in compiler authoring, just as it is in the operation of a finished compiler going from source code to machine code in multiple stages/passes.)

The goal of SEMANOL+Ada or Z+MetaOCaml would be to generate the existing Byron source code (as touched up as per the revised design document).  Once the generation of syntactic parser was demonstrated, generation of more-sophisticated semantics in fresh Byron source code naturally follow. 

>  (f) what *is* the best way to engineer/design a compiler for Ada?

The best way would be one that transliterates the AARM into a machine-readable semantic language (once) for then fully-automated derivation of the compiler.  I would claim that some of the “numerous passes” performed by GNAT are actually invariants that can be factored out to compiler-authoring-time instead of program-parsing-time.

Another definition of the best way would be whatever attracts people and/or funding to pioneer something new and innovative, instead of me-too and imitative.

Re: Ada programmers: Edward Fish - interview

[Shark8]

On Friday, April 26, 2019 at 12:52:46 PM UTC-6, Optikos wrote:
[snip]
> > 
> > So, obviously, the idea isn't new — this invites some questions though:
> >  (a) why didn't any of these take off?
> 
> Two-level grammars did not take off because they incompletely capture the entire semantic meaning of the AARM.

The semantic meaning is the interesting part; arguably the only part that matters — especially as I am of the opinion that text-based source-programs are absolutely the wrong way to address programming.

As I envision a whole tool-suite for Ada, it's not text that should be the "lingua franca", but rather a structured and meaningful form. (eg the intermediate representation.) -- but Byron needn't go that far, as I doubt many people would *want* to get in on a whole Integrated Development Environment.

I get a bit of intuitive feel that limiting the scope of the Byron project to the role of "compiler" (albeit keeping things 'open'/modular enough that it could be used in a real IDE) would invite more people being willing to contribute.

> >  (b) what difficulties did they encounter that may still be extant?
> 
> Two-level grammars are unnatural for human beings to think in.  Other approaches such as Z/Zed travel a different avenue.  Other avenues might exist too.

Perhaps the problem is being tied to text and textual modes of thought, as the term 'grammar' indicates, there is a great deal invested into treating programming languages in a textual-linguistic sense.

> >  (c) how much work would it be to build on any of these as opposed to all-new development?
> 
> Much effort.  But then again, GNAT expended an immense amount of effort doing it twice:
> 1) one transliteration of the prose into an Ada-centric semantically-annotated syntax tree written in Ada language
> then once again:
> 2) one transliteration of the Ada-centric semantically-annotated syntax tree tree-transducer into C/C++-centric semantically-annotated tree written in C.
> 
> It seems that human beings manually transliterating the AARM twice is once too many.

A while back, someone mentioned taking a look at "Alphard: Form and Content" -- http://libgen.io/search.php?req=978-1-4612-5979-4&lg_topic=libgen&open=0&view=simple&res=25&phrase=1&column=def / https://d-m.bksdl.xyz/download/book/5c63f88850b4253978a11370 -- I haven't had a chance to but according to wikipwdia it seems interesting/intriguing and may have some applicability here:
"Its main innovative feature was the introduction of the 'form' datatype, which combines a specification and a procedural (executable) implementation. It also took the generator from IPL-V, as well as the mapping functions from Lisp and made it general case."

> >  (d) what impacts would later standards (95, 2005, 2012, 2020) have on both the extant work as well as the ability for the underlying designs to address it?
> 
> Conversely, which other languages that have analogous features (e.g., covariant OO polymorphism; parameterized types) have similar semantic definition of behavior—including academic research languages?

I'm not sure what you're getting at here. I was entertaining the notion of a sort of executable and verifiable semantic-describing language as being appropriate here. This could be the meta-language described in the tail-end of the interview.

In the sense of the above "meaningful data-structures" perhaps this would be realized as an "execute" method on the nodes of the structure. If the structure is guaranteed to be correct (which we could do on construction) then the execution of these nodes could generate the proper parser/processing-unit.

> >  (e) are there modern techniques that would work better? [Note: "newer" ≠ "better".]
> 
> Two-level grammars seem to lack enough stepwise refinement.

Interesting.
I wonder if this could be addressed via the same technique of "parselets" that is used in this demo/tutorial of Pratt-parsers: http://journal.stuffwithstuff.com/2011/03/19/pratt-parsers-expression-parsing-made-easy/

> What if Byron would take as input a) the AARM transliterated to a machine-readable encoding of its semantics in some stepwise-refinement language and b) your design document transliterated to a machine-readable encoding of its semantics in some stepwise-refinement language, and then the compiler generator stitched the 2 together, not entirely unlike AOP weavers (on steroids).  The question is:  what is that machine-readable encoding of semantics that begets several stages of stepwise refinement via programmatic-transform multistage programming á la MetaOCaml?  Is it Z/Zed on the front-end driving MetaOCaml programs as some sort of automated Vienna development method (VDM)?

Hm, an interesting idea.
Though, I am pretty unfamiliar with AOP weavers or Vienna development method. How would these tie in together?

> Or is it TRW's SEMANOL?  Would SEMANOL+Ada sufficiently approximate Z+MetaOCaml as a stepwise-refinement multistage-programming environment for generator of code generator of … of code generator?

I have no idea; other than that abstract/paper I don't think I've seen Semanol referred to anywhere. 

> The goal of SEMANOL+Ada or Z+MetaOCaml would be to generate the existing Byron source code (as touched up as per the revised design document).

I don't know; the extant code-base isn't the greatest, and is all by-hand: mine.

> Once the generation of syntactic parser was demonstrated, generation of more-sophisticated semantics in fresh Byron source code naturally follow. 

Does it?
I'm not convinced: if we were to start/focus on capturing the semantics and rules, then I think the syntactic would follow easily, but the other way might me more difficult. Just as the write method on a stream is much easier than a read -- example: (23, Dave, 17) can be easily put in a stream as 23Dave17, but there's a problem if the data written is (21,14,13) as it produces 211413 which is itself a proper integer.

> >  (f) what *is* the best way to engineer/design a compiler for Ada?
> 
> The best way would be one that transliterates the AARM into a machine-readable semantic language (once) for then fully-automated derivation of the compiler.  I would claim that some of the “numerous passes” performed by GNAT are actually invariants that can be factored out to compiler-authoring-time instead of program-parsing-time.

I would be unsurprised if you're right about that.

> Another definition of the best way would be whatever attracts people and/or funding to pioneer something new and innovative, instead of me-too and imitative.

And there's the sticking point: absolutely none of my non-employment projects since graduation have had any other contributors. (I'm certainly no Torvalds.)

Re: Ada programmers: Edward Fish - interview

[Optikos]

On Friday, April 26, 2019 at 5:41:06 PM UTC-5, Shark8 wrote:
> On Friday, April 26, 2019 at 12:52:46 PM UTC-6, Optikos wrote:
> > Or is it TRW's SEMANOL?  Would SEMANOL+Ada sufficiently approximate Z+MetaOCaml as a stepwise-refinement multistage-programming environment for generator of code generator of … of code generator?
> 
> I have no idea; other than that abstract/paper I don't think I've seen Semanol referred to anywhere. 

There is a companion report describing much of SEMANOL(76) (i.e., 1976) for the Air Force's contract to TRW.  This was extensions to the SEMANOL(73) (i.e., 1973) that had been utilized to encode the semantics of BASIC, COBOL, PASCAL, and 2 variants of JOVIAL.  It seems that the area of extension for Ada between the 1973 to 1976 editions was concurrency semantics.
https://apps.dtic.mil/dtic/tr/fulltext/u2/a091682.pdf

Re: Ada programmers: Edward Fish - interview

[Optikos]

On Friday, April 26, 2019 at 5:41:06 PM UTC-5, Shark8 wrote:
> On Friday, April 26, 2019 at 12:52:46 PM UTC-6, Optikos wrote:
> [snip]
> > > 
> > > So, obviously, the idea isn't new — this invites some questions though:
> > >  (a) why didn't any of these take off?
> > 
> > Two-level grammars did not take off because they incompletely capture the entire semantic meaning of the AARM.
> 
> The semantic meaning is the interesting part; arguably the only part that matters — especially as I am of the opinion that text-based source-programs are absolutely the wrong way to address programming.
> 
> As I envision a whole tool-suite for Ada, it's not text that should be the "lingua franca", but rather a structured and meaningful form. (eg the intermediate representation.) -- but Byron needn't go that far, as I doubt many people would *want* to get in on a whole Integrated Development Environment.
> 
> I get a bit of intuitive feel that limiting the scope of the Byron project to the role of "compiler" (albeit keeping things 'open'/modular enough that it could be used in a real IDE) would invite more people being willing to contribute.
> 
> > >  (b) what difficulties did they encounter that may still be extant?
> > 
> > Two-level grammars are unnatural for human beings to think in.  Other approaches such as Z/Zed travel a different avenue.  Other avenues might exist too.
> 
> Perhaps the problem is being tied to text and textual modes of thought, as the term 'grammar' indicates, there is a great deal invested into treating programming languages in a textual-linguistic sense.
> 
> > >  (c) how much work would it be to build on any of these as opposed to all-new development?
> > 
> > Much effort.  But then again, GNAT expended an immense amount of effort doing it twice:
> > 1) one transliteration of the prose into an Ada-centric semantically-annotated syntax tree written in Ada language
> > then once again:
> > 2) one transliteration of the Ada-centric semantically-annotated syntax tree tree-transducer into C/C++-centric semantically-annotated tree written in C.
> > 
> > It seems that human beings manually transliterating the AARM twice is once too many.
> 
> A while back, someone mentioned taking a look at "Alphard: Form and Content" --
> http://libgen.io/search.php?req=978-1-4612-5979-4&lg_topic=libgen&open=0&view=simple&res=25&phrase=1&column=def / https://d-m.bksdl.xyz/download/book/5c63f88850b4253978a11370 -- I haven't had a chance to but according to wikipwdia it seems interesting/intriguing and may have some applicability here:
> "Its main innovative feature was the introduction of the 'form' datatype, which combines a specification
> and a procedural (executable) implementation. It also took the generator from IPL-V, as well as the
> mapping functions from Lisp and made it general case."

That was I.  Alphard and Seed7 both are inspirations for what could be Low Ada:  an Ada-esque language in which normal ISO8652 (High) Ada could be implemented as merely one instance of a new family of Ada-variant languages under the Adang umbrella.  Adang = Ada next generation.  The adangs would be the Adang family of languages that prune out something from the Low Ada implementation to then build out something new-era Ada-embracing modern post-Adaisms.  Each adang would jettison one musty crusty Ada83 axiom to permit one of the adangs to explore new programmer-usability territory that is curtailed/squelched in today's ISO8652 (High) Ada.  For example,
1) One of the adangs would jettison Algol-PL/I-Pascal begin-end syntax for the prevailing “familiarity” of C-family {} cryptosymbol syntax.
2) One of the adangs would jettison various 1970s Ichbiah-era Ada83isms whose time came & went that are standing in the way of the ARG's various AIs.
3) One of the adangs would jettison backwards-compatibility cruft that built up (e.g., all the less-than-stellar string representations) to impose the one true modern wise way on those topics.
4) One of the adangs would jettison ISO8652 Ada's lifetime management, embracing one or more other lifetime management schemes (e.g., Rust's borrow checker).
5) As 2 or more adangs achieve their goals successfully, a separate blend adang could integrate their disparate wisdom into an even bigger better adang that is the offspring of those 2 or more parent adangs (as survival of the fittest).
6) and so forth, but all of the adangs (and also ISO8652-compliant High Ada) would be implemented in terms of Low Ada, which might be its own textual language and/or which might be its own stage of code generator in a multistage code-generation of the adang family of languages, squirting out a different adang or High Ada depending on how Low Ada was tuned.  Please see MetaOCaml for more regarding N-stange multistage programming of code generators of ... of code generators.

Also Adang vaguely fits with the naming pattern of Clang and Flang precedents as LLVM-backended compiler front-ends, but solves the Ada'succ and Add++ naming challenge.

Re: Ada programmers: Edward Fish - interview

[Simon Wright]

Optikos <optikos@verizon.net> writes:

> Adang = Ada next generation

AdaNG would be *a lot* more recognisable.

Re: Ada programmers: Edward Fish - interview

[tranngocduong]

On Friday, May 10, 2019 at 3:07:01 PM UTC+7, Simon Wright wrote:
> Optikos writes:
> 
> > Adang = Ada next generation
> 
> AdaNG would be *a lot* more recognisable.

Do you mean Ada_Ng?

Re: Ada programmers: Edward Fish - interview

[Lucretia]

On Friday, 10 May 2019 09:50:59 UTC+1, tranng...@gmail.com  wrote:

> > AdaNG would be *a lot* more recognisable.
> 
> Do you mean Ada_Ng?

Wooter van Oortmerssen wrote AmigaE way back, this was one of the first AdaNG's, but it still had upper case keywords, was nice though.

Re: Ada programmers: Edward Fish - interview

[Optikos]

On Friday, May 10, 2019 at 3:07:01 AM UTC-5, Simon Wright wrote:
> Optikos writes:
> 
> > Adang = Ada next generation
> 
> AdaNG would be *a lot* more recognisable.

Outside of the Ada community, Ada as a brandname tends to a have an undeservedly bad reputation due to gossipy-spin legend & hearsay.  Unfortunately, (outside of Boeing) even inside the DoD community of defense contractors in the USA, Ada as a brandname tends to have a drastically eroded reputation compared to the vibrant fervor of 2 or 3 decades ago.  Perhaps more unrecognizability should be the goal instead of more recognizability.  Then after a fresh objective look at the goodness of Ada and its adang offspring at the language-content level, then each individual in private (instead of in propagandistic group-think mode) can have a memorable epiphany of “oh, •this• is Ada? This is clearly not at all the horrendous mess that I have always heard via hearsay”.  Note Flang (with OO and with a plethora of modern features) doesn't immediately call to mind to well-deserved horrors of Fortran IV and Fortran77.  Note that F# at Microsoft does not immediately call to mind all of OCaml's backstory in French military-defense industry.  Obfuscated* rebranding can be beneficial to a language reboot.

* provoking an epiphany days, weeks, months, or years later for those people who become in the know

In my reply above where I introduced the Adang family of multiple derivative-language adangs, I am using them emphasizing the plural more than an AdaNG •single• language as often gets discussed here on c.l.a.  In this, the adangs could have been written instead in Ada-centric notation as Ada.Children, where package-centric naming is back-applied to the family of related languages in the same same Low-Ada-based compiler/toolchain.  I almost wrote Ada.Children instead of adangs and of Adang family of languages, but I thought that it was too confusing that 1) Ada.WithCsyntax, 2) Ada.WithoutAda83isms, 3) Ada.WithoutBackwardCompatibility, 4) Ada.WithBorrowChecker, 5) Ada.HybridWithCsyntaxWithoutAda83ismsWithoutBackwardCompatibilityWithBorrowChecker, and so forth confusingly look far too much like child packages instead of variant languages.  The excessively-clever Ada-syntax pun of using child-package notation for child languages was a stretch.  (Plus it overemphasized reputation-tarnished Ada in the brandnaming.)

“Frankly, my dear Scarlet, I actually do give a dang about the Adangs.” ;-)

Re: Ada programmers: Edward Fish - interview

[Optikos]

On Thursday, May 9, 2019 at 5:02:47 PM UTC-5, Optikos wrote:
> On Friday, April 26, 2019 at 5:41:06 PM UTC-5, Shark8 wrote:
> > On Friday, April 26, 2019 at 12:52:46 PM UTC-6, Optikos wrote:
> > [snip]
> > > > 
> > > > So, obviously, the idea isn't new — this invites some questions though:
> > > >  (a) why didn't any of these take off?
> > > 
> > > Two-level grammars did not take off because they incompletely capture the entire semantic meaning of the AARM.
> > 
> > The semantic meaning is the interesting part; arguably the only part that matters — especially as I am of the opinion that text-based source-programs are absolutely the wrong way to address programming.
> > 
> > As I envision a whole tool-suite for Ada, it's not text that should be the "lingua franca", but rather a structured and meaningful form. (eg the intermediate representation.) -- but Byron needn't go that far, as I doubt many people would *want* to get in on a whole Integrated Development Environment.
> > 
> > I get a bit of intuitive feel that limiting the scope of the Byron project to the role of "compiler" (albeit keeping things 'open'/modular enough that it could be used in a real IDE) would invite more people being willing to contribute.
> > 
> > > >  (b) what difficulties did they encounter that may still be extant?
> > > 
> > > Two-level grammars are unnatural for human beings to think in.  Other approaches such as Z/Zed travel a different avenue.  Other avenues might exist too.
> > 
> > Perhaps the problem is being tied to text and textual modes of thought, as the term 'grammar' indicates, there is a great deal invested into treating programming languages in a textual-linguistic sense.
> > 
> > > >  (c) how much work would it be to build on any of these as opposed to all-new development?
> > > 
> > > Much effort.  But then again, GNAT expended an immense amount of effort doing it twice:
> > > 1) one transliteration of the prose into an Ada-centric semantically-annotated syntax tree written in Ada language
> > > then once again:
> > > 2) one transliteration of the Ada-centric semantically-annotated syntax tree tree-transducer into C/C++-centric semantically-annotated tree written in C.
> > > 
> > > It seems that human beings manually transliterating the AARM twice is once too many.
> > 
> > A while back, someone mentioned taking a look at "Alphard: Form and Content" --
> > http://libgen.io/search.php?req=978-1-4612-5979-4&lg_topic=libgen&open=0&view=simple&res=25&phrase=1&column=def / https://d-m.bksdl.xyz/download/book/5c63f88850b4253978a11370 -- I haven't had a chance to but according to wikipwdia it seems interesting/intriguing and may have some applicability here:
> > "Its main innovative feature was the introduction of the 'form' datatype, which combines a specification
> > and a procedural (executable) implementation. It also took the generator from IPL-V, as well as the
> > mapping functions from Lisp and made it general case."
> 
> That was I.  Alphard and Seed7 both are inspirations for what could be Low Ada:  an Ada-esque language in which normal ISO8652 (High) Ada could be implemented as merely one instance of a new family of Ada-variant languages under the Adang umbrella.  Adang = Ada next generation.  The adangs would be the Adang family of languages that prune out something from the Low Ada implementation to then build out something new-era Ada-embracing modern post-Adaisms.  Each adang would jettison one musty crusty Ada83 axiom to permit one of the adangs to explore new programmer-usability territory that is curtailed/squelched in today's ISO8652 (High) Ada.  For example,
> 1) One of the adangs would jettison Algol-PL/I-Pascal begin-end syntax for the prevailing “familiarity” of C-family {} cryptosymbol syntax.
> 2) One of the adangs would jettison various 1970s Ichbiah-era Ada83isms whose time came & went that are standing in the way of the ARG's various AIs.
> 3) One of the adangs would jettison backwards-compatibility cruft that built up (e.g., all the less-than-stellar string representations) to impose the one true modern wise way on those topics.
> 4) One of the adangs would jettison ISO8652 Ada's lifetime management, embracing one or more other lifetime management schemes (e.g., Rust's borrow checker).
> 5) As 2 or more adangs achieve their goals successfully, a separate blend adang could integrate their disparate wisdom into an even bigger better adang that is the offspring of those 2 or more parent adangs (as survival of the fittest).
> 6) and so forth, but all of the adangs (and also ISO8652-compliant High Ada) would be implemented in terms of Low Ada, which might be its own textual language and/or which might be its own stage of code generator in a multistage code-generation of the adang family of languages, squirting out a different adang or High Ada depending on how Low Ada was tuned.  Please see MetaOCaml for more regarding N-stange multistage programming of code generators of ... of code generators.

7) One of the adangs would jettison Algol-PL/I-Pascal BEGIN-END and LOOP syntaxes for the prevailing ML-family LET-IN syntax and tail-recursion semantics to explore Ada fully embracing every feature in the functional-programming paradigm.