Visibility problems with package instantiations.....

Visibility problems with package instantiations.....

[Petter Fryklund]

We have the following:

generic 
   type A is mod (<>);
   type B is mod (<>);
package Gen_0 is
   type C is 
      record
         AA : A;
         BB : B;
      end record;
end Gen_0;

with Gen_0;
generic
   with package Inst_0 is new Gen_0 (<>);
package Gen_1 is
   procedure X (P1 : Inst_0.C);
end Gen_1;

with Gen_0;
generic
   with package Inst_0 is new Gen_0 (<>);
   with package Inst_1 is new Gen_1 (<>);
package Gen_2 is
   procedure X (P1 : Inst_0.C);
end Gen_2;

package body Gen_2 is
   procedure X (P1 : Inst_0.C) is
   begin
      Inst_1 (P1); <---- visibility problems.
   end X;
end Gen_2;

procedure Main is 
   package Inst_0 is new Gen_0 (Interfaces.Unsigned_16, Interfaces.Unsigned_16);
   package Inst_1 is new Gen_1 (Inst_0);
   package Inst_2 is new Gen_2 (Inst_0, Inst_1);
begin
   Inst_2.X ...

Why?

Re: Visibility problems with package instantiations.....

[Dmitry A. Kazakov]

On 27 Nov 2003 07:42:40 -0800, petter.fryklund@atero.se (Petter
Fryklund) wrote:

>We have the following:
>
>generic 
>   type A is mod (<>);
>   type B is mod (<>);
>package Gen_0 is
>   type C is 
>      record
>         AA : A;
>         BB : B;
>      end record;
>end Gen_0;
>
>with Gen_0;
>generic
>   with package Inst_0 is new Gen_0 (<>);
>package Gen_1 is
>   procedure X (P1 : Inst_0.C);
>end Gen_1;
>
>with Gen_0;

+ with Gen_1; -- I suppose

>generic
>   with package Inst_0 is new Gen_0 (<>);
>   with package Inst_1 is new Gen_1 (<>);
>package Gen_2 is
>   procedure X (P1 : Inst_0.C);
>end Gen_2;
>
>package body Gen_2 is
>   procedure X (P1 : Inst_0.C) is
>   begin
>      Inst_1 (P1); <---- visibility problems.

Inst_1.X (P1); -- Probably

Provided that my assuptions are correct then Inst_1.X cannot be called
with Inst_0.C, because Inst_1.Inst_0.C and Inst_0.C are different
types, at least for the compiler. So either

1. they are not and should not be, then:

generic
   with package Inst_0 is new Gen_0 (<>);
   with package Inst_1 is new Gen_1 (<>);
package Gen_2 is
   procedure X (P1 : Inst_1.Inst_0.C);
      -- The right type is  Inst_1.Inst_0.C
end Gen_2;

2. they should be same, then

generic
   with package Inst_0 is new Gen_0 (<>);
   with package Inst_1 is new Gen_1 (Inst_0);
      -- Inst_1 shall be instantiated with Inst_0
package Gen_2 is
   procedure X (P1 : Inst_0.C);
end Gen_2;

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

Re: Visibility problems with package instantiations.....

[Petter Fryklund]

Thanks Dmitry!

Now taking this further. If Gen_3 only needs a few of the parameters
of the instantiation of Inst_2 to be correct or known, wouldn't it be
nice to be able to do:

with Gen_0;
with Gen_1; -- with 200 other parameters ....
generic
   with package Inst_0 is new Gen_0 (<>);
   with package Inst_1 is new Gen_1 (Inst_0 => Inst_0, others =>
(<>));
package Gen_2 is
   .....

Regards,
Petter

Re: Visibility problems with package instantiations.....

[Dmitry A. Kazakov]

On 28 Nov 2003 03:23:50 -0800, petter.fryklund@atero.se (Petter
Fryklund) wrote:

>Now taking this further. If Gen_3 only needs a few of the parameters
>of the instantiation of Inst_2 to be correct or known, wouldn't it be
>nice to be able to do:
>
>with Gen_0;
>with Gen_1; -- with 200 other parameters ....
>generic
>   with package Inst_0 is new Gen_0 (<>);
>   with package Inst_1 is new Gen_1 (Inst_0 => Inst_0, others =>
>(<>));
>package Gen_2 is
>   .....

Well I am not a fan of generics. Any implementation based on generics
is suspicious to my taste. That's aside.

Returning to your question, a package with 200 parameters is even more
suspicious from design point of view, than the fact of being generic.

