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 autolearn=unavailable autolearn_force=no version=3.4.4 Path: backlog3.nntp.dca3.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!reality.xs3.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: spec/body/rep (Was: Compilation error (GNAT bug?)) Date: Fri, 23 May 2014 16:21:21 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <537bd591$0$6621$9b4e6d93@newsspool4.arcor-online.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1401134684 11432 69.95.181.76 (26 May 2014 20:04:44 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 26 May 2014 20:04:44 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: number.nntp.dca.giganews.com comp.lang.ada:186624 Date: 2014-05-23T16:21:21-05:00 List-Id: "Georg Bauhaus" wrote in message news:537bd591$0$6621$9b4e6d93@newsspool4.arcor-online.net... > On 20/05/14 20:43, Simon Wright wrote: >> Victor Porton writes: >> >>> package My is >>> >>> procedure C_Raptor_New_World >>> with Import => True, Convention => C, External_Name => >>> "raptor_new_world"; >>> >>> end My; >>> >>> $ gnat compile -gnat2012 my.ads >>> gcc-4.6 -c -gnat2012 my.ads >>> my.ads:4:11: aspect identifier expected >>> gnatmake: "my.ads" compilation error >>> >>> Why it does not compile? Is it a GNAT bug? >> >> No, just an old version of GNAT. GCC 4.7 fails too; 4.8 is OK. GNAT GPL >> 2011 fails; 2012 is OK. > > procedure Foo (Arg : in out T) > with > Global => ... > Pre => ... > Post => ... > Convention => ... > External_Name => ... > Linker_Options => ... > Inline; > > Some aspects, such as Linker_Options, are about things outside the > program. Linker_Options is not an aspect. Aspects apply to specific entities; one uses pragmas to specify things that apply to the entire partition. ("Configuration pragmas"). > A Convention identifier less so, it addresses any client of > package My and insofar belongs in the public part with the declaration. > Then there are aspects of still other kinds, such as Pre/Post conditions > of contracts. They cannot very well exist without their declarative item, > just like pragmatic aspect Inline, although the latter may written > separately. > > The pin board style list of aspects just lumps all of these different > kinds together after "with". > > What if the "external aspects" went elsewhere? For example, in a > representation unit. (That's a name I remember). With rep units, > the source text proper becomes more portable, and more configurable > at the same time. There is no need to change aspects in the source > text when switching environments or when changing the configuration > (Linker_Options is one example). Just pick a suitable rep unit. > Declarations also become more readable, insofar as they'd focus on > just the logic, not link names and such. Huh? A "representation unit" or whatever you call it is part of the "source text". You can't run the program without it. That's the problem with fancy project management (no matter how well-designed) -- it's part of the program (you can't build it without it), but it's outside of the language definition. (And it would be impractical to add it to the language definition.) So it causes vendor lock-in. > Representation units can provide an Ada version of dependency > injection, even when injection happens at compile time. > > In fact, GNAT already supports "outsourcing" certain aspects with the > help of project files. Do some of the other compilers do that, too? > > Since aspects are a fairly new addition to the language, chances > are that representation units will not generate backwards compatibility > issues. > > Would representation units help producing clear separation of concerns? I don't think so, mainly because you already have such a capability: constants! It's not the presence or absence of an aspect that changes, it's the value. So it might make sense to have a package specifically for the target-specific details (many systems do that, including the ACATS). For instance: package Target_Specific is -- Package for Windows. pragma Linker_Options (...); -- Data types: type Largest_Integer is range -2**31 .. 2**31 with Size => 32; type Largest_Modular is mod 2**32 with Size => 32; -- Interfacing details for package Blarch: Foo_External_Name : constant String := "..."; Bar_External_Name : constant String := "..."; ... end Target_Specific; And then have separate versions of the package for the various targets supported. I don't see any benefit to creating a new kind of unit (with the massive costs that would have for compilation systems) just to reproduce capabilities that already exist. (For what's it's worth, I don't believe that it makes sense to separate representation from other aspects (pun intended) of a declaration. All of these things have fundamental impacts on the semantics of an entity, and trying to deny that (as the Ada 83 designers attempted to) just leads to a forest of odd restrictions and complex rules designed to keep a fiction going while still allowing a simple compiler design. [The majority of the freezing rules come about because of this desire, for instance.] And it isn't even a very useful fiction. See type Largest_Integer above; if we need to give that a different size on some other target, we need to change the range, too. That's pretty common when dealing with representation.[Disclaimer: My personal views here may not be held by others, even within the ARG.]) Randy.