Compilation error (GNAT bug?)

Compilation error (GNAT bug?)

[Victor Porton]

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?

-- 
Victor Porton - http://portonvictor.org

Re: Compilation error (GNAT bug?)

[Simon Wright]

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.

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

[Georg Bauhaus]

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. 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.

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?

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

[Randy Brukardt]

"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.

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

[J-P. Rosen]

Le 23/05/2014 23:21, Randy Brukardt a écrit :
> 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.
And to ease porting, have a package called Target_Specific_Windows,
another one called Target_Specific_Linux. All the users do:
with Target_Specific;

and have the following library-lever renaming:
with Target_Specific_Windows;
package Target_Specific renames Target_Specific_Windows;


-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

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

[Niklas Holsti]

On 14-05-27 08:16 , J-P. Rosen wrote:
> Le 23/05/2014 23:21, Randy Brukardt a écrit :
>> 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.
> And to ease porting, have a package called Target_Specific_Windows,
> another one called Target_Specific_Linux. All the users do:
> with Target_Specific;
> 
> and have the following library-lever renaming:
> with Target_Specific_Windows;
> package Target_Specific renames Target_Specific_Windows;

I don't see what advantage such as a library-level renaming gives. If
one is developing for several platforms, say Windows and Linux, there
will then be two library-level renamings somewhere, one as above and the
other using Target_Specific_Linux, but some compiler-specific way is
still needed to choose which of the library level renamings to include
in the compilation. So one could just as well call both the
target-specific packages Target_Specific, directly, and use the same
compiler-specific way to choose which one to compile. For example, I use
GNAT's ADA_INCLUDE_PATH to choose the folder ("linux" or "windows")
which contains the version of Target_Specific to be compiled.

Would there be some sense in being able to specify such library-level
renamings as configuration pragmas? This might give us a standard way to
choose component versions depending on the configuration (leaving as
compiler-specific the way to select which configuration is to be
compiled... :-)

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

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

[J-P. Rosen]

Le 27/05/2014 08:22, Niklas Holsti a écrit :
>> And to ease porting, have a package called Target_Specific_Windows,
>> > another one called Target_Specific_Linux. All the users do:
>> > with Target_Specific;
>> > 
>> > and have the following library-lever renaming:
>> > with Target_Specific_Windows;
>> > package Target_Specific renames Target_Specific_Windows;
> I don't see what advantage such as a library-level renaming gives. If
> one is developing for several platforms, say Windows and Linux, there
> will then be two library-level renamings somewhere, one as above and the
> other using Target_Specific_Linux, but some compiler-specific way is
> still needed to choose which of the library level renamings to include
> in the compilation. So one could just as well call both the
> target-specific packages Target_Specific, directly, and use the same
> compiler-specific way to choose which one to compile. For example, I use
> GNAT's ADA_INCLUDE_PATH to choose the folder ("linux" or "windows")
> which contains the version of Target_Specific to be compiled.

The way I do it, both renamings are in the same file, one of them
commented out. I just comment/uncomment the right one at the time of
build. Not fully automated, but easy, and I argue (with the C people)
that it is hardly more work than changing a global variable in a Makefile.

The point is: one single simple change in one file, and your whole
application switches OSes. The other benefit being that you see quite
well which parameters are for which OS.

But of course, it all depends on your build process, use case, and
personal taste...
-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

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

[Dmitry A. Kazakov]

On Tue, 27 May 2014 09:22:16 +0300, Niklas Holsti wrote:

> On 14-05-27 08:16 , J-P. Rosen wrote:
>> Le 23/05/2014 23:21, Randy Brukardt a écrit :
>>> 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.
>> And to ease porting, have a package called Target_Specific_Windows,
>> another one called Target_Specific_Linux. All the users do:
>> with Target_Specific;
>> 
>> and have the following library-lever renaming:
>> with Target_Specific_Windows;
>> package Target_Specific renames Target_Specific_Windows;
> 
> I don't see what advantage such as a library-level renaming gives. If
> one is developing for several platforms, say Windows and Linux, there
> will then be two library-level renamings somewhere, one as above and the
> other using Target_Specific_Linux, but some compiler-specific way is
> still needed to choose which of the library level renamings to include
> in the compilation. So one could just as well call both the
> target-specific packages Target_Specific, directly, and use the same
> compiler-specific way to choose which one to compile. For example, I use
> GNAT's ADA_INCLUDE_PATH to choose the folder ("linux" or "windows")
> which contains the version of Target_Specific to be compiled.
> 
> Would there be some sense in being able to specify such library-level
> renamings as configuration pragmas? This might give us a standard way to
> choose component versions depending on the configuration (leaving as
> compiler-specific the way to select which configuration is to be
> compiled... :-)

I have issues with this approach in general. The problem is that there is
no any check that the interfaces of the target-specific packages are same
in the sense that all target-independent clients were compilable with any
"implementation."

In my projects I, of course, use neither pragmas nor renaming. It is too
clumsy and unmaintainable. I simply put same named package into different
target-specific directories, e.g. x86/windows or i686/linux and switch them
using gpr scenario.

This does not solve the abovementioned problem, though. As a possible
solution, without introducing some huge stuff of formal package interfaces
[*], it would be enough to be able to switch only the private part of the
specification and the package body, keeping the public part same. It would
not work with target-specific constants and conditionally with-ed packages.

-----------------------
* Much needed for generic formal packages, though. But this is a different
story.

BTW, target-specific packages could be considered instances of some virtual
generic package with target as an actual parameter.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[G.B.]

On 27.05.14 10:55, Dmitry A. Kazakov wrote:
> On Tue, 27 May 2014 09:22:16 +0300, Niklas Holsti wrote:
>
>> On 14-05-27 08:16 , J-P. Rosen wrote:
>>> Le 23/05/2014 23:21, Randy Brukardt a écrit :