However, there is another way to "inherit" from packages. Ada offers
child packages. For example you could make Gen_1 a child of Gen_0 to
inherit all its generic parameters.

To your proposal. It goes the direction of making generic formal
parameter profiles to closer resemble the parameter profiles of
subprograms. That's not easy. If we dig it a bit deeper, we will
discover that for example:

   procedure Foo (X : Integer; X : Float);  -- Clearly illegal

but

   generic
      with function X return Integer;
      with function X return Float;
   procedure Foo;  -- This is fine!

So any proposal concerning named associations of the generic
parameters should somehow deal with this nasty problem (at least).

BTW, true procedural types could help here, because then, one could
use qualified expressions. Alas, Ada misses them.

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

Re: Visibility problems with package instantiations.....

[Petter Fryklund]

Well 200 parameters was an overstatement trying to make a point. What
I'm doing now is moving a way from child packages partly because when
you reach level four, the filenames becomes awfully long. And also,
with two possible parents, which one should be choosen? Our CM policy
also dictates a directory structure with every unit in it's own branch
leading to a large tree. So I'm now using the chain-saw strategy with
generics. (I finally found a reasonable usage of unchecked conversion
at level four.)

I still think that it would be nice to have a "box" syntax for
parameters that aren't relevant.

Re: Visibility problems with package instantiations.....

[Dmitry A. Kazakov]

On 30 Nov 2003 23:45:51 -0800, petter.fryklund@atero.se (Petter
Fryklund) wrote:

>Well 200 parameters was an overstatement trying to make a point. What
>I'm doing now is moving a way from child packages partly because when
>you reach level four,

In my present project I have dived down 5 levels of depth! (:-))

> the filenames becomes awfully long.

Egh, that should be no problem, if you aren't under MS-DOS.

But if you are eager to save keystrokes typing Ada code, then use
package renaming:

package ABCDEF renames A.B.C.D.E.F;

>And also,
>with two possible parents, which one should be choosen?

Both! However, unfortunately, Ada supports neither multiple parents
nor multiple inheritance. They are related things.

>Our CM policy
>also dictates a directory structure with every unit in it's own branch
>leading to a large tree.

It is a reasonable policy.

>So I'm now using the chain-saw strategy with
>generics. (I finally found a reasonable usage of unchecked conversion
>at level four.)

There are very limited number of cases where use of
Unchecked_Conversion could be reasonable. (:-))

>I still think that it would be nice to have a "box" syntax for
>parameters that aren't relevant.

If you are going to make an AI on generics and send it to ARG, then
add there
 
1. defaults for generic parameters;
2. a way to resolve conflicts in generic parameter names;
3. matching the actuals of generic subroutine with omitted default
parameters [It might be backward incompatible, as Christoph Grein
pointed];
4. generic formal dispatching subroutines;
5. generic dispatching subroutines;
. . .
666. automatic instantiations;
. . .
n. user-defined generic types

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

Re: Visibility problems with package instantiations.....

[Stephen Leake]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:

> On 30 Nov 2003 23:45:51 -0800, petter.fryklund@atero.se (Petter
> Fryklund) wrote:

> >Our CM policy
> >also dictates a directory structure with every unit in it's own branch
> >leading to a large tree.
> 
> It is a reasonable policy.

Maybe for Java, which requires that directory structure anyway.

But for Ada, which has a good way to name files that indicates the
package heirarchy, directories should be used for even higher level
organization, like projects.

-- 
-- Stephe

Re: Visibility problems with package instantiations.....

[Dmitry A. Kazakov]

On 01 Dec 2003 11:31:19 -0500, Stephen Leake <Stephe.Leake@nasa.gov>
wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:
>
>> On 30 Nov 2003 23:45:51 -0800, petter.fryklund@atero.se (Petter
>> Fryklund) wrote:
>
>> >Our CM policy
>> >also dictates a directory structure with every unit in it's own branch
>> >leading to a large tree.
>> 
>> It is a reasonable policy.
>
>Maybe for Java, which requires that directory structure anyway.
>
>But for Ada, which has a good way to name files that indicates the
>package heirarchy, directories should be used for even higher level
>organization, like projects.

For a small or medium sized project one can indeed pack everything in
one directory. With hundreds of files it becomes rather difficult. So
if there is no good code management system or IDE, it becomes
reasonable to have separate directories for project branches [mapped
to packages].

BTW, maybe a stupid idea, but what if we change file naming policy
allowing:

   package A.B is ...

to be named "b.ads" IFF that is placed in a subdirectory named "a" of
the directory containing "a.ads"?

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

