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.131.37 with SMTP id f37mr7047131iod.89.1480530537710; Wed, 30 Nov 2016 10:28:57 -0800 (PST) X-Received: by 10.157.17.3 with SMTP id g3mr2046053ote.8.1480530537655; Wed, 30 Nov 2016 10:28:57 -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!p16no411727qta.1!news-out.google.com!j8ni1449qtc.0!nntp.google.com!p16no411723qta.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 30 Nov 2016 10:28:57 -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> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <03847fd7-5699-48de-bb3c-ef5512398f26@googlegroups.com> Subject: Re: Ada 2012 Constraints (WRT an Ada IR) From: Shark8 Injection-Date: Wed, 30 Nov 2016 18:28:57 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:32532 Date: 2016-11-30T10:28:57-08:00 List-Id: On Wednesday, November 30, 2016 at 1:31:17 AM UTC-7, Dmitry A. Kazakov wrot= e: >=20 > BTW, "representing" is certainly irrelevant because Ada is a statically= =20 > typed language, hence, no types are ever represented in an Ada program=20 > [they are in the compiler and then the representations are thrown away]. Insofar as you can think of the Ada translator as a function of the form "F= unction Translate( Input : Source ) Return Executable_or_Library_Object;" t= hat's absolutely true... it is untrue if you are considering an IR (interme= diate representation). Now we could decompose Translate along the phases of compilation as somethi= ng perhaps like: Function Translate( Input : Source ) Return Executable_or_Library_Objec= t is ( Code_Generator(Optimizer(Semantic_Analyzer((Parser((Lexer(Source)))))= )) ); and, further, if we were to instead do something like this: Function Translate( Input : Source ) Return Executable_or_Library_Objec= t is Begin declare Semantic_Tree : constant Semantic_Analysis_Result :=3D=20 Semantic_Analyzer(Parser(Lexer(Source))); begin Semantic_Analysis_Result'Write( IR_Stream, Semantic_Tree ); Return Code_Generator(Optimizer(Semantic_Tree)); end; End Translate; The result would be that the compiler phases 'Lexer' through 'Semantic_Anal= yzer' have been "captured" into the stream IR_Stream, and it's guaranteed t= o be valid Ada (insofar as the correctness of the implementation of those p= hases are concerned) and, moreover, consistent w/ itself. We could then at = a later date read that stream into a Semantic_Analysis_Result object and co= ntinue the compilation process (optimizing and code-gen). -- So, with that = in mind it makes sense to consider the usefulness of making Semantic_Analys= is_Result its own formal language: the Intermediate Representation. Because of the properties listed above, every instance of Semantic_Analysis= _Result is valid, consistent Ada -- by uniformly representing the underlyin= g construct/concepts of the Ada-source we can severely cut down the complex= ity needed by the later stages of the compiler^1 (like, say, the DER encod= ings vs the BER encodings of ASN.1). These properties are ideal for many applications -- one of the most practic= al 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 amiable 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-infor= mation already we could build-in tools to allow correct dependency-storage,= like Gnoga using Simple Components, but with proper versioning so that a b= reaking change in a new version's API could be detected and the older one w= ith the required properties could be retrieved. > On 29/11/2016 23:59, Shark8 wrote: > > On Tuesday, November 29, 2016 at 2:06:21 PM UTC-7, Dmitry A. Kazakov wr= ote: > >> On 2016-11-29 21:51, Shark8 wrote: > >>> On Tuesday, November 29, 2016 at 1:44:43 PM UTC-7, Dmitry A. Kazakov = wrote: > >>>> On 2016-11-29 21:32, Shark8 wrote: > >>>> > >>>>> The above has a constraint -- that of only holding digits -- but > >>>>> still is unconstrained. If we were doing a formal CS class we'd sa= y something > >>>>> like "The type Serial_Number contains all strings that have only th= e > >>>>> decimal digits therein." > >>>> > >>>> You want convariance, that is a completely different beast. > >>> > >>> 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. >=20 > It is relevant to the difference between Ada 83 style constrained types= =20 > and constrained types introduced by predicates. Ada 83 constraints are=20 > more consistent because they took into account operations that must be=20 > covariant. E.g. adding to the list of examples: >=20 > subtype Text is String (1..80); >=20 > That overrides 'First, 'Last, 'Range, 'Length and propagates the=20 > constraint to other types by promoting Text definite. None of this=20 > happens if you add a predicate because all operations are inherited=20 > 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? 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 th= ose 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-bits Operations : Arithmetic_ops & Scalar_Attributes =20 Prime_Nybble modifying Nybble is Operations : Operations without Scalar_Attributes or somesuch. > >>>> It is a new > >>>> type with some operations overridden, e.g. the operation that yields= a > >>>> value of a discrete type for case statement. It is an implicit opera= tion > >>>> in Ada, yet it is an operation. It must be covariant, i.e. returning= the > >>>> new type rather than the old one for the case be satisfied with the = new > >>>> set of values. Same with already mentioned 'First, 'Last, 'Range. Or= , > >>>> for that matter, 'Succ and 'Pred if the new type has a non-contiguou= s > >>>> values set, e.g. Odd_Number. You cannot get there by merely putting = some > >>>> predicate on the assignment operation (which Ada's predicates do). T= hat > >>>> model is too weak to express such things. > >>> > >>> This is not about defining a type in Ada, it's about abstracting the > >>> making of a type [in Ada] and how best to represent _that_. > >> > >> What is abstracting making the type? > > > > Perhaps I should have used the word "defining" or "representing" instea= d of "making". >=20 > So it *is* about "defining" now? >=20 > [I still do not understand what you meant.] In some sense, yes. -- By making the IR a mapping of Ada's concepts (such a= s defining a new type, or adding constraints thereon, [ie] the particular s= ubject 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 und= erlay Ada, and (b) storing/transforming an Ada text-source in terms of thos= e concepts. Does that clear things up? -------------------------------------- ^1 -- As an example the Standard says that a renaming of a function-call an= d a constant-object initialized to that function-call are equivalent; it is= therefore quite sensible to have a single IR-construct to represent both..= . if exact source-text recovery is important then simply adding a discrimin= ant/field of "Is_Renaming : Boolean" would be enough to track source recove= ry for that construct.