From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.13.198.69 with SMTP id i66mr8775613ywd.30.1480551401532; Wed, 30 Nov 2016 16:16:41 -0800 (PST) X-Received: by 10.157.37.125 with SMTP id j58mr2239132otd.18.1480551401492; Wed, 30 Nov 2016 16:16:41 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.mixmin.net!enother.net!enother.net!enother.net!peer04.fr7!futter-mich.highwinds-media.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!n6no554721qtd.0!news-out.google.com!j8ni1891qtc.0!nntp.google.com!p16no553514qta.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 30 Nov 2016 16:16:41 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=174.28.218.229; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC NNTP-Posting-Host: 174.28.218.229 References: <92ed75e9-baae-455c-9e34-53348dc6eaef@googlegroups.com> <03847fd7-5699-48de-bb3c-ef5512398f26@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Ada 2012 Constraints (WRT an Ada IR) From: Shark8 Injection-Date: Thu, 01 Dec 2016 00:16:41 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Received-Body-CRC: 2195749028 X-Received-Bytes: 4638 Xref: news.eternal-september.org comp.lang.ada:32537 Date: 2016-11-30T16:16:41-08:00 List-Id: On Wednesday, November 30, 2016 at 1:26:52 PM UTC-7, Niklas Holsti wrote: > On 16-11-30 20:28 , Shark8 wrote: >=20 > > 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. >=20 > Are you trying to revive DIANA=20 > (https://en.wikipedia.org/wiki/DIANA_(intermediate_language)) or replace= =20 > the IR's used by ASIS implementations=20 > (https://en.wikipedia.org/wiki/Ada_Semantic_Interface_Specification)? >=20 > Or are those too close to the source-code level for you, and your IR=20 > 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 ab= out meta-programming upon Ada -- something that would abstract things so th= at, say, Ada.[wide_[wide_]]strings could all share the same code/descriptio= n/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 retriev= al/regeneration so highly; (b) it was defined as an ADT, but not particular= ly 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 add= ressed by having a "CPAN-like tool" that uses the IR, essentially relegatin= g to generation of consumable source-text to a pretty-printer function/prog= ram. I simply see a lot of advantage in a good "universal Ada theory" and DB-ami= able intermediate representation. ----------------- ^1 -- DIANA Reference Manual (Rev 3) ch 1 intro paragraph 3 AND 1.1 [parag= raph 2] vs the given DIANA package as an example in 4.6 of this PDF: http:/= /www.dtic.mil/get-tr-doc/pdf?AD=3DADA128232 rather than using a more generi= c approach. (Such as "type NODE(<>) is private;" w/ "function ARITY( N : NO= DE ) 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/Programmin= g] industry's adoption of inferior systems. (e.g. C with preprocessor #incl= ude instead of an actual module-system.) NOTE: There's a draft of revision 4 here: http://www.dtic.mil/cgi-bin/GetTR= Doc?Location=3DU2&doc=3DGetTRDoc.pdf&AD=3DADA272792