Re: Visibility problems with package instantiations.....

[Stephen Leake]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:

> On 01 Dec 2003 11:31:19 -0500, Stephen Leake <Stephe.Leake@nasa.gov>
> wrote:
> 
> >Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:
> >
> >> On 30 Nov 2003 23:45:51 -0800, petter.fryklund@atero.se (Petter
> >> Fryklund) wrote:
> >
> >> >Our CM policy
> >> >also dictates a directory structure with every unit in it's own branch
> >> >leading to a large tree.
> >> 
> >> It is a reasonable policy.
> >
> >Maybe for Java, which requires that directory structure anyway.
> >
> >But for Ada, which has a good way to name files that indicates the
> >package heirarchy, directories should be used for even higher level
> >organization, like projects.
> 
> For a small or medium sized project one can indeed pack everything in
> one directory. With hundreds of files it becomes rather difficult. 

Why? I don't have a problem with 280 files on Windows 2000. What sorts
of problems do you run into?

> So if there is no good code management system or IDE, it becomes
> reasonable to have separate directories for project branches [mapped
> to packages].

You are using the term "branches" in a way that is different than I'm
used to; I use it in the context of configuration management, to mean
a different development path of the same set of code; for a release,
or for an experimental new feature.

> BTW, maybe a stupid idea, but what if we change file naming policy
> allowing:
> 
>    package A.B is ...
> 
> to be named "b.ads" IFF that is placed in a subdirectory named "a" of
> the directory containing "a.ads"?

You can try that, but you have to get the compiler to support it.
That's unlikely; most require a unique file name, _independent_ of the
directory. 

-- 
-- Stephe

Re: Visibility problems with package instantiations.....

[Dmitry A. Kazakov]

On 02 Dec 2003 11:20:08 -0500, Stephen Leake <Stephe.Leake@nasa.gov>
wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:
>
>> On 01 Dec 2003 11:31:19 -0500, Stephen Leake <Stephe.Leake@nasa.gov>
>> wrote:
>> 
>> >Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:
>> >
>> >> On 30 Nov 2003 23:45:51 -0800, petter.fryklund@atero.se (Petter
>> >> Fryklund) wrote:
>> >
>> >> >Our CM policy
>> >> >also dictates a directory structure with every unit in it's own branch
>> >> >leading to a large tree.
>> >> 
>> >> It is a reasonable policy.
>> >
>> >Maybe for Java, which requires that directory structure anyway.
>> >
>> >But for Ada, which has a good way to name files that indicates the
>> >package heirarchy, directories should be used for even higher level
>> >organization, like projects.
>> 
>> For a small or medium sized project one can indeed pack everything in
>> one directory. With hundreds of files it becomes rather difficult. 
>
>Why? I don't have a problem with 280 files on Windows 2000. What sorts
>of problems do you run into?

To find a file in that huge directory. Note also that a nested package
of level 5 could have name like:

   fuzzy.graph.handle.learning.implementation.ads

It becomes a pain to navigate across this directory. It is difficult
for human eye to recognize a postfix of a long name. So one have to
separate files in some way. One possible way is to mimic the package
tree. It is a reasonable way, but not the only one.

>> So if there is no good code management system or IDE, it becomes
>> reasonable to have separate directories for project branches [mapped
>> to packages].
>
>You are using the term "branches" in a way that is different than I'm
>used to; I use it in the context of configuration management, to mean
>a different development path of the same set of code; for a release,
>or for an experimental new feature.

The difference is not that great. For example, in one of my projects,
there were many different layers of interfaces. Private, half-public,
public + their implementations in different environments. It was
reasonable to put the corresponding packages into different
directories. Then not surprisingly, the resulting directory tree
closely resembled one of the packages.

>> BTW, maybe a stupid idea, but what if we change file naming policy
>> allowing:
>> 
>>    package A.B is ...
>> 
>> to be named "b.ads" IFF that is placed in a subdirectory named "a" of
>> the directory containing "a.ads"?
>
>You can try that, but you have to get the compiler to support it.

Surely

>That's unlikely; most require a unique file name, _independent_ of the
>directory. 

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

Re: Visibility problems with package instantiations.....

[Stephen Leake]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:

> On 02 Dec 2003 11:20:08 -0500, Stephen Leake <Stephe.Leake@nasa.gov>
> wrote:
> 
> >Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:
> >
> >> On 01 Dec 2003 11:31:19 -0500, Stephen Leake <Stephe.Leake@nasa.gov>
> >> wrote:
> >> 
> >> >Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:
> >> >
> >> >> On 30 Nov 2003 23:45:51 -0800, petter.fryklund@atero.se (Petter
> >> >> Fryklund) wrote:
> >> >
> >> >> >Our CM policy
> >> >> >also dictates a directory structure with every unit in it's own branch
> >> >> >leading to a large tree.
> >> >> 
> >> >> It is a reasonable policy.
> >> >
> >> >Maybe for Java, which requires that directory structure anyway.
> >> >
> >> >But for Ada, which has a good way to name files that indicates the
> >> >package heirarchy, directories should be used for even higher level
> >> >organization, like projects.
> >> 
> >> For a small or medium sized project one can indeed pack everything in
> >> one directory. With hundreds of files it becomes rather difficult. 
> >
> >Why? I don't have a problem with 280 files on Windows 2000. What sorts
> >of problems do you run into?
> 
> To find a file in that huge directory. 

How does having multiple directories make that easier?

> Note also that a nested package of level 5 could have name like:
> 
>    fuzzy.graph.handle.learning.implementation.ads
> 
> It becomes a pain to navigate across this directory. It is difficult
> for human eye to recognize a postfix of a long name. 

Hmm. In emacs, I pull up the whole directory, then search in the
buffer.

But actually, to navigate Ada source, I don't tend to use file names;
I use Ada names, and let Emacs figure out where the files are.

> So one have to separate files in some way. One possible way is to
> mimic the package tree. It is a reasonable way, but not the only
> one.

File names that mimic the package tree are better than directories
that mimic the package tree, in my opinion. I haven't heard any solid
evidence here to contradict that.

-- 
-- Stephe

Re: Visibility problems with package instantiations.....

[Dmitry A. Kazakov]

On 03 Dec 2003 13:09:25 -0500, Stephen Leake <Stephe.Leake@nasa.gov>
wrote:

>Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:
>
>> On 02 Dec 2003 11:20:08 -0500, Stephen Leake <Stephe.Leake@nasa.gov>
>> wrote:
>> 
>> >Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:
>> >
>> >> On 01 Dec 2003 11:31:19 -0500, Stephen Leake <Stephe.Leake@nasa.gov>
>> >> wrote:
>> >> 
>> >> >Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> writes:
>> >> >
>> >> >> On 30 Nov 2003 23:45:51 -0800, petter.fryklund@atero.se (Petter
>> >> >> Fryklund) wrote:
>> >> >
>> >> >> >Our CM policy
>> >> >> >also dictates a directory structure with every unit in it's own branch
>> >> >> >leading to a large tree.
>> >> >> 
>> >> >> It is a reasonable policy.
>> >> >
>> >> >Maybe for Java, which requires that directory structure anyway.
>> >> >
>> >> >But for Ada, which has a good way to name files that indicates the
>> >> >package heirarchy, directories should be used for even higher level
>> >> >organization, like projects.
>> >> 
>> >> For a small or medium sized project one can indeed pack everything in
>> >> one directory. With hundreds of files it becomes rather difficult. 
>> >
>> >Why? I don't have a problem with 280 files on Windows 2000. What sorts
>> >of problems do you run into?
>> 
>> To find a file in that huge directory. 
>
>How does having multiple directories make that easier?

I know which directory should contain the file. And that directory is
relatively small.

>> Note also that a nested package of level 5 could have name like:
>> 
>>    fuzzy.graph.handle.learning.implementation.ads
>> 
>> It becomes a pain to navigate across this directory. It is difficult
>> for human eye to recognize a postfix of a long name. 
>
>Hmm. In emacs, I pull up the whole directory, then search in the
>buffer.
>
>But actually, to navigate Ada source, I don't tend to use file names;
>I use Ada names, and let Emacs figure out where the files are.

I see. You know, an ability to accept emacs is IMO sort of genetically
preprogrammed. (:-))

>> So one have to separate files in some way. One possible way is to
>> mimic the package tree. It is a reasonable way, but not the only
>> one.
>
>File names that mimic the package tree are better than directories
>that mimic the package tree, in my opinion. I haven't heard any solid
>evidence here to contradict that.

As a emacs user you should see little difference between:

    fuzzy-graph-handle-learning-implementation.ads

and

    fuzzy/graph/handle/learning/implementation.ads

after all one can substitute '/' for '-' in emacs.

Then, do not you feel that packing everything in one directory is
similar to packing all packages in one huge all_stuff.ada file? I mean
that if we accept the idea of mapping compilation units to files, we
should also, consequently, accept mapping of their parent-child
relations to the directory-file ones.

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