(I hadn't seen Randy Brukardt's original reply in my news reader,
sorry for responding late. (And I should have mentioned Link_Name,
not Linker_Options.))

>> Would there be some sense in being able to specify such library-level
>> renamings as configuration pragmas? This might give us a standard way to
>> choose component versions depending on the configuration (leaving as
>> compiler-specific the way to select which configuration is to be
>> compiled... :-)

A configuration pragma seems to have the property that
just one may cover many units, whereas library level
renamings lack this formal connection, and there may be many.
(Directories, or discipline, providing for a more or less formal
mode of development.)

When the compiler knows about "representation units" (I think Bob Duff
once mentioned such a thing using this name), and the language ties
them to (the private part of) a unit, then at least programmers will
have something explicit and reliable, issues notwithstanding:

> I have issues with this approach in general. The problem is that there is
> no any check that the interfaces of the target-specific packages are same
> in the sense that all target-independent clients were compilable with any
> "implementation."

Assuming that a universal expression of "compilability" in any
configuration is nice, but likely impossible, would you still think
that what Randy has called a semantics-denying fiction could
be preserved for some aspects? For example,

    procedure Doubled (X : in out Natural)
    with Post => (if
                    X'Old <= Natural'Last / 2
                  then
                    X = X'Old * 2
                  else
                    False),
      Import,
      External_Name => "d2";


If the External_Name aspect of Doubled were moved to
a representation unit tied to whatever Doubled lives in,
then developing the program that calls Doubled should work
up to a point, namely when Natural's representation finally
matters. And doesn't it matter now, in any case, when porting
(configuring)?

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

[Dmitry A. Kazakov]

On Tue, 27 May 2014 17:45:07 +0200, G.B. wrote:

> On 27.05.14 10:55, Dmitry A. Kazakov wrote:

>> I have issues with this approach in general. The problem is that there is
>> no any check that the interfaces of the target-specific packages are same
>> in the sense that all target-independent clients were compilable with any
>> "implementation."
> 
> Assuming that a universal expression of "compilability" in any
> configuration is nice, but likely impossible,

It is surely possible at the same level of scrutiny the language mandates
certain programs legal <=> compilable.

> would you still think
> that what Randy has called a semantics-denying fiction could
> be preserved for some aspects? For example,
> 
>     procedure Doubled (X : in out Natural)
>     with Post => (if
>                     X'Old <= Natural'Last / 2
>                   then
>                     X = X'Old * 2
>                   else
>                     False),
>       Import,
>       External_Name => "d2";
> 
> If the External_Name aspect of Doubled were moved to
> a representation unit tied to whatever Doubled lives in,

That is what I suggested. I don't care about aspects, there is no such
thing in real-life at all. There are specifications and implementations,
nothing else.

External_Name certainly belongs to the implementation as any definition of
a body does. No difference.

So if you moved it to the implementation and then switched implementations
with the targets, that will be all OK to me. Some implementations could
have a proper body of Doubled.

> then developing the program that calls Doubled should work
> up to a point, namely when Natural's representation finally
> matters.

It never matters if post-condition you wrote was meant proper
post-condition = checked at compile time.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[G.B.]

On 27.05.14 18:41, Dmitry A. Kazakov wrote:
> It never matters if post-condition you wrote was meant proper
> post-condition = checked at compile time.

I meant to refer to the effects of the rep aspects:

Import can surely break contracts, practically, if
the external entity has no notion of Natural'Last?

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

[Dmitry A. Kazakov]

On Tue, 27 May 2014 18:52:44 +0200, in comp.lang.ada you wrote:

> On 27.05.14 18:41, Dmitry A. Kazakov wrote:
>> It never matters if post-condition you wrote was meant proper
>> post-condition = checked at compile time.
> 
> I meant to refer to the effects of the rep aspects:
> 
> Import can surely break contracts, practically, if
> the external entity has no notion of Natural'Last?

No, it cannot. The contract proper is checked at compile-, latest static 
linkage-time. You cannot state a contract in terms of Natural'Last if you 
don't have Natural'Last.

The thing you used to call "contract" is merely behavior. It can be any if 
unspecified => it does not matter => nothing broken. If specified, then the 
only way to do so formally is per a contract proper. (Informal contract are 
not a language issue. They are enforced through code reviews, testing etc.)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

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

[Randy Brukardt]

"G.B." <rm-dash-bau-haus@dash.futureapps.de> wrote in message 
news:5384b302$0$6663$9b4e6d93@newsspool3.arcor-online.net...
...
> When the compiler knows about "representation units" (I think Bob Duff
> once mentioned such a thing using this name), and the language ties
> them to (the private part of) a unit, then at least programmers will
> have something explicit and reliable, issues notwithstanding:

But this solves nothing. There has to be some implementation-defined (or 
project-defined) way of selecting which "representation unit" is selected 
for a particular compilation. And that's the problem, with any of these 
solutions. (I agree with Dmitry about the problem of keeping the versions of 
the packages in sync. I believe this has to be solved by the 
version-control; one of the reasons that I find typical VCs useless is that 
they refuse to solve that problem and solve other unlikely problems 
instead.)

In any case, adding a new kind of unit would require sweeping changes to the 
language standard and to implementations. It would require a pretty 
significant problem to even consider such a change. We did in fact consider 
that for the mutually-dependent package problem, but ultimately decided to 
avoid it in favor of the "virtual" limited view solution. If we're unwilling 
to use such a solution to solve a critical problem, I can hardly imagine 
using it to solve a problem that's not hard to solve with some tools (as 
with Dmitry's project manager solution) or discipline (as in J-P's comment 
in or out of a library-level renames).

                                Randy.