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.107.156.83 with SMTP id f80mr7683488ioe.46.1480553938739; Wed, 30 Nov 2016 16:58:58 -0800 (PST) X-Received: by 10.157.15.143 with SMTP id d15mr2246471otd.2.1480553938640; Wed, 30 Nov 2016 16:58:58 -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.glorb.com!p16no568309qta.1!news-out.google.com!j8ni1940qtc.0!nntp.google.com!n6no569517qtd.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 30 Nov 2016 16:58:58 -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: <3ef819e8-55f7-4ef7-9f37-77e6abc33f98@googlegroups.com> Subject: Re: Ada 2012 Constraints (WRT an Ada IR) From: Shark8 Injection-Date: Thu, 01 Dec 2016 00:58:58 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:32539 Date: 2016-11-30T16:58:58-08:00 List-Id: On Wednesday, November 30, 2016 at 1:45:04 PM UTC-7, Dmitry A. Kazakov wrot= e: > On 2016-11-30 19:28, Shark8 wrote: >=20 > > So, with that in mind it makes sense to > > consider the usefulness of making Semantic_Analysis_Result its own > > formal language: the Intermediate Representation. >=20 > It would be difficult without making intermediate effectively target=20 > language, e.g. byte code. What you have in mind is some sort of data=20 > definition language [DDL] (operations' semantics stripped). In the sense that a program *IS* data, it certainly is a DDL. > > These properties are ideal for many applications -- one of the most > > practical to addressing some of the complaints/difficulties leveled at > > Ada (like a poor ecosystem) would be implementation of a CPAN-style > > repository... but far better -- for if we can, say, make this IR amiabl= e > > to storage in a DB (with attendant consistency-checks) we can eliminate > > the storage of invalid Ada in said repository; furthermore, because we > > have all the semantic-information already we could build-in tools to > > allow correct dependency-storage, like Gnoga using Simple Components, > > but with proper versioning so that a breaking change in a new version's > > API could be detected and the older one with the required properties > > could be retrieved. >=20 > Surely some level of introspection would be extremely helpful for=20 > distributed and persistency systems. This is true, but I don't think that ought to be the concern of the IR. -- = Insofar as a CPAN-like tool is concerned w/ the IR the major operations are= merely STORE and RETRIEVE; other functionality such as, say, tracking lice= nses or searching/indexing stored data don't involve the IR... in fact, the= only operations that would are listing the dependencies and the aforementi= oned version-control. Maybe a tool [or language for] operating on the IR would be appropriate, pe= rhaps using generic/template functionality to enable the expression of a "c= ompressed" form so that (e.g.) [[Wide_[Wide_]]String could all share common= portions and so that you could have something operating across the interfa= ces of packages, generic or not, meta-programming stuff... but that seems p= retty far outside the scope of creating an IR. > Versioning is a huge issue unresolved. I am afraid that type=20 > representation if not enough by far, because you need a lot of=20 > additional information to decide substitutablity, which is key to=20 > handling type versions. This is true, a full "bullet-proof system" would require extensive unit-tes= ts tightly coupled with the particular program/library... perhaps more than= are comfortable/practical for the hobbyist and small-business types. Requiring that level of support would be nice, from an end-user point-of-vi= ew, and certainly has appeal to me given my admiration of provability and d= esires for "the industry" to embrace better practices... but that would req= uire *MUCH* more work, and hamper ease-of-use [to the point of hampering us= ability itself, I suspect] on the program/library uploader. As much as I like "completely correct", versioning at the CPAN-like-reposit= ory level should probably be restricted to the public interface. (Essential= ly the analog of "can it compile?" asked of a prolog program with the sets = of modules involved, starting with the most-recent versions and backtrackin= g until the solution is found.) > >>>>> No, I really don't. > >>>>> I'm not talking about Ada-syntax, > >>>> > >>>> Yes you do, covariance vs. contravariance is semantics, not syntax. > >>> > >>> Maybe I'm misunderstanding. > >>> I simply don't see how covariance vs. contravariance is at all > >>> germane to representing the definition of a type. > >> > >> It is relevant to the difference between Ada 83 style constrained type= s > >> and constrained types introduced by predicates. Ada 83 constraints are > >> more consistent because they took into account operations that must be > >> covariant. E.g. adding to the list of examples: > >> > >> subtype Text is String (1..80); > >> > >> That overrides 'First, 'Last, 'Range, 'Length and propagates the > >> constraint to other types by promoting Text definite. None of this > >> happens if you add a predicate because all operations are inherited > >> as-is =3D contravariant. > > > > And shouldn't that (eg Predicated_Subtype'Pred or 'Last, etc) be > > caught by the semantic-analysis phase? If so, then it's entirely a moot > > point, isn't it? >=20 > The compiler cannot read minds. The information that the semantics of=20 > 'Pred must be changed (and thus the operation becomes covariant) is=20 > nowhere to get. Of course it is, it's in the set of operations available to the subtype... = imagine extending the ability to add constraints to values, but with operat= ions. It is, in a very general sense, the same thing -- the values a type h= as are a set, the operations a type has are a set: if we can exclude items = from the value-set, why can't we exclude operations from the operation-set? > In the model of tagged types covariance is the default.=20 > In the model of added predicates it is contravariance the default.=20 > Ada-83 subtypes mix contravariance and covariance by hardwired rules. Then wouldn't a way to represent both be applicable to representing an Ada-= 83 type? > > But it certainly doesn't invalidate the concept of considering a > > type [and subtype] as the collection of a set of values and a set of > > operations on those values; for example: > > > > Type Nybble is range 0..15 with Size =3D> 4; > > Subtype Prime_Nybble is Nybble with > > Static_Predicate =3D> Prime_Nybble in 2|3|5|7|11|13; > > > > could be represented as something which visualized-as-text would be: > > > > Nybble is > > Size : Bits(4) > > Internal_Values : Set(0..15) > > Offset : 0 -- So we could represent 1..16 w/ 4-bi= ts > > Operations : Arithmetic_ops & Scalar_Attributes > > > > > > Prime_Nybble modifying Nybble is > > Operations : Operations without Scalar_Attributes > > > > or somesuch. >=20 > You describe here DDL and leave all semantics of the operations aside. Are the semantics needed when semantic validity has been ensured by the sem= antic-analysis phase?=20 > Prime numbers do not have arithmetic because arithmetic operations on=20 > primes do not yield a prime. A semantically correct choice for "+" is=20 > either leave it contravariant: >=20 > function "+" (Left, Right : Prime) return Universal_Integer; >=20 > or drop it >=20 > function "+" (Left, Right : Prime) return Prime is abstract; Or we could simply assume Ada's model w/ subtypes. (i.e. that "+"(Left, Rig= ht : Integer) Return Integer can be used for subtypes like Natural.) The IR is to model Ada programs, not behaviors. > For attributes the choices are different. It depends on the properties=20 > of the mathematical structure the [sub]type is to model. There is no way= =20 > the language could decide that. It can for built-in types, because they= =20 > are built-in. >=20 > [...] >=20 > > Does that clear things up? >=20 > Yes, you are under the delusion that DDL is a type system. It is not,=20 > DDL is weakly/untyped and as such is fundamentally incapable to describe= =20 > Ada type system, not even in first approximation. No, you misunderstand -- my thought is that the Ada type-system (insofar as= defining types) can be modeled in a DDL. DIANA was just such a system, an = instance of IDL, and could represent Ada's type-declarations. QED. What I'm looking for is a more unified, universal way to do so that encompa= ss constraints generally.