Re: Visibility problems with package instantiations.....

[Stephen Leake]

Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> writes:

> On 03 Dec 2003 13:09:25 -0500, Stephen Leake <Stephe.Leake@nasa.gov>
> wrote:
> 
> >Hmm. In emacs, I pull up the whole directory, then search in the
> >buffer.
> >
> >But actually, to navigate Ada source, I don't tend to use file names;
> >I use Ada names, and let Emacs figure out where the files are.
> 
> I see. You know, an ability to accept emacs is IMO sort of genetically
> preprogrammed. (:-))

Well, there do seem to be Emacs people and non-Emacs people. 

> >File names that mimic the package tree are better than directories
> >that mimic the package tree, in my opinion. I haven't heard any solid
> >evidence here to contradict that.
> 
> As a emacs user you should see little difference between:
> 
>     fuzzy-graph-handle-learning-implementation.ads
> 
> and
> 
>     fuzzy/graph/handle/learning/implementation.ads
> 
> after all one can substitute '/' for '-' in emacs.

Exactly; they are very much the same in readability. But, I have to
add all directories to various search lists, so it is much easier to
have only a few directories. Thus I prefer long file names over long
directory paths.

> Then, do not you feel that packing everything in one directory is
> similar to packing all packages in one huge all_stuff.ada file? 

Since the Ada compiler treats compilation units in one file much
differently than compilation units in separate files, but cares not at
all about what directories things are in, these are very different issues.

> I mean that if we accept the idea of mapping compilation units to
> files, we should also, consequently, accept mapping of their
> parent-child relations to the directory-file ones.

I accept it as a possibility, but it is simply not as nice in practice.

Java is the only language I have used that cares about directories; I
found it annoying. But if I had to use it much, I'd teach Emacs how to
deal with it efficiently (or, more likely, find an Emacs package that
someone else has written that does that). Then I wouldn't notice
anymore. The same could be done for Ada, of course, if we had a
compiler that supported it. But I see no compelling reason to bother.

If the tools you are using get in your way (don't allow an efficient,
convenient way to find files), then get (or build) better tools. The
compiler is not at fault; your IDE is.

I find GPS annoying with long file names, because it does not allow
searching on anything other than the first letter of the file name (as
do most GUI IDEs). Emacs allows searching on any portion of the file
name.

Give Emacs another try; it will be good for you :).

-- 
-- Stephe

Re: Visibility problems with package instantiations.....

[Dmitry A. Kazakov]

On 04 Dec 2003 08:09:22 -0500, Stephen Leake <stephen_leake@acm.org>
wrote:

>Dmitry A.Kazakov <mailbox@dmitry-kazakov.de> writes:
>
>> On 03 Dec 2003 13:09:25 -0500, Stephen Leake <Stephe.Leake@nasa.gov>
>> wrote:
>> 
>> >Hmm. In emacs, I pull up the whole directory, then search in the
>> >buffer.
>> >
>> >But actually, to navigate Ada source, I don't tend to use file names;
>> >I use Ada names, and let Emacs figure out where the files are.
>> 
>> I see. You know, an ability to accept emacs is IMO sort of genetically
>> preprogrammed. (:-))
>
>Well, there do seem to be Emacs people and non-Emacs people. 
>
>> >File names that mimic the package tree are better than directories
>> >that mimic the package tree, in my opinion. I haven't heard any solid
>> >evidence here to contradict that.
>> 
>> As a emacs user you should see little difference between:
>> 
>>     fuzzy-graph-handle-learning-implementation.ads
>> 
>> and
>> 
>>     fuzzy/graph/handle/learning/implementation.ads
>> 
>> after all one can substitute '/' for '-' in emacs.
>
>Exactly; they are very much the same in readability. But, I have to
>add all directories to various search lists, so it is much easier to
>have only a few directories. Thus I prefer long file names over long
>directory paths.

It depends on the compiler and IDE. AdaGide does it very good for
GNAT. I found it easier to use than GPS (except for debugging of
course).

>> Then, do not you feel that packing everything in one directory is
>> similar to packing all packages in one huge all_stuff.ada file? 
>
>Since the Ada compiler treats compilation units in one file much
>differently than compilation units in separate files, but cares not at
>all about what directories things are in, these are very different issues.
>
>> I mean that if we accept the idea of mapping compilation units to
>> files, we should also, consequently, accept mapping of their
>> parent-child relations to the directory-file ones.
>
>I accept it as a possibility, but it is simply not as nice in practice.
>
>Java is the only language I have used that cares about directories; I
>found it annoying. But if I had to use it much, I'd teach Emacs how to
>deal with it efficiently (or, more likely, find an Emacs package that
>someone else has written that does that). Then I wouldn't notice
>anymore. The same could be done for Ada, of course, if we had a
>compiler that supported it. But I see no compelling reason to bother.
>
>If the tools you are using get in your way (don't allow an efficient,
>convenient way to find files), then get (or build) better tools. The
>compiler is not at fault; your IDE is.

