comp.lang.ada
 help / color / mirror / Atom feed
From: Optikos <optikos@verizon.net>
Subject: Re: Ada programmers: Edward Fish - interview
Date: Thu, 9 May 2019 15:02:44 -0700 (PDT)
Date: 2019-05-09T15:02:44-07:00	[thread overview]
Message-ID: <e97c36a2-0614-4287-8a4d-a8312f4b08a4@googlegroups.com> (raw)
In-Reply-To: <1a915f9c-2560-4668-9375-764271dfbffb@googlegroups.com>

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.

  parent reply	other threads:[~2019-05-09 22:02 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-10  7:47 Ada programmers: Edward Fish - interview Tomek Wałkuski
2019-04-26  3:17 ` Optikos
2019-04-26 16:20   ` Shark8
2019-04-26 18:52     ` Optikos
2019-04-26 22:41       ` Shark8
2019-04-27 18:37         ` Optikos
2019-05-09 22:02         ` Optikos [this message]
2019-05-10  8:06           ` Simon Wright
2019-05-10  8:50             ` tranngocduong
2019-05-12 18:25               ` Lucretia
2019-05-10 15:32             ` Optikos
2019-05-12 14:46           ` Optikos
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox