Re: spec/body/rep (Was: Compilation error (GNAT bug?))

["Randy Brukardt" <randy@rrsoftware.com>]

"Georg Bauhaus" <rm-host.bauhaus@maps.futureapps.de> wrote in message 
news:537bd591$0$6621$9b4e6d93@newsspool4.arcor-online.net...
> On 20/05/14 20:43, Simon Wright wrote:
>> Victor Porton <porton@narod.ru> 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.