Right. With a good IDE there should be no reason to care about files.
But the issue will arise in another form, as you write below.

>I find GPS annoying with long file names, because it does not allow
>searching on anything other than the first letter of the file name (as
>do most GUI IDEs). Emacs allows searching on any portion of the file
>name.

Yes GPS has a long way to go. One problem is that the project view
shows files (and their directories) instead of compilation units. I.e.
it should be sort of:

+ specifications
   + window
      + pop_up
         - dialog

instead of:

+ some-irrelevant-directory-path
   - window-pop_up-dialog.ads

with a negative effect of consuming too much of screen space.

One can organize project view in a directory-tree-like way under
MSVC++. In C++ there is no parent/child relation, so one should create
project "directories" manually. ObjectAda at least supports separation
of specifications and bodies. But in Ada there is a natural
"partitioning" base on parent-child/separate body relation. Should IDE
support it, then, yes, one could forget about all file names.

>Give Emacs another try; it will be good for you :).

Maybe, when EU will allow experiments on stem cells, then a small
injection of emacs-cells and ... (:-))

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

Re: Visibility problems with package instantiations.....

[Randy Brukardt]

"Stephen Leake" <stephen_leake@acm.org> wrote in message
news:mailman.8.1070543384.31149.comp.lang.ada@ada-france.org...
> > Then, do not you feel that packing everything in one directory is
> > similar to packing all packages in one huge all_stuff.ada file?
>
> Since the Ada compiler treats compilation units in one file much
> differently than compilation units in separate files, but cares not at
> all about what directories things are in, these are very different issues.

That's a mis-feature of a particular Ada implementation, one that follows
the "letter" of the standard but not the spirit. So far as I know, all other
Ada compilers directly support compiling files containing multiple units.
And it certainly seems to me that the intent of the standard was that that
would directly supported. So Dmitry is right -- there is no practical
difference.

But the basic point should be, do what makes most sense to you and your
project, and get tools that support that well. The more flexible the tools,
the better (unless, like me, you have your own personal development system
that you fix/upgrade when its annoying. But that's not the norm!).

                    Randy.

Re: Visibility problems with package instantiations.....

[Stephen Leake]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Stephen Leake" <stephen_leake@acm.org> wrote in message
> news:mailman.8.1070543384.31149.comp.lang.ada@ada-france.org...
> > > Then, do not you feel that packing everything in one directory is
> > > similar to packing all packages in one huge all_stuff.ada file?
> >
> > Since the Ada compiler treats compilation units in one file much
> > differently than compilation units in separate files, but cares not at
> > all about what directories things are in, these are very different issues.
> 
> That's a mis-feature of a particular Ada implementation, one that follows
> the "letter" of the standard but not the spirit. So far as I know, all other
> Ada compilers directly support compiling files containing multiple units.

Well, yes, GNAT refuses to compile a file containing multiple units.
But even in other systems, the re-compilation dependencies get
confused when there are more than one unit in a file (which is why
GNAT refuses to do it); it is that effect I was talking about.

> But the basic point should be, do what makes most sense to you and your
> project, and get tools that support that well. The more flexible the tools,
> the better (unless, like me, you have your own personal development system
> that you fix/upgrade when its annoying. But that's not the norm!).

I fix Emacs when it doesn't do what I want. I haven't gotten around to
fixing the compiler; to much else to do :).

-- 
-- Stephe

Re: Visibility problems with package instantiations.....

[Randy Brukardt]

"Stephen Leake" <stephen_leake@acm.org> wrote in message
news:mailman.11.1070584255.31149.comp.lang.ada@ada-france.org...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
> > "Stephen Leake" <stephen_leake@acm.org> wrote in message
> > news:mailman.8.1070543384.31149.comp.lang.ada@ada-france.org...
> > > > Then, do not you feel that packing everything in one directory is
> > > > similar to packing all packages in one huge all_stuff.ada file?
> > >
> > > Since the Ada compiler treats compilation units in one file much
> > > differently than compilation units in separate files, but cares not at
> > > all about what directories things are in, these are very different
issues.
> >
> > That's a mis-feature of a particular Ada implementation, one that
follows
> > the "letter" of the standard but not the spirit. So far as I know, all
other
> > Ada compilers directly support compiling files containing multiple
units.
>
> Well, yes, GNAT refuses to compile a file containing multiple units.
> But even in other systems, the re-compilation dependencies get
> confused when there are more than one unit in a file (which is why
> GNAT refuses to do it); it is that effect I was talking about.

'fraid I don't follow. Certainly it is possible to compile more than you
need to in that way, but if compilation is fast enough, that's not really an
issue. If the units are completely out of order, you'll have trouble, but
that hardly is surprising. But the make tools work (I know ours does), and
it works well to put a number of specs in the same file. For instance, in
Claw, there are a number of packages that we had to move in the hierarchy.
The spec file then also contains a rename of the package to its original
name. It would hardly make sense to give a one line item its own source
file, with all of the configuration management/standard comments like
copyrights that that entails - the result would be pretty large and it would
be hard to find the actual code. :-)

                   Randy.

