Re: Ada 2012 Constraints (WRT an Ada IR)

[Shark8 <onewingedshark@gmail.com>]

On Wednesday, November 30, 2016 at 1:26:52 PM UTC-7, Niklas Holsti wrote:
> On 16-11-30 20:28 , Shark8 wrote:
> 
> > In some sense, yes. -- By making the IR a mapping of Ada's concepts
> > (such as defining a new type, or adding constraints thereon, [ie] the
> > particular subject of this thread) in a general manner we can
> > simplify some complexity of the Ada language insofar as
> > [implementations of] tools and the back-end of compilers are
> > concerned.
> >
> > But as a whole, no -- the IR is about (a) abstracting the concepts
> > that underlay Ada, and (b) storing/transforming an Ada text-source in
> > terms of those concepts.
> 
> Are you trying to revive DIANA 
> (https://en.wikipedia.org/wiki/DIANA_(intermediate_language)) or replace 
> the IR's used by ASIS implementations 
> (https://en.wikipedia.org/wiki/Ada_Semantic_Interface_Specification)?
> 
> Or are those too close to the source-code level for you, and your IR 
> would go deeper to some simpler, more uniform "theory of all Ada"?

In some sense Yes to both DIANA and the "uniform theory of Ada".

It seems to me that ASIS ought to instead be a language about a language about meta-programming upon Ada -- something that would abstract things so that, say, Ada.[wide_[wide_]]strings could all share the same code/description/definition for their common operations, perhaps with the ability to also use "interfaces upon package-specs" and such.

That's different than the thrust I'm going for; IMO, DIANA was a solid idea, but hampered by the facts that (a) they chose to rate source-code retrieval/regeneration so highly; (b) it was defined as an ADT, but not particularly presented as one^1; (c) low adoption-rate of compilers and tools.^2

The first is entirely a design-decision, and understandable. My preference is more toward a "unified theory" though. -- The third I think could be addressed by having a "CPAN-like tool" that uses the IR, essentially relegating to generation of consumable source-text to a pretty-printer function/program.

I simply see a lot of advantage in a good "universal Ada theory" and DB-amiable intermediate representation.

-----------------

^1 -- DIANA Reference Manual (Rev 3) ch 1 intro paragraph 3 AND  1.1 [paragraph 2] vs the given DIANA package as an example in 4.6 of this PDF: http://www.dtic.mil/get-tr-doc/pdf?AD=ADA128232 rather than using a more generic approach. (Such as "type NODE(<>) is private;" w/ "function ARITY( N : NODE ) return NATURAL;")

^2 -- An interesting system that did use DIANA was the R-1000; and it seems to me that the DIANA adoption was hurt by the [Computer Science/Programming] industry's adoption of inferior systems. (e.g. C with preprocessor #include instead of an actual module-system.)

NOTE: There's a draft of revision 4 here: http://www.dtic.mil/cgi-bin/GetTRDoc?Location=U2&doc=GetTRDoc.pdf&AD=ADA272792