Re: Visibility problems with package instantiations.....

[Stephen Leake]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Stephen Leake" <stephen_leake@acm.org> wrote in message
> news:mailman.11.1070584255.31149.comp.lang.ada@ada-france.org...
> > Well, yes, GNAT refuses to compile a file containing multiple units.
> > But even in other systems, the re-compilation dependencies get
> > confused when there are more than one unit in a file (which is why
> > GNAT refuses to do it); it is that effect I was talking about.
> 
> 'fraid I don't follow. Certainly it is possible to compile more than you
> need to in that way, but if compilation is fast enough, that's not really an
> issue. 

On a "large enough" project, compilation is never "fast enough". This
is exactly the issue. I guess "confused" was too strong a word.
"inefficient" is better.

> If the units are completely out of order, you'll have trouble, but
> that hardly is surprising. But the make tools work (I know ours
> does), and it works well to put a number of specs in the same file.

If you ignore the recompilation inefficiency, yes, this can work well.

> For instance, in Claw, there are a number of packages that we had to
> move in the hierarchy. The spec file then also contains a rename of
> the package to its original name. It would hardly make sense to give
> a one line item its own source file, with all of the configuration
> management/standard comments like copyrights that that entails - the
> result would be pretty large and it would be hard to find the actual
> code. :-)

Yes, that's true. There are special cases on both sides :).

-- 
-- Stephe

Re: Visibility problems with package instantiations.....

[Jeff C,]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:vsv2ilkl6god65@corp.supernews.com...
> "Stephen Leake" <stephen_leake@acm.org> wrote in message
> news:mailman.8.1070543384.31149.comp.lang.ada@ada-france.org...
> > > Then, do not you feel that packing everything in one directory is
> > > similar to packing all packages in one huge all_stuff.ada file?
> >
> > Since the Ada compiler treats compilation units in one file much
> > differently than compilation units in separate files, but cares not at
> > all about what directories things are in, these are very different
issues.
>
> That's a mis-feature of a particular Ada implementation, one that follows
> the "letter" of the standard but not the spirit. So far as I know, all
other


Note that it is incorrect to assume that only GNAT has this limitation. I
believe
GNAT and Rational Apex both require one one compilation unit per file. There
are probably
others as well.

Re: Visibility problems with package instantiations.....

[Arnaud Charlet]

> Note that it is incorrect to assume that only GNAT has this limitation.

And it is also incorrect to assume or state that GNAT has this
limitation, since this is wrong.

If GNAT (or any Ada compiler for that matter) had this limitation, it
would not be able to compile ACATS tests which contain several units per
file.

What people meant is that the optimal, recommended and typical use of
GNAT is to have one unit per file.

For multiple units per file, GNAT comes with gnatchop which is fully
capable of handling multiple units.

Arno

Re: Visibility problems with package instantiations.....

[Randy Brukardt]

"Arnaud Charlet" <charlet@gnat.com> wrote in message
news:Pine.LNX.4.44.0312051409310.14199-100000@aix.act-europe.fr...
> > Note that it is incorrect to assume that only GNAT has this limitation.
>
> And it is also incorrect to assume or state that GNAT has this
> limitation, since this is wrong.
>
> If GNAT (or any Ada compiler for that matter) had this limitation, it
> would not be able to compile ACATS tests which contain several units per
> file.
>
> What people meant is that the optimal, recommended and typical use of
> GNAT is to have one unit per file.
>
> For multiple units per file, GNAT comes with gnatchop which is fully
> capable of handling multiple units.

What I said is that GNAT follows the *letter* of the standard, not the
*spirit*. If you have to do something that the compiler and/or make tool
does not recognize and do automatically if needed, then it doesn't really
support it in my book. That's because you can't edit the source file with
the multiple units and use the make tool to update your program. That means
that you either modify the split files (at which point you no longer have
multiple units in your file), or you have to rememeber to run gnatchop by
hand (and the failure to do so means a lot of wasted time figuring out why
something doesn't work - something I've spent a lot of time doing with
Claw).

Given that supporting this properly would only a few days of work
(implementing it in Janus/Ada took precisely one day, and that was a lot
more complex than integrating gnatchop would be), it is hard to imagine
precisely why that was never done.

Someone mentioned Apex as not supporting multiple files. I believe that in
fact it does work if you use the command line compiler (it doesn't enforce
source naming requirements). And if you just use the GUI, the source code is
pretty much a useless appendage used only to communicate to non-Apex
programs. Even so, it is fair to say that it too has a limitation in this
area.

                        Randy.

Re: Visibility problems with package instantiations.....

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> What I said is that GNAT follows the *letter* of the standard, not the
> *spirit*. If you have to do something that the compiler and/or make tool
> does not recognize and do automatically if needed, then it doesn't really
> support it in my book. That's because you can't edit the source file with
> the multiple units and use the make tool to update your program. That means
> that you either modify the split files (at which point you no longer have
> multiple units in your file), or you have to rememeber to run gnatchop by
> hand (and the failure to do so means a lot of wasted time figuring out why
> something doesn't work - something I've spent a lot of time doing with
> Claw).

I added a minor mode to Emacs that automatically runs gnatchop when
you save the file.

-- 
Simon Wright                               100% Ada, no bugs.

Re: Visibility problems with package instantiations.....

[Jeffrey Carter]

Dmitry A. Kazakov wrote:

> BTW, maybe a stupid idea, but what if we change file naming policy
> allowing:
> 
>    package A.B is ...
> 
> to be named "b.ads" IFF that is placed in a subdirectory named "a" of
> the directory containing "a.ads"?

The naming of source files is a compiler issue, not a language issue; 
the ARM is appropriately silent on the subject. You can take it up with 
your compiler vendor, if you like (or make the changes yourself in GNAT).

-- 
Jeff Carter
"Saving keystrokes is the job of the text editor,
not the programming language."
Preben Randhol
64

Re: Visibility problems with package instantiations.....

[Dmitry A. Kazakov]

On Tue, 02 Dec 2003 17:07:23 GMT, Jeffrey Carter <spam@spam.com>
wrote:

>Dmitry A. Kazakov wrote:
>
>> BTW, maybe a stupid idea, but what if we change file naming policy
>> allowing:
>> 
>>    package A.B is ...
>> 
>> to be named "b.ads" IFF that is placed in a subdirectory named "a" of
>> the directory containing "a.ads"?
>
>The naming of source files is a compiler issue, not a language issue; 
>the ARM is appropriately silent on the subject. You can take it up with 
>your compiler vendor, if you like (or make the changes yourself in GNAT).

That would be unwise. Naming conventions should be compatible across
different compilers. Otherwise, we would loose one of great Ada
advantages: portability. At least as end-user understands it. He takes
a project and with no or minimum efforts get it compiled under any Ada
compiler.

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

Re: Visibility problems with package instantiations.....

[Randy Brukardt]

"Petter Fryklund" <petter.fryklund@atero.se> wrote in message
news:95234e08.0311302345.4f9e235b@posting.google.com...
> I still think that it would be nice to have a "box" syntax for
> parameters that aren't relevant.

See AI-317, approved by the ARG at the last meeting.

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> said:

>If you are going to make an AI on generics and send it to ARG, then add
there

>1. defaults for generic parameters;

This was proposed in AI-299. It didn't find sufficient support, and it was
shelved. (Generally, people didn't think it was important enough.)

>2. a way to resolve conflicts in generic parameter names;
>3. matching the actuals of generic subroutine with omitted default
>parameters [It might be backward incompatible, as Christoph Grein pointed];

Dunno about these.

> 4. generic formal dispatching subroutines;
> 5. generic dispatching subroutines;

Tucker has been lobbying for changes in this area for years. The main
problem is that the changes proposed so far are very messy; it's very hard
to understand the implications. I believe someone has the action item to
work on them.
>. . .
>666. automatic instantiations;

I think you have the appropriate number here. :-)

             Randy Brukardt