Possible Ada deficiency?

Possible Ada deficiency?

[danmcleran]

I would like to know if anyone else thinks that the inability to hide
private information from child packages is a deficiency in Ada95. I am
discussing ways to do this on another thread, (See Private area and
child packages), but it seems wrong that one has to go through a bunch
of machinations to do something like this. Wouldn't a language
construct for this be advantageous?

In C++ and Java, no private data can be seen by child classes. I think
that Ada would benefit from extending its information hiding
capabilities by allowing a package writer to conceal type information
from child packages.

What if Ada had a keyword, I've chosen 'concealed' for the sake of
discussion, to indicate that the implementation of a type was not
visible to the outside world (including child packages). Something like
this:

--This is not Ada!

package Some_Package is
type Not_So_Secret_Type is private;   -- Child packages can see the
details
type Super_Secret_Type  is concealed; -- Hidden from everyone
private
--child packages have full visibility
concealed
--not even child packages can see here
end Some_Package;

Possible Ada deficiency?

[danmcleran]

I would like to know if anyone else thinks that the inability to hide
private information from child packages is a deficiency in Ada95. I am
discussing ways to do this on another thread, (See Private area and
child packages), but it seems wrong that one has to go through a bunch
of machinations to do something like this. Wouldn't a language
construct for this be advantageous?

In C++ and Java, no private data can be seen by child classes. I think
that Ada would benefit from extending its information hiding
capabilities by allowing a package writer to conceal type information
from child packages.

What if Ada had a keyword, I've chosen 'concealed' for the sake of
discussion, to indicate that the implementation of a type was not
visible to the outside world (including child packages). Something like
this:

--This is not Ada!

package Some_Package is
type Not_So_Secret_Type is private;   -- Child packages can see the
details
type Super_Secret_Type  is concealed; -- Hidden from everyone
private
--child packages have full visibility
concealed
--not even child packages can see here
end Some_Package;

Re: Possible Ada deficiency?

[Jeffrey Carter]

danmcleran@hotmail.com wrote:

> In C++ and Java, no private data can be seen by child classes. I think
> that Ada would benefit from extending its information hiding
> capabilities by allowing a package writer to conceal type information
> from child packages.

You're confusing C++ classes with Ada packages. In C++, classes serve a 
multitude of purposes, including encapsulation, information hiding, type 
extension, and dynamic dispatching. In Ada, encapsulation, name space 
control, and information hiding are handled by packages. Type extension 
and dispatching are handled by tagged types.

Private components in C++ prevent the components from being visible to 
derived types. This is also possible in Ada:

package P is
    type T is tagged private;

    procedure Op (A : in out T);
private -- P
    type T is tagged record
       I : Integer := 0;
    end record;
end P;

with P;
package Q is
    type T is new P.T with record
       F : Float := 0.0;
    end record;

    procedure Op_2 (A : in out T);
end Q;

package body Q is
    procedure Op_2 (A : in out T) is
       -- null;
    begin -- Op_2
       A.I := 2; -- Illegal.
    end Op_2;
end Q;

Child packages in Ada provide the equivalent of friends in C++; thus, 
the private part of a package is akin to protected in C++, with the 
package body corresponding to C++'s private.

-- 
Jeff Carter
"Ada has made you lazy and careless. You can write programs in C that
are just as safe by the simple application of super-human diligence."
E. Robert Tisdale
72

Re: Possible Ada deficiency?

[Martin Dowie]

danmcleran@hotmail.com wrote:
> In C++ and Java, no private data can be seen by child classes. I think
> that Ada would benefit from extending its information hiding
> capabilities by allowing a package writer to conceal type information
> from child packages.

...but "protected" data can? E.g.

package C_Plus_Plus is

    type Public_Type is tagged record
       I : Integer;  -- Anyone can see
    end record;

    type Protected_Type is new Public_Type with private;

private

    type Protected_Type is new Public_Type with record
       F : Float;  -- Any derived class can see
    end record;

end C_Plus_Plus;

package body C_Plus_Plus is

    type Private_Type is new Protected_Type with record
       B : Boolean;  -- Only "parent namespace" can see
    end record;

end C_Plus_Plus;

Re: Possible Ada deficiency?

[Nick Roberts]

danmcleran@hotmail.com wrote:

> I would like to know if anyone else thinks that the inability to hide
> private information from child packages is a deficiency in Ada95. I am
> discussing ways to do this on another thread, (See Private area and child
> packages), but it seems wrong that one has to go through a bunch of
> machinations to do something like this. Wouldn't a language construct for
> this be advantageous?

Perhaps the ability to declare a 'body type' within a private part would do
the trick:

   package Some_Package is
      type Fairly_Secret_Type is private;
   private
      body type Really_Secret_Stuff is
         record
            ...;
         end record;
      type Fairly_Secret_Type is
         record
            ...;
            Secret: Really_Secret_Stuff;
         end record;
   end Some_Package;

This would prevent the type Really_Secret_Stuff from being visible anywhere
but in the body of the package Some_Package (so that components of the
component Secret would be hidden from private children of Some_Package).

Unfortunately, it is now too late for any further changes to Ada 2005. This
might be something to be considered at the next revision.

Personally, I've often found it useful to use an incomplete type declaration
in the private part to completely isolate the actual contents of a visible
type from everything outside the package body.

   package P is
      type T is private;
      ...
   private
      type Innards_Bearer(<>);
      type Innards is access Innards_Bearer;
      type T is
         record
            Data: Innards;
         end record;
   end P;

   package body P is
      ...
      type Innards_Bearer is
         record
            ... -- actual contents here
         end record;
      ...
   end P;

Obviously this technique requires explicit allocation (and maybe
deallocation), and the inefficiency of a (further) level of dereferencing,
but these are usually not a significant problem (and are confined to the
body). The additional advantage is that the actual contents can be changed
within the body, so not clobbering the specification (or therefore, more
importantly, any of its dependants).

This technique will hide the actual contents from the private children of
the package. It comes close to achieving what you suggest, Dan. I haven't
read the whole of the other thread you mention, so perhaps this technique
has already been mentioned there.

-- 
Nick Roberts

Re: Possible Ada deficiency?

[danmcleran]

Jeffrey Carter wrote:
> danmcleran@hotmail.com wrote:
>
> > In C++ and Java, no private data can be seen by child classes. I
think
> > that Ada would benefit from extending its information hiding
> > capabilities by allowing a package writer to conceal type
information
> > from child packages.
>
> You're confusing C++ classes with Ada packages. In C++, classes serve
a
> multitude of purposes, including encapsulation, information hiding,
type
> extension, and dynamic dispatching. In Ada, encapsulation, name space

> control, and information hiding are handled by packages. Type
extension
> and dispatching are handled by tagged types.
>
> Private components in C++ prevent the components from being visible
to
> derived types. This is also possible in Ada:
>
> package P is
>     type T is tagged private;
>
>     procedure Op (A : in out T);
> private -- P
>     type T is tagged record
>        I : Integer := 0;
>     end record;
> end P;
>
> with P;
> package Q is
>     type T is new P.T with record
>        F : Float := 0.0;
>     end record;
>
>     procedure Op_2 (A : in out T);
> end Q;
>
> package body Q is
>     procedure Op_2 (A : in out T) is
>        -- null;
>     begin -- Op_2
>        A.I := 2; -- Illegal.
>     end Op_2;
> end Q;
>
> Child packages in Ada provide the equivalent of friends in C++; thus,

> the private part of a package is akin to protected in C++, with the
> package body corresponding to C++'s private.

There's one problem with this analogy. In C++, a class grants
friendship status to other classes and/or functions. In Ada, a child
package assumes friendship with the parent package whether the parent
likes it or not.

Re: Possible Ada deficiency?

[danmcleran]

Another problem with this, as demonstrated by Jefferey Carter, is that
child packages could make copies of the access values (Data in your
example). Thus, you might have dangling references when this access
value goes out of scope.

Re: Possible Ada deficiency?

[danmcleran]

I understand your point about packages vs. tagged types. I still
believe that it would be a good thing to have a mechanism to hide
impelmentation detail from child packages. Otherwise, anyone could
write a package as a child of another and expose a public interface to
the outside world that could change the private area of its parent
package.

Re: Possible Ada deficiency?

[Jeffrey Carter]

Martin Dowie wrote:
  ...but "protected" data can? E.g.
> 
> package C_Plus_Plus is
> 
>    type Public_Type is tagged record
>       I : Integer;  -- Anyone can see
>    end record;
> 
>    type Protected_Type is new Public_Type with private;
> 
> private
> 
>    type Protected_Type is new Public_Type with record
>       F : Float;  -- Any derived class can see

Only in child packages.

>    end record;
> 
> end C_Plus_Plus;


-- 
Jeff Carter
"I've got to stay here, but there's no reason
why you folks shouldn't go out into the lobby
until this thing blows over."
Horse Feathers
50

Re: Possible Ada deficiency?

[Jeffrey Carter]

danmcleran@hotmail.com wrote:

> There's one problem with this analogy. In C++, a class grants
> friendship status to other classes and/or functions. In Ada, a child
> package assumes friendship with the parent package whether the parent
> likes it or not.

This was considered a weakness in C++, that possible friends have to be 
known when the class is created, or the class has to be modified to 
allow new friends. The Ada-95 project felt that extensibility was better 
served by not requiring such a mechanism.

 > I understand your point about packages vs. tagged types. I still
 > believe that it would be a good thing to have a mechanism to hide
 > impelmentation detail from child packages. Otherwise, anyone could
 > write a package as a child of another and expose a public interface to
 > the outside world that could change the private area of its parent
 > package.

Not that I necessarily disagree with you. See Carter, J., "Breaking the 
Ada Privacy Act", /Ada Letters/, 1996 May/Jun.

-- 
Jeff Carter
"I've got to stay here, but there's no reason
why you folks shouldn't go out into the lobby
until this thing blows over."
Horse Feathers
50

Re: Possible Ada deficiency?

[Dmitry A. Kazakov]

On 31 Dec 2004 10:15:13 -0800, danmcleran@hotmail.com wrote:

> I would like to know if anyone else thinks that the inability to hide
> private information from child packages is a deficiency in Ada95. I am
> discussing ways to do this on another thread, (See Private area and
> child packages), but it seems wrong that one has to go through a bunch
> of machinations to do something like this. Wouldn't a language
> construct for this be advantageous?
> 
> In C++ and Java, no private data can be seen by child classes. I think
> that Ada would benefit from extending its information hiding
> capabilities by allowing a package writer to conceal type information
> from child packages.
> 
> What if Ada had a keyword, I've chosen 'concealed' for the sake of
> discussion, to indicate that the implementation of a type was not
> visible to the outside world (including child packages). Something like
> this:
> 
> --This is not Ada!
> 
> package Some_Package is
> type Not_So_Secret_Type is private;   -- Child packages can see the
> details
> type Super_Secret_Type  is concealed; -- Hidden from everyone
> private
> --child packages have full visibility
> concealed
> --not even child packages can see here
> end Some_Package;

I do not think it is a deficiency. What you want is just C++'s private.
Ada's private is like C++'s protected.

OK, what is actually the use of C++'s private? It is used to declare
implementation-specific members, which cannot be accessed by anyone except
the owner, i.e. by the class implementation. But that breaks implementation
hiding concept! A private part of implementation gets exposed in a class
definition. Well, it might be inaccessible, but it is still there and
visible to the code reader. [S]he might unintentionally use it, not
directly but you know there are many ways to play tricks. So to me the idea
of C++'s private is altogether wrong.

Now let's return to Ada. There you need not to expose implementation in a
package specification. If you need a C++-like member function, you never
declare it there. You rather move it into the package body. If that gets
too large, you make a separate body or a separate nested package, but again
declared in the package body (*). So Ada provides better information hiding
here. Where your critique might be right is that the above is not true for
data members. It is not easy to hide them.

Anyway, in my view the only right way to hide something is in the body.
From this point of view your proposal would be a step in wrong direction.

----------
* Note two mechanisms to provide implementations in Ada. Child packages are
for implementation "en large", when the designer of an interface will not
implement it now and here. For a tighter local implementation one should
always use the body. That can be organized in a way equivalent to child
packages. Analogous objects here are packages nested in the body. A nested
package body can be separate.

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

Re: Possible Ada deficiency?

[Martin Krischik]

danmcleran@hotmail.com wrote:

> I would like to know if anyone else thinks that the inability to hide
> private information from child packages is a deficiency in Ada95. I am
> discussing ways to do this on another thread, (See Private area and
> child packages), but it seems wrong that one has to go through a bunch
> of machinations to do something like this. Wouldn't a language
> construct for this be advantageous?
> 
> In C++ and Java, no private data can be seen by child classes. I think
> that Ada would benefit from extending its information hiding
> capabilities by allowing a package writer to conceal type information
> from child packages.

The C++ private is not realy hidden. The private keyword is only a marketing
gag. Think about:

#define private public
#include "..."
#undef private

Truly hidden data need to be part of the package body or in C++ be declared
only in the ".cpp" file. Ada is just more honest about it.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Possible Ada deficiency?

[Martin Krischik]

danmcleran@hotmail.com wrote:

> I understand your point about packages vs. tagged types. I still
> believe that it would be a good thing to have a mechanism to hide
> impelmentation detail from child packages. Otherwise, anyone could
> write a package as a child of another and expose a public interface to
> the outside world that could change the private area of its parent
> package.

just as anybody can type

#define private public

in C++.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Possible Ada deficiency?

[danmcleran]

> just as anybody can type
>
> #define private public
>
> in C++.
>
> With Regards
>
> Martin

Yes. This kind of thing is evil. One of the main reasons I find Ada so
appealing is that it has fewer loopholes for this kind of stuff to get
through. I am surprised that child packages have as much visibility as
they do, and that there is no way to prevent it, though.

Re: Possible Ada deficiency?

[Stephen Leake]

danmcleran@hotmail.com writes:

> I understand your point about packages vs. tagged types. I still
> believe that it would be a good thing to have a mechanism to hide
> impelmentation detail from child packages. Otherwise, anyone could
> write a package as a child of another and expose a public interface to
> the outside world that could change the private area of its parent
> package.

Remember, the point of a good programming language is to help good
programmers write better programs, not to force bad programmers to
follow the rules.

-- 
-- Stephe

Re: Possible Ada deficiency?

[danmcleran]

I'm not trying to promote C++'s private. I don't believe that this
would be the way to go. For one thing, I don't like the idea of friends
(or any other component) having access to private data. Although I have
used this technique myself, I feel like it is a trick one can pull out
when they didn't think ahead during the design phase.

What I would like to have in Ada is very simple, a way to hide a data
type's internal representation from child packages. I didn't even
consider hiding procedure(s) and/or function(s), because of your point
about putting them into the package body.

If my type consists of a record, which contains stuff I don't want
anyone else messing with, there's no way to prevent someone from
writing a child package and having full access to the internals of my
type!

Re: Possible Ada deficiency?

[danmcleran]

Well, here you're using the preprocessor to pull this off, not the
language. Anyway, I'm not trying to convince anyone that C++'s private
is the answer or somehow superior. The point I'm trying to make is that
private in Ada is not as private as I would like. I'm really surprised
that there is not a way to a type's representaion from child packages.
In my opinion, the language would benefit from providing the ability to
hide a types internal representation from the outside world, including
child packages.

Re: Possible Ada deficiency?

[danmcleran]

Yes, but it seems like such an obvious place where bad things could
happen. It seems like only goodness can be bought by having the ability
to hide a type's impelmentation from child packages. I don't see any
downside to providing this ability. That way, one could force a child
package to use the interface provided by the public area of its parent
and prevent the child from manipulating the internal representation of
a type.

Re: Possible Ada deficiency?

[Larry Kilgallen]

In article <1104594390.142290.12210@z14g2000cwz.googlegroups.com>, danmcleran@hotmail.com writes:
> I'm not trying to promote C++'s private. I don't believe that this
> would be the way to go. For one thing, I don't like the idea of friends
> (or any other component) having access to private data. Although I have
> used this technique myself, I feel like it is a trick one can pull out
> when they didn't think ahead during the design phase.
> 
> What I would like to have in Ada is very simple, a way to hide a data
> type's internal representation from child packages. I didn't even
> consider hiding procedure(s) and/or function(s), because of your point
> about putting them into the package body.

If you want to hide the information, why are you making it a child package ?
To me the major reason for a child package is to share the information.

Re: Possible Ada deficiency?

[danmcleran]

The point I'm trying to make is that if I want to write a package and
hide certain information from all future child packages, a new
construct is needed. One might want to share certain information with
child packages, but force child packages to use a public or private
interface for other information. For the sake of discussion, let's say
that a new keyword, 'concealed', meant that this section could not be
seen by the outside world, including child packages. One could then
write a package with a public area, a private area (child packages
could see this area), and a concealed area that no one, including child
packages, could see. In this example, Secret_Type is a type that I want
completely hidden from the outside world. There is a public interface,
Print_Secret_Value, that anyone can call, and a private interface,
Change_Concealed_Value, that is only callable from with the package
body and all child packages. Simple example:

-- This is not Ada!

package Some_Package is
--public area
type Secret_Type is concealed;

procedure Print_Secret_Value (Value : in Secret_Type);

private
--Child packages can see here
procedure Change_Concealed_Value (New_Value : in Secret_Type);
concealed
--Child packages cannot see here, they must use the public and/or
private interface
type Secret_Type is record
Secret_Value : Integer;
end record
end Some_Package;

Re: Possible Ada deficiency?

[danmcleran]

Here's a different way to illustrate this problem. If I want to extend
a type, I can do this with a non-child package. But, if I make the
package containing the extended type a child package, I then have
access to all of the private area as well. So, one can extend a type
with or without access to the private area, depending on whether one
makes the packages containing the derived type a child package or not.
In my example, notice that the derived type in the child package can
change the private area, whereas the derived type in the non-child
package cannot.

Consider these files (Main.adb is the test program):

--Some_Package.ads

package Some_Package is
type Secret_Type is tagged private;

procedure Print_Secret_Value (Value : in out Secret_Type'Class);
private
type Secret_Type is tagged record
Secret_Value : Integer := 0;
end record;
end Some_Package;

--Some_Package.adb

with Ada.Text_IO;

package body Some_Package is
procedure Print_Secret_Value (Value : in out Secret_Type'Class) is
begin
Ada.Text_IO.Put_Line (Item => "Secret value = " &
Integer'Image(Value.Secret_Value));
end Print_Secret_Value;
end Some_Package;

--Some_Package.Child_Package.ads

package Some_Package.Child_Package is
type Some_Child_Type is new Secret_Type with null record;

procedure Badness (
Child     : in out Some_Child_Type;
New_Value : in Integer);


end Some_Package.Child_Package;

--Some_Package.Child_Package.adb

package body Some_Package.Child_Package is
procedure Badness (
Child     : in out Some_Child_Type;
New_Value : in Integer) is
begin
Child.Secret_Value := New_Value;
end Badness;
end Some_Package.Child_Package;

--Non_Child_Package.ads

with Some_Package;

package Non_Child_Package is
type Derived_Type is new Some_Package.Secret_Type with null record;

procedure Badness (
Derived   : in out Derived_Type;
New_Value : in Integer);

end Non_Child_Package;

--Non_Child_Package.adb

package body Non_Child_Package is
procedure Badness (
Derived   : in out Derived_Type;
New_Value : in Integer) is
begin
--Derived.Secret_Value := New_Value;--won't compile
null;
end Badness;
end Non_Child_Package;

--Main.adb

with Some_Package;
with Some_Package.Child_Package;
with Non_Child_Package;

procedure Main is
Child_Value : Some_Package.Child_Package.Some_Child_Type;
Non_Child   : Non_Child_Package.Derived_Type;
begin
Some_Package.Print_Secret_Value (Value => Child_Value);
Some_Package.Print_Secret_Value (Value => Non_Child);
Some_Package.Child_Package.Badness (Child => Child_Value, New_Value
=> 100);
Non_Child_Package.Badness (Derived => Non_Child, New_Value => 100);
Some_Package.Print_Secret_Value (Value => Child_Value);
Some_Package.Print_Secret_Value (Value => Non_Child);
end Main;

Re: Possible Ada deficiency?

[tmoran]

>Otherwise, anyone could write a package as a child of another and expose a
>public interface to the outside world that could change the private area
>of its parent package.
   "Anyone could" read the package spec's source code past the word
"private" and do various clever tricks.
  I think the difference here is in attitude toward use of the "child
package" construct.  I think of "child" as a rather intimate relationship.
I would expect the design of package P to include all of its fixed set of
children, or at least to include a very definite expected framework for
any future children.  Random users shouldn't be writing children of my
library packages.  If they do, I would treat it as if they changed the
parent package - if you break it you own it.  This attitude is exemplified
by ARM A.2(4) "In the standard mode, it is illegal to compile a child of
package Ada."

Re: Possible Ada deficiency?

[Ed Falis]

On 1 Jan 2005 11:43:15 -0800, <danmcleran@hotmail.com> wrote:

>
> package Some_Package is
> --public area
> type Secret_Type is concealed;
>
> procedure Print_Secret_Value (Value : in Secret_Type);
>
> private
> --Child packages can see here
> procedure Change_Concealed_Value (New_Value : in Secret_Type);
> concealed
> --Child packages cannot see here, they must use the public and/or
> private interface
> type Secret_Type is record
> Secret_Value : Integer;
> end record
> end Some_Package;
>

Why is this so much preferable to:

package Some_Package is
    type Public_Handle is private;

    procedure Print_Secret_Value (Value : in Public_Handle);

private
    procedure Change_Concealed_Value (New_Value : in Public_Handle);

    type Secret_Type;
    type Public_Handle is access all Secret_Type;
end Some_Package;

package body Some_Package is
    type Secret_Type is record
       Secret_Value : Integer;
    end record;

    ...

end Some_Package;

...?

- Ed

Re: Possible Ada deficiency?

[danmcleran]

Because by using access values, one would have to manage the memory
associated with the object. Also, a dangling reference could be left
behind. See Jeff Carter's post:

http://groups-beta.google.com/group/comp.lang.ada/browse_frm/thread/93d7def3eeefbc26/e8e7d2d6f3847f5c#e8e7d2d6f3847f5c

IMO, a proper construct to allow hiding of implementation detail from
child packages is superior to this suggestion.

Re: Possible Ada deficiency?

[danmcleran]

Then why not have a construct in the language to enforce this desired
behavior? It's all well and good to say, "Don't do that!". But, the
whole idea here is to have this enforceable by the compiler, much as
other good programming practice is enforce by and Ada compiler already.

Re: Possible Ada deficiency?

[Dmitry A. Kazakov]

On 1 Jan 2005 15:28:10 -0800, danmcleran@hotmail.com wrote:

> Here's a different way to illustrate this problem. If I want to extend
> a type, I can do this with a non-child package. But, if I make the
> package containing the extended type a child package, I then have
> access to all of the private area as well. So, one can extend a type
> with or without access to the private area, depending on whether one
> makes the packages containing the derived type a child package or not.

Yes, this is exactly the idea of child packages. The effect of getting nice
package names A.B.C is a side one. They are not intended for that. You
should use child packages when the implementation cannot be completed by
the parent package, e.g. when a type is abstract or just a root of some
deep hierarchy. Separate bodies could not serve this purpose because they
have to be mentioned in the "parent". Note also that children do not break
hiding. You cannot refer any private thing of the parent in the public part
of a child. But the private child's part naturally extends the private part
of the parent.

You can consider the issue for the point view of how packages are coupled.
Unrelated packages are coupled through with'es of their public parts. So if
B with'es A then the private part of A can be changed without any revision
of B. This is the *actual* reason why something need to be hidden. But
coupling between child and parent is tighter. For A.B the rule above does
not hold. If you change the parent you have to inspect all children. Should
you add "very private" clause (*) or sealed types (**) or whatsoever, that
will not change the situation. So it is simper just not to abuse children
and to use separate bodies instead. The design rule of thumb is: "child is
worse than unrelated". Again, observe that Ada's encapsulation is built on
packages, so child vs. not is a coupling and visibility issue.

> In my example, notice that the derived type in the child package can
> change the private area, whereas the derived type in the non-child
> package cannot.

Yes, it must be so.

-----
* as C++ example shows, people get lost in that complex
public/protected/private issue. Decision protected vs. private in 50% falls
wrong. One could toss a coin instead. What is worse that people get
frustrated and start to make everything public.

** sealed types seem to be even worse than private. 

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

Re: Possible Ada deficiency?

[Adrian Hoe]

Stephen Leake wrote:
> danmcleran@hotmail.com writes:
>
> > I understand your point about packages vs. tagged types. I still
> > believe that it would be a good thing to have a mechanism to hide
> > impelmentation detail from child packages. Otherwise, anyone could
> > write a package as a child of another and expose a public interface
to
> > the outside world that could change the private area of its parent
> > package.
>
> Remember, the point of a good programming language is to help good
> programmers write better programs, not to force bad programmers to
> follow the rules.


And good programming language is to help training good programmers. :-)
--
Adrian Hoe

Re: Possible Ada deficiency?

[danmcleran]

> * as C++ example shows, people get lost in that complex
> public/protected/private issue. Decision protected vs. private in 50%
falls
> wrong. One could toss a coin instead. What is worse that people get
> frustrated and start to make everything public.

I can definitely see this point. If one did have this option in Ada, I
can imagine that a decision to make some feature of a parent package
invisible to children might be regretted by the developer months down
the road. In my mind, it's always nice to have more options to work
with, but I also see that keeping it simple(r) can be the best option,
sometimes.

Re: Possible Ada deficiency?

[Ed Falis]

On 1 Jan 2005 19:36:37 -0800, <danmcleran@hotmail.com> wrote:

> Because by using access values, one would have to manage the memory
> associated with the object. Also, a dangling reference could be left
> behind. See Jeff Carter's post:
>
> http://groups-beta.google.com/group/comp.lang.ada/browse_frm/thread/93d7def3eeefbc26/e8e7d2d6f3847f5c#e8e7d2d6f3847f5c
>
> IMO, a proper construct to allow hiding of implementation detail from
> child packages is superior to this suggestion.
>

IMO, the kind of type opacity you're looking for here is rarely enough  
used that an additional language feature is unjustified.  As others have  
pointed out, child units are most often used to provide enhancements or  
additional facilities to a basic abstraction. Sometimes/often this needs  
access to the underlying representation.

If you read the introductory section on hierarchical libraries in the Ada  
95 Rationale, (II.7), I think you'll find that one of the main motivations  
(if not the main motivation) for the concept is to facilitate the sharing  
of private type representations among related abstractions.  In that  
context, the kind of type opacity you want is a corner case, addressable  
by other facilities of the language in a "building block" manner - the  
usual Ada way of addressing non-language-defined capabilities.

This may sound conservative, and it is - there is always a cost related to  
adding new features to the language.  In this particular case, we have to  
agree to disagree about the relative value of the proposed construct.

- Ed

Re: Possible Ada deficiency?

[Martin Krischik]

danmcleran@hotmail.com wrote:

> 
>> just as anybody can type
>>
>> #define private public
>>
>> in C++.
>>
>> With Regards
>>
>> Martin
> 
> Yes. This kind of thing is evil.

Of course you can do the same in Ada using the "Cut/Copy/Paste" feature of
you favourite Editor and Unchecked_Conversion. For the determined you can
make it only more difficult. 

You know, after using C++ for a few years I started to create only classes
like this:

class X_self;

class X
   {
   public:

   ..........

   private:

      X_self& X;

   };

Reason: The main incompatiblily problem is the result of the sizeof
operator. And only opaque types can solve that.

But then I have to agree that the C++ "private" has enormous marketing
value.

> One of the main reasons I find Ada so 
> appealing is that it has fewer loopholes for this kind of stuff to get
> through. I am surprised that child packages have as much visibility as
> they do, and that there is no way to prevent it, though.

If you write a child package you should know what you are doing. Mind you,
child packages where new for Ada 95. In Ada 83 there was only:

package Parent

  package Child

  private

  end Child;

private

end Parent;

package body Parent

  package body Child is seperate;

end Parent;

With this contruct you actualy know all possible child packages. There must
have been a good reason why the new Child packages got access the private
data as well. But then the old child packages even have access to the body
informations.

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Possible Ada deficiency?

[Randy Brukardt]

<danmcleran@hotmail.com> wrote in message
news:1104595073.731663.180100@c13g2000cwb.googlegroups.com...
> Yes, but it seems like such an obvious place where bad things could
> happen. It seems like only goodness can be bought by having the ability
> to hide a type's impelmentation from child packages. I don't see any
> downside to providing this ability. That way, one could force a child
> package to use the interface provided by the public area of its parent
> and prevent the child from manipulating the internal representation of
> a type.

The purpose of a child package is to extend its parent, often in ways not
forseen by the parent's author. You're trying to prevent that purpose. If
you don't want access to the private information, then don't write children.
You have to at some point trust programmers to do something sensible; it's
not the least bit hard to use 'Address or Unchecked_Conversion to access the
private information of a package, no matter where you hide it.

Since children are obvious syntactically, it is easy to determine if a
particular program has any. If your project is creating child packages
willy-nilly, it has project management problems far beyond anything a mere
programming language can help with.

For public packages (like Claw), it's just as easy. Write a child, you're on
your own -- because the only reason to write a child is to get access to
implementation details. Once you do that, we aren't likely to support the
result.

Repeat after me: it's not the least bit hard in any programming language to
write bad code. Ada can only do so much; you have to have coding rules and
the project management to make them stick to get the whole job done.
Otherwise, you can write a morass of child packages, use clauses, address
clauses to make overlays, and so on to rival any messy C code. (Indeed,
these sorts of things are used to translate C to Ada automatically - garbage
in, worse garbage out!).

                               Randy.

Re: Possible Ada deficiency?

[Randy Brukardt]

<danmcleran@hotmail.com> wrote in message
news:1104622090.271236.286730@c13g2000cwb.googlegroups.com...
...
> In my example, notice that the derived type in the child package can
> change the private area, whereas the derived type in the non-child
> package cannot.

Right, that's the whole idea. You don't want to be declaring child packages
willy-nilly. You only do it when you want access to the private part.

About the only language change I could imagine making sense would be a
pragma No_Children. (The visibility and usage costs of a third kind of
declaration are too much.) But I suspect that most of the time, someone
would find they had to remove the pragma for one reason or another.

(Another idea explored very briefly was "separate" private types:
    type P is separate private;
 where the full declaration was given in the body. That wasn't seriously
considered, because Ada compilers take full advantage of the fact that the
size of types are fully known by the end of the package specification. To
change that would be a major disruption in the implementations, and the gain
wasn't considered worth it.)

                            Randy.

Re: Possible Ada deficiency?

[Peter Hermann]

Stephen Leake <stephen_leake@acm.org> wrote:
> Remember, the point of a good programming language is to help good
> programmers write better programs, not to force bad programmers to
> follow the rules.

caught in
http://www.csv.ica.uni-stuttgart.de/homes/ph/resources_on_ada.html
as "Quote of the Day" (see bottom)

-- 
--Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de
--Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
--http://www.csv.ica.uni-stuttgart.de/homes/ph/
--Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: Possible Ada deficiency?

[Nick Roberts]

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

> The purpose of a child package is to extend its parent, often in ways not
> forseen by the parent's author. You're trying to prevent that purpose. If
> you don't want access to the private information, then don't write
> children. You have to at some point trust programmers to do something
> sensible; it's not the least bit hard to use 'Address or
> Unchecked_Conversion to access the private information of a package, no
> matter where you hide it.

I think you're missing the point a little, Randy.

Suppose there are some things in the private part of a package that you do
want private children of the package to be able to see (and modify), and
some other things in the private part that you do not want even private
children to be able to see (or modify).

In this case, it would seem it may be useful to have language construct that
allows this intention to be clearly stated, and enforced by the compiler.

If the intention later turns out to be an obstacle, the construct can be
changed or removed. But if the intention is /accidentally/ violated, it
could be very useful for the compiler to detect it and flag it up.

I suppose the problem is, such a construct would imply the need for a new
kind of private child -- perhaps a 'private private' child ;-) -- which
could access the secret stuff. And then one might have ultra-secret stuff,
and then ultra-secret children, and so on.

So possibly the argument against is that it would be overkill.

-- 
Best wishes,
Nick Roberts

Re: Possible Ada deficiency?

[danmcleran]

>Suppose there are some things in the private part of a package that
you do
>want private children of the package to be able to see (and modify),
and
>some other things in the private part that you do not want even
private
>children to be able to see (or modify).

That is exactly my point. A good analogy would be Java's private.

>I suppose the problem is, such a construct would imply the need for a
new
>kind of private child -- perhaps a 'private private' child ;-) --
which
>could access the secret stuff. And then one might have ultra-secret
stuff,
>and then ultra-secret children, and so on.

I was thinking that there would be a construct, 'concealed'. The
'concealed' area of a package would not be visible to any other
component, period. I wouldn't think that another kind of child would be
needed.

This would allow something like this:

package Some_Package is
type Secret_Type is concealed; -- Visible to the outside world
concealed
-- No other software component has access here,
--and cannot change Secret_Value
type Secret_Type is record
Secret_Value : Integer := 100;
end record;
end Some_Package;

Re: Possible Ada deficiency?

[danmcleran]

Someone else pointed out that the ARM states that it is illegal to
compile a child of package Standard:

This attitude is exemplified
by ARM A.2(4) "In the standard mode, it is illegal to compile a child
of
package Ada."

Why not have a construct to enforce this behavior?

Re: Possible Ada deficiency?

[Pascal Obry]

danmcleran@hotmail.com writes:

> Someone else pointed out that the ARM states that it is illegal to
> compile a child of package Standard:

I don't think this is true. In Ada95 all procedures/functions/packages are
child of Standard. That's why you have access to ASCII for example.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Possible Ada deficiency?

[danmcleran]

Ooops! I meant it is illegal to compile a child package of Ada.

Re: Possible Ada deficiency?

[Pascal Obry]

danmcleran@hotmail.com writes:

> Ooops! I meant it is illegal to compile a child package of Ada.

Ok, that's right.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Possible Ada deficiency?

[Randy Brukardt]

"Nick Roberts" <nick.roberts@acm.org> wrote in message
news:gemini.i9yj3c0051not02as.nick.roberts@acm.org...
> "Randy Brukardt" <randy@rrsoftware.com> wrote:
>
> > The purpose of a child package is to extend its parent, often in ways
not
> > forseen by the parent's author. You're trying to prevent that purpose.
If
> > you don't want access to the private information, then don't write
> > children. You have to at some point trust programmers to do something
> > sensible; it's not the least bit hard to use 'Address or
> > Unchecked_Conversion to access the private information of a package, no
> > matter where you hide it.
>
> I think you're missing the point a little, Randy.
>
> Suppose there are some things in the private part of a package that you do
> want private children of the package to be able to see (and modify), and
> some other things in the private part that you do not want even private
> children to be able to see (or modify).
>
> In this case, it would seem it may be useful to have language construct
that
> allows this intention to be clearly stated, and enforced by the compiler.

There is, it's called the "body". :-)

> If the intention later turns out to be an obstacle, the construct can be
> changed or removed. But if the intention is /accidentally/ violated, it
> could be very useful for the compiler to detect it and flag it up.
>
> I suppose the problem is, such a construct would imply the need for a new
> kind of private child -- perhaps a 'private private' child ;-) -- which
> could access the secret stuff. And then one might have ultra-secret stuff,
> and then ultra-secret children, and so on.
>
> So possibly the argument against is that it would be overkill.

Right. When the ARG considered adding an extra part to package
specifications to support mutually dependent packages (which eventually was
handled with limited with), there were two major concerns:
1) the interactions of the visibility rules for private parts with other
rules of the language are already very complex (and hard to implement). We'd
be nuts to double those interactions with a new kind of package part.
2) How would the user be able to decide what part to put things in? Imagine
the world if all of these proposals had been accepted: package would have 5
parts! (abstract, visible, private, concealed, body).

The way to solve this problem is to figure out how to put more stuff into
the body, not inventing new kinds of parts. It has been claimed (correctly,
IMHO) that the private part originally was a hack to allow compilers to be
written more easily. Ada 95 gave it a second use (exporting stuff within the
subsystem to child units), and it is the conflict between the hack and the
legitimate use that is causing the problem. So the real solution is to get
rid of the requirement for the hack. But there currently isn't the will to
do that - maybe next time.

                           Randy.

Re: Possible Ada deficiency?

[Robert A Duff]

danmcleran@hotmail.com writes:

> I would like to know if anyone else thinks that the inability to hide
> private information from child packages is a deficiency in Ada95.

If so, I think it's a minor one.  As Randy pointed out, if you don't
want child packages to do something nasty, then don't create any child
packages.

The language solution, I think, is not to restrict visibility in the way
you and others have suggested.  Instead, what I would do if I were
designing a new language would be: allow each package to declare one of
(1) no children allowed, (2) a particular list of named children
allowed, or (3) fully extensible -- any children allowed.

Subunits achieve (1) and (2), because the parent has to name all the
subunits.  But subunits are a pain for various reasons (which is why
Tucker invented child units).

In any case, as some folks have pointed out, you should think of "adding
a child of X" as very similar to "modifying the source code of X".
If you don't want people to do that, you need some extra-lingual
mechanism to restrict them.

- Bob

Re: Possible Ada deficiency?

[Nick Roberts]

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

> ...
> The way to solve this problem is to figure out how to put more stuff into
> the body, not inventing new kinds of parts.

Yes. This suggests allowing a private type to be completed in the body. 

> It has been claimed (correctly, IMHO) that the private part originally was
> a hack to allow compilers to be written more easily.

I've heard the same, and I think it might be correct. There's no real
technical barrier to types being completed in the body, other than it might
cause some compilers to have to (effectly) make an extra pass. (Correct?)

-- 
Nick Roberts

Re: Possible Ada deficiency?

[Robert A Duff]

Nick Roberts <nick.roberts@acm.org> writes:

> I've heard the same, and I think it might be correct. There's no real
> technical barrier to types being completed in the body, other than it might
> cause some compilers to have to (effectly) make an extra pass. (Correct?)

I'm not sure what you mean by "extra pass".  The issue is whether the
compiler looks at the body while compiling clients.

The main thing is that the compiler needs to know the size of a private
type in order to allocate things, unless it treats all private types as
dynamic-sized, which would be annoying -- you shouldn't have to pay an
efficiency cost to get the benefits of encapsulation, information
hiding, etc.  So if the full type were in the body, the compiler would
have to look at the body (at least in optimizing mode).

And if the compiler looks at the body, then you have to recompile all
the clients when the body changes (unless you're doing fancy incremental
compilation -- that's the kind of compiler I'd really like to have!).

Another point is that the rules about whether to pass by copy or by
reference depend on the full type.  I don't much like that, but anyway,
the compiler would have to look at the body to find out, unless the
decision is made at run time, which would be grossly inefficient.

So I guess the Ada 83 designers invented the private part so the
compiler wouldn't have to look at the body to generate efficient code.
But the compiler has to look at the body anyway, in order to implement
generics (unless they are always code-shared) and pragmas Inline.
So the decision seems somewhat inconsistent to me.

If JDI had not invented private parts, so we just had spec and body, and
all the hidden stuff goes in the body, then when Tucker came along and
invented child packages, he would have given them visibility into the
body.  And we'd be having this same discussion about how do you prevent
evil children from seeing what they shouldn't.  I still think the right
answer is to restrict which children are allowed, rather than to have
yet another special visibility rule.

By the way, is the original poster worried that subunits can see all
kinds of hidden stuff in the parent body?  That case seems less
worrisome, because the parent mentions the names of all subunits.
The language could allow the same thing for children (but it shouldn't
*require* it).

- Bob

Re: Possible Ada deficiency?

[Jeffrey Carter]

Robert A Duff wrote:
> 
> The main thing is that the compiler needs to know the size of a private
> type in order to allocate things, unless it treats all private types as
> dynamic-sized, which would be annoying -- you shouldn't have to pay an
> efficiency cost to get the benefits of encapsulation, information
> hiding, etc.  So if the full type were in the body, the compiler would
> have to look at the body (at least in optimizing mode).

It's always seemed to me that such types could be implemented as access 
types, allocated where declared, deallocated when they went out of 
scope, and with all operations dealing with the designated value, not 
the access value.

All such types would, of course, be passed by reference.

-- 
Jeff Carter
"Sir Robin the-not-quite-so-brave-as-Sir-Lancelot,
who had nearly fought the Dragon of Angnor,
who nearly stood up to the vicious Chicken of Bristol,
and who had personally wet himself at the
Battle of Badon Hill."
Monty Python & the Holy Grail
68

Re: Possible Ada deficiency?

[Robert A Duff]

Jeffrey Carter <spam@spam.com> writes:

> Robert A Duff wrote:
> > The main thing is that the compiler needs to know the size of a private
> > type in order to allocate things, unless it treats all private types as
> > dynamic-sized, which would be annoying -- you shouldn't have to pay an
> > efficiency cost to get the benefits of encapsulation, information
> > hiding, etc.  So if the full type were in the body, the compiler would
> > have to look at the body (at least in optimizing mode).
> 
> It's always seemed to me that such types could be implemented as access
> types, allocated where declared, deallocated when they went out of
> scope, and with all operations dealing with the designated value, not
> the access value.

That could work.  But you don't *need* to do any heap allocation.
If you say:

    subtype My_String is String(1..X);

where X is a run-time quantity, and:

    type R is
        record
            A, B, C: My_String;
        end record;

    Obj: R;

most compilers will implement Obj as a contiguous hunk of storage.
Accessing the components of Obj requires adding the appropriate
offsets to the address of Obj (at run time).  But it's still more
efficient than putting the three strings on the heap.

Note that the upper bound of My_String is typically stored just once --
not in every object of type R.  And the lower bound need not be stored
at all.  (If A,B,C were aliased, then every object of type R would
typically contain 3 lower bounds and 3 upper bounds.)

If the compiler can't see the full type of a private type, then it could
do the same thing as for My_String -- just assume that the size is a
run-time quantity.  And, I suppose, assume worst-case alignment.

But I still don't like it.  I think there should be *zero* overhead for
making a type private.

> All such types would, of course, be passed by reference.

Well, that would require changing the current rules,
which require pass-by-copy for a private type if the
full type is elementary.  (I don't much like the existing rules
in this area, but I'm not sure the change suggested here would
be an improvement.  It would be seriously incompatible, for
one thing.)

- Bob

Re: Possible Ada deficiency?

[Jeffrey Carter]

Robert A Duff wrote:

> Jeffrey Carter <spam@spam.com> writes:
> 
>>All such types would, of course, be passed by reference.
> 
> Well, that would require changing the current rules,
> which require pass-by-copy for a private type if the
> full type is elementary.  (I don't much like the existing rules
> in this area, but I'm not sure the change suggested here would
> be an improvement.  It would be seriously incompatible, for
> one thing.)

It's not going to happen in Ada anyway, and if you designed a language 
to work this way, you wouldn't have such rules in the 1st place.

-- 
Jeff Carter
"I blow my nose on you."
Monty Python & the Holy Grail
03

Re: Possible Ada deficiency?

[danmcleran]

>If so, I think it's a minor one. As Randy pointed out, if you don't
>want child packages to do something nasty, then don't create any child
>packages.

Yes. But what if I want to hide implementation detail from all others
who would write child packages?

>In any case, as some folks have pointed out, you should think of
"adding
>a child of X" as very similar to "modifying the source code of X".

This is also spelled out in the Ada95 rationale. While I understand the
reasoning, I would also argue that it would be advantageous for a
package writer to have the power to restrict what child packages can
see and modify.

>If you don't want people to do that, you need some extra-lingual
>mechanism to restrict them.

That's exactly right. I would propose adding a new keyword,
'concealed', to allow a package writer to hide certain areas from all
child packages. A trivial example:

package Some_Package is
type Not_So_Secret_Type is private; --Child packages can see here
type Some_Type is concealed; --Child package cannot see here
private
--Child package can change Not_So_Secret_Value
type Not_So_Secret_Type is record
Not_So_Secret_Value : Integer := 0;
end record
concealed
--Child packages cannot change Secret_Value directly
type Some_Type is record
Secret_Value : Integer := 1;
end record
end Some_Package

With the addition of this construct, a package writer can choose what
areas should be directly visible to child packages, and what areas
should not. This would force a child package to use the parent
package's public interface when dealing with objects of type Some_Type,
rather than having full visibility into Some_Type's internal
representation.

Re: Possible Ada deficiency?

[danmcleran]

>By the way, is the original poster worried that subunits can see all
>kinds of hidden stuff in the parent body? That case seems less
>worrisome, because the parent mentions the names of all subunits.
>The language could allow the same thing for children (but it shouldn't
>*require* it).

I'm not sure what you mean by this. My only point is that there is no
way to hide internal representation details from child packages. I have
read the Ada95 rationale and I understand why child packages are
allowed and why they have the visibility they have. What I would like
in Ada is the power to hide implementation detail from child packages,
if I choose to do so.

I would propose adding a new keyword, 'concealed', to allow a package
writer to hide certain areas from all child packages.

package Some_Package is
type Not_So_Secret_Type is private; --Child packages can see here
type Some_Type is concealed; --Child package cannot see here
private
--Child package can change Not_So_Secret_Value
type Not_So_Secret_Type is record
Not_So_Secret_Value : Integer := 0;
end record
concealed
--Child packages cannot change Secret_Value directly
type Some_Type is record
Secret_Value : Integer := 1;
end record
end Some_Package

With the addition of this construct, a package writer can choose what
areas should be directly visible to child packages, and what areas
should not. This would force a child package to use the parent
package's public interface when dealing with objects of type Some_Type,
rather than having full visibility into Some_Type's internal
representation.

Re: Possible Ada deficiency?

[Robert A Duff]

Jeffrey Carter <spam@spam.com> writes:

> Robert A Duff wrote:
> 
> > Jeffrey Carter <spam@spam.com> writes:
> >
> >>All such types would, of course, be passed by reference.
> > Well, that would require changing the current rules,
> > which require pass-by-copy for a private type if the
> > full type is elementary.  (I don't much like the existing rules
> > in this area, but I'm not sure the change suggested here would
> > be an improvement.  It would be seriously incompatible, for
> > one thing.)
> 
> It's not going to happen in Ada anyway, ...

True.  I guess I shouldn't use upward compatibility in an argument about
pie-in-the-sky language design.

>...and if you designed a language
> to work this way, you wouldn't have such rules in the 1st place.

What rule would you prefer (in a from-scratch language design)?

The main thing I dislike about the Ada rule is that it is possible to
write code by accident that behaves differently because one compiler
chooses pass-by-copy and another one pass-by-reference.  And it's not
clear whose responsibility it is to worry about this kind of bug: should
procedures be written so that they work even in the presence of aliasing
among actual parameters?  Or should callers avoid that aliasing?  And
what can the caller know about data modified in a procedure that raised
an exception in the middle of processing?

I also think it's kludgy to treat (say) integers differently from
strings.  I understand the efficiency reason for this, but I still don't
like it.

I can think of several solutions, but I'm not sure which is best.
One idea is to define all parameter passing to be nominally by copy,
but add some features that allow the compiler to know enough about
global variables and whatnot, so that it can use by-reference in most
cases, having proved it doesn't make any difference.  That wouldn't work
in Ada because the compiler doesn't have enough information to do the
proof, in most cases.

- Bob

Re: Possible Ada deficiency?

[Robert A Duff]

danmcleran@hotmail.com writes:

> That's exactly right. I would propose adding a new keyword,
> 'concealed', to allow a package writer to hide certain areas from all
> child packages.

OK, but you haven't explained why you prefer that to the idea I
proposed: allow the person who writes a package to specify the names of
all children.  That seems pretty simple.  And if you have that complete
list, you can track down all the relevant code and control it.  You
can't add new "evil" children later (without modifying the parent).

There's not really much point in a child package that *can't* see the
parent's private part.  Such a child could just as well be declared at
the same level as the parent.  So if you want some 'concealed' stuff,
the simplest thing would be to declare that this package has no
children.

Your 'concealed' idea could work, but it seems to add a lot of
complexity (to a language that already has too-complex visibility
rules).

(Of course, as Jeff Carter pointed out, none of these changes are likely
to make it into a future version of Ada.  Certainly not Ada 2005 -- the
new feature set is pretty much cast in stone at this point.)

Does it bother you that subunits can access stuff in the parent *body*?

- Bob

Re: Possible Ada deficiency?

[Robert A Duff]

danmcleran@hotmail.com writes:

> >By the way, is the original poster worried that subunits can see all
> >kinds of hidden stuff in the parent body? That case seems less
> >worrisome, because the parent mentions the names of all subunits.
> >The language could allow the same thing for children (but it shouldn't
> >*require* it).
> 
> I'm not sure what you mean by this. My only point is that there is no
> way to hide internal representation details from child packages.

I mean: both child packages and subunits are separately compiled hunks
of code (separate from the parent).  Child packages have visibility on
the parent's private part, which you don't like.  Subunits have
visibility on the parent's body.  Is that equally bothersome?
I say, no, because the parent package lists the names of all the
subunits; you can't add new ones without modifying the parent.
And the parent can of course disallow subunits altogether.
So my suggested "fix" is to make child units more like subunits in this
one respect -- allow (not require) the parent to name the children,
or forbid children altogether.

If you answer "yes" to my question (please explain why), then you won't
like my suggested fix.

- Bob

Re: Possible Ada deficiency?

[Martin Dowie]

danmcleran@hotmail.com wrote:
> With the addition of this construct, a package writer can choose what
> areas should be directly visible to child packages, and what areas
> should not. This would force a child package to use the parent
> package's public interface when dealing with objects of type Some_Type,
> rather than having full visibility into Some_Type's internal
> representation.

I'm not sure but isn't this going to lead to some potentially horrible 
situations, e.g. the 'private' part needs to embed a 'concealed' part 
within a type? How would you treat mutual dependencies between such 
types? Etc.

Cheers

-- Martin

Re: Possible Ada deficiency?

[Nick Roberts]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote:

> Nick Roberts <nick.roberts@acm.org> writes:
> 
> > I've heard the same, and I think it might be correct. There's no real
> > technical barrier to types being completed in the body, other than it
> > might cause some compilers to have to (effectly) make an extra pass.
> > (Correct?)
> 
> I'm not sure what you mean by "extra pass".  The issue is whether the
> compiler looks at the body while compiling clients.

Yes, sorry, that's what I should have said.

> The main thing is that the compiler needs to know the size of a private
> type in order to allocate things, unless it treats all private types as
> dynamic-sized, which would be annoying -- you shouldn't have to pay an
> efficiency cost to get the benefits of encapsulation, information hiding,
> etc.  So if the full type were in the body, the compiler would have to
> look at the body (at least in optimizing mode).

I agree completely.

> And if the compiler looks at the body, then you have to recompile all the
> clients when the body changes (unless you're doing fancy incremental
> compilation -- that's the kind of compiler I'd really like to have!).

I don't think it would have to be that fancy. A simple but effective
strategy would be for the compiler to remember the size of each private type
(completed in the body), and recompile library units dependent on the
specification if any of these types changed size. In addition, it might
recompile library units which use (call or instantiate) an inline subprogram
or generic unit if the body of that subprogram or generic unit got changed.

> Another point is that the rules about whether to pass by copy or by
> reference depend on the full type.  I don't much like that, but anyway,
> the compiler would have to look at the body to find out, unless the
> decision is made at run time, which would be grossly inefficient.

Again, the compiler could simply remember the category of each full type
(elementary, tagged, task or protected, composite with by-reference
subcomponent), and recompile as necessary if it got changed.

> So I guess the Ada 83 designers invented the private part so the compiler
> wouldn't have to look at the body to generate efficient code. But the
> compiler has to look at the body anyway, in order to implement generics
> (unless they are always code-shared) and pragmas Inline. So the decision
> seems somewhat inconsistent to me.

Exactly. I couldn't agree more. And for a compiler that is to perform global
optimisations anyway, almost pointless. Obviously, the practicality of such
compilers was generally less in the early 1980s than it is now.

> If JDI had not invented private parts, so we just had spec and body, and
> all the hidden stuff goes in the body, then when Tucker came along and
> invented child packages, he would have given them visibility into the
> body.  And we'd be having this same discussion about how do you prevent
> evil children from seeing what they shouldn't.  I still think the right
> answer is to restrict which children are allowed, rather than to have yet
> another special visibility rule.

I suppose it is slightly idle speculation (not that I'm averse to idle
speculation ;-) but I think we all have our own ideas about how the perfect
language should have been. (By the way, on a historical note JDI stands for
'Jean Ichbiah', the leader of the team who developed the Ada 83 standard.)

One idea would have been to eliminate the principle of having to declare
things in advance of their use. Ada takes this approach to goto labels, in
fact. When something was used, for example a procedure call:

   Foo(Bar,Hum);

the compiler would simply note the need for an object Bar, and an object
Hum, and a procedure with profile Foo(Bar'Type,Hum'Type).

At the end of the compilation process, the compiler would say "Was there a
declaration of an object Bar?" Assuming there was, its type must now be
known, let's say T1. The compiler would do the same thing with Hum, let's
say its type was T2. Then the compiler would say "Was there a declaration of
a procedure fitting profile Foo(T1,T2)?" If there wasn't, or if there was an
ambiguity, it could report the error.

This way, package specifications wouldn't be needed. You would actually have
a private part in the body, which would contain the declarations of things
not to be exported.

Of course, this approach didn't fit the prevailing compilation model of
those days (the 1980s). Just an idle thought.

-- 
Nick Roberts

Re: Possible Ada deficiency?

[Jeffrey Carter]

danmcleran@hotmail.com wrote:

>>In any case, as some folks have pointed out, you should think of
> "adding
>>a child of X" as very similar to "modifying the source code of X".
> 
> This is also spelled out in the Ada95 rationale. While I understand the
> reasoning, I would also argue that it would be advantageous for a
> package writer to have the power to restrict what child packages can
> see and modify.
> 
>>If you don't want people to do that, you need some extra-lingual
>>mechanism to restrict them.
> 
> That's exactly right. I would propose adding a new keyword,
> 'concealed', to allow a package writer to hide certain areas from all
> child packages. A trivial example:

This is not an extra-lingual mechanism. As long as people can modify the 
source of the parent, there's no real point in restricting child 
packages any more than they already are.

-- 
Jeff Carter
"You cheesy lot of second-hand electric donkey-bottom biters."
Monty Python & the Holy Grail
14

Re: Possible Ada deficiency?

[Martin Krischik]

Nick Roberts wrote:

> This way, package specifications wouldn't be needed. You would actually
> have a private part in the body, which would contain the declarations of
> things not to be exported.

But you are missing the documentation value of an specification. Library
vendors would need something like JavaDoc then to extract the informations
they want to hand out to your customers.

Martin

(Of course personaly I prefer open source as well)
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Possible Ada deficiency?

[Jeffrey Carter]

Robert A Duff wrote:

> What rule would you prefer (in a from-scratch language design)?

That's hard to tell, since I haven't really designed such a language. 
Perhaps simply that the rule for a private type may be different from 
the rule if the full type were visible. That would allow compilers to 
implement a private type as a secret access type, but not prevent 
compilers from using other approaches, such as looking at the full type 
in the body and using that information, or allocating objects 
dynamically at run time.

> The main thing I dislike about the Ada rule is that it is possible to
> write code by accident that behaves differently because one compiler
> chooses pass-by-copy and another one pass-by-reference.  And it's not
> clear whose responsibility it is to worry about this kind of bug: should
> procedures be written so that they work even in the presence of aliasing
> among actual parameters?  Or should callers avoid that aliasing?  And
> what can the caller know about data modified in a procedure that raised
> an exception in the middle of processing?

It seems pretty clear to me that it's the procedure's responsibility. 
Code that relies on the parameter-passing mechanism for types with an 
undefined mechanism has an error.

-- 
Jeff Carter
"You cheesy lot of second-hand electric donkey-bottom biters."
Monty Python & the Holy Grail
14

Re: Possible Ada deficiency?

[Robert A Duff]

Nick Roberts <nick.roberts@acm.org> writes:

> Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
> > The main thing is that the compiler needs to know the size of a private
> > type in order to allocate things, unless it treats all private types as
> > dynamic-sized, which would be annoying -- you shouldn't have to pay an
> > efficiency cost to get the benefits of encapsulation, information hiding,
> > etc.  So if the full type were in the body, the compiler would have to
> > look at the body (at least in optimizing mode).
> 
> I agree completely.

Well, I don't.  ;-)

I said "at least in optimizing mode", implying that the compiler could
choose a compile-time-efficient method of record layout (not looking at
the body) or a run-time-efficient one (looking at the body), depending
on some optimization switch.  But now that I think about it, that might
not be a good idea.  It might be disconcerting to programmers if record
layout changes depending on compiler switches, especially if those
records are written to files.  Hmm...

> I don't think it would have to be that fancy.

Well, I don't think incremental compilers are trivial.  (I've built
them, but not for Ada.)  But I agree they are feasible and desirable.
The granularity of incrementality need not be very fine in order to get
the benefits.

>... A simple but effective
> strategy would be for the compiler to remember the size of each private type

But it's not just the size of private types and a couple of other
things.  It's any piece of information that affects the generated code.
This depends on how much optimization is done, but it could include all
kinds of things: alignment, whether a type contains tasks, whether a
type has finalization, whether a parameter is small enough to pass in a
register, whether the value of a deferred constant is known at compile
time, and if so, the value, whether various dope (such as array bounds)
is known at compile time, and if so, the values, &c.

And if you forget one such item, you've got a very nasty compiler bug:
rebuilding misses some changes to your code.

The source-based compilation model of GNAT and AdaMagic seems much
simpler, although much less efficient at compile time.

Another problem with moving private-part stuff into the body would be
elaboration order problems.  The freezing rules wouldn't work at all.
(The freezing rules are an abomination, though, and I wouldn't mind a
total redesign of that area.)  But the point is, you need to prevent
things like creating an object of a given type before its full type has
been elaborated.  We do run-time checks for subprograms, which is
somewhat ugly in my opinion; I suppose that could work for private
types, too.

Another issue: I wonder if it would wreak havoc with representation
clauses.

> I suppose it is slightly idle speculation (not that I'm averse to idle
> speculation ;-) but I think we all have our own ideas about how the perfect
> language should have been.

I've got lots of ideas.  ;-)

And I think programming language design is in its infancy.
There may never be a "perfect" language, but we can do a lot better
than any existing language.

>... (By the way, on a historical note JDI stands for
> 'Jean Ichbiah', the leader of the team who developed the Ada 83 standard.)

Yes, thank you.  I shouldn't have assumed everybody knows that.
And Tucker was the leader of the Ada 95 design team, of which I
was a member.

> One idea would have been to eliminate the principle of having to declare
> things in advance of their use. Ada takes this approach to goto labels, in
> fact. When something was used, for example a procedure call:
> 
>    Foo(Bar,Hum);
> 
> the compiler would simply note the need for an object Bar, and an object
> Hum, and a procedure with profile Foo(Bar'Type,Hum'Type).
> 
> At the end of the compilation process, the compiler would say "Was there a
> declaration of an object Bar?" Assuming there was, its type must now be
> known, let's say T1. The compiler would do the same thing with Hum, let's
> say its type was T2. Then the compiler would say "Was there a declaration of
> a procedure fitting profile Foo(T1,T2)?" If there wasn't, or if there was an
> ambiguity, it could report the error.

Nick, I don't know how to say this politely: You're stark raving mad! ;-)

If Foo is overloaded, the above mechanism would be complicated beyond
belief.  And note that Bar could be a parameterless function.

If Ada allowed forward references, a two-pass semantic analysis
algorithm could work reasonably.  But the above-suggested method seems
completely infeasible to me.

Anyway, I think the main reason for disallowing forward references was
to make code more readable, not just to make the compiler's life easier.

Allowing forward references also introduces elaboration-order problems,
and circularity problems.  Probably solvable, but more rules would be
needed.  For example:

    type T1 is range 1..T2'Last; -- currently illegal
    type T2 is range 1..T1'Last;

> This way, package specifications wouldn't be needed. You would actually have
> a private part in the body, which would contain the declarations of things
> not to be exported.
> 
> Of course, this approach didn't fit the prevailing compilation model of
> those days (the 1980s). Just an idle thought.

Package specs are not (primarily) for the benefit of the compiler.
They are there to provide a contract -- a definition of the interface
between a package and its clients.  The visible part is a Good Thing.
It's just the private part that seems kludgy.

- Bob

Re: Possible Ada deficiency?

[Robert A Duff]

Nick Roberts <nick.roberts@acm.org> writes:

> One idea would have been to eliminate the principle of having to declare
> things in advance of their use. Ada takes this approach to goto labels, in
> fact.

I don't much like the rules about goto labels.  They cause a lot of
implementation difficulty for near-zero benefit to programmers.  And
goto's are little used -- even if there were a benefit, it's not worth
any extra trouble.

I implemented those rules in GNAT when I was consulting for ACT.
As a compiler writer, I find it very dissatisfying to do extra work that
doesn't benefit my user community.

This is one area Pascal got right.

- Bob

Re: Possible Ada deficiency?

[Nick Roberts]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote:

> ...
> The main thing I dislike about the Ada rule is that it is possible to
> write code by accident that behaves differently because one compiler
> chooses pass-by-copy and another one pass-by-reference.  And it's not
> clear whose responsibility it is to worry about this kind of bug: should
> procedures be written so that they work even in the presence of aliasing
> among actual parameters?  Or should callers avoid that aliasing?  And what
> can the caller know about data modified in a procedure that raised an
> exception in the middle of processing?
> 
> I also think it's kludgy to treat (say) integers differently from strings.
> I understand the efficiency reason for this, but I still don't like it.

Yes, I think this is one of the nastiest gotchas in Ada. It's even worse
that Ada is supposed to be a multitasking-friendly language.

> I can think of several solutions, but I'm not sure which is best. One idea
> is to define all parameter passing to be nominally by copy, but add some
> features that allow the compiler to know enough about global variables and
> whatnot, so that it can use by-reference in most cases, having proved it
> doesn't make any difference.  That wouldn't work in Ada because the
> compiler doesn't have enough information to do the proof, in most cases.

A couple of facilities would help.

One would be a pragma that declared two parameters (of the same type) of a
subprogram unaliased. At each call, a static check would be made if
possible, otherwise code inserted to make a dynamic check (that the same
object had not been passed as the actual for both parameters). I suppose
this would be similar to an assertion or pre-condition.

The other would be a pragma that declared a subprogram non-reentrant. A flag
(global at the level of the declarative region immediately containing the
subprogram) would be set upon entry and reset on exit. Just before setting
the flag, a test would be made: if the flag is already set, raise an
exception. The compiler could catch obvious breaches (such as a recursive
call).

There could be a couple of checks associated with these pragmas, named
Aliasing_Check and Reentrancy_Check perhaps, for use by the Suppress pragma.

-- 
Nick Roberts

Re: Possible Ada deficiency?

[danmcleran]

I believe you are referring to separate compilation. If so, no separate
compilation does not bother me. I don't think that this is the same
thing. I also don't believe that requiring the parent package to
declare child packages is desirable, since the declared child packages
would still have full visibility into the parent package. I still
believe that the ability to hide information from all child packages is
a desireable feature. That way, whatever one wants child packages to
see can be declared private. If one wants to hide some implementation
detail from child packages, the one could declare them 'concealed'.

The best thing about this proposed feature is, if you don't want to
use it, then don't. It would not affect any current code.

Re: Possible Ada deficiency?

[danmcleran]

>OK, but you haven't explained why you prefer that to the idea I
>proposed: allow the person who writes a package to specify the names
of
>all children.

I don't think that this is the right way to go. What I view as the
problem is that child packages have full visibility into the parent
package, with no way to prevent it. Forward-declaring child packages
doesn't solve this problem.

>Does it bother you that subunits can access stuff in the parent
*body*?

Separate compilation and child package visibility into parent packages
are not the same issue, IMO.

Re: Possible Ada deficiency?

[danmcleran]

I don't think it needs to be this complicated an issue. The only
mechanism I'm proposing is that a parent package can choose to hide
detail(s) from child packages. There would be 3 areas of visibilty:
public, private, & concealed.

Re: Possible Ada deficiency?

[danmcleran]

Well, then why not make everything public and forget the whole idea of
encapsulation altogether?

Re: Possible Ada deficiency?

[Dmitry A. Kazakov]

On Sun, 9 Jan 2005 21:56:13 +0000, Nick Roberts wrote:

> One would be a pragma that ...

Another thing *I* would remove from the language is pragmas! At least I
would not allow them anywhere except bodies.

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

Re: Possible Ada deficiency?

[Duncan Sands]

> Another thing *I* would remove from the language is pragmas! At least I
> would not allow them anywhere except bodies.

What about pragma Inline?

All the best,

Duncan.

Re: Possible Ada deficiency?

[Pascal Obry]

Duncan Sands <baldrick@free.fr> writes:

> > Another thing *I* would remove from the language is pragmas! At least I
> > would not allow them anywhere except bodies.
> 
> What about pragma Inline?

And Import / Export / Interface ? Since there is no body in those cases :)

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Possible Ada deficiency?

[Dmitry A. Kazakov]

On 10 Jan 2005 18:58:12 +0100, Pascal Obry wrote:

> Duncan Sands <baldrick@free.fr> writes:
> 
>>> Another thing *I* would remove from the language is pragmas! At least I
>>> would not allow them anywhere except bodies.
>> 
>> What about pragma Inline?

I would leave all optimization issues to the compiler.

A separate case is inlining and executing of a static pure function at
compile-time to get a static value. Unfortunately it is not Ada. But if it
would then it should be a syntactic construct indicating declaration of a
pure function, not a pragma 

> And Import / Export / Interface ? Since there is no body in those cases :)

You mean that there is a non-Ada body. But for Import I would provide an
Ada body and place the pragma there (if that should be a pragma). Later one
could replace the body with an Ada implementation and vise versa *without*
touching specifications.

---
I consider pragmas as a dangerous, quick and dirty way of patching language
holes instead of searching for an appropriate generalization.

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

Re: Possible Ada deficiency?

[Pascal Obry]

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

> You mean that there is a non-Ada body. But for Import I would provide an
> Ada body and place the pragma there (if that should be a pragma). Later one
> could replace the body with an Ada implementation and vise versa *without*
> touching specifications.

Ok, but it seems wrong to me to hide Export/Import. This is definitly part of
the interface. Reviewers/Users must know if this is imported or not. Idem for
Inline, this is really part of the spec and tells you that the code will be
inline in yours. If you have size considerations for your code it seems quite
important to note this just by reading the spec.

Just my 2 cents,
Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Possible Ada deficiency?

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wccwtun9481.fsf@shell01.TheWorld.com...
...
> So I guess the Ada 83 designers invented the private part so the
> compiler wouldn't have to look at the body to generate efficient code.
> But the compiler has to look at the body anyway, in order to implement
> generics (unless they are always code-shared) and pragmas Inline.
> So the decision seems somewhat inconsistent to me.

I viewed the intent of the Ada 83 design to be exactly that: no looking at
the body is required. Generics should be shared, inline is a hint and the
dependencies need not (and should not) be used. Do any inlining/macro
expansion at link-time. Certainly I wasn't the only one who thought that was
the intent. Machines of the era weren't really powerful enough to implement
that intent, thus the hacks of the generic dependency and the inline
dependency were allowed.

Of course, Ada 95 came along and changed that intent. Which is too bad, as
machines now are powerful enough to implement the Ada 83 intent!

                      Randy Brukardt

Re: Possible Ada deficiency?

[Randy Brukardt]

<danmcleran@hotmail.com> wrote in message
news:1105327132.335673.73950@c13g2000cwb.googlegroups.com...
> I don't think it needs to be this complicated an issue. The only
> mechanism I'm proposing is that a parent package can choose to hide
> detail(s) from child packages. There would be 3 areas of visibilty:
> public, private, & concealed.

There are already three areas of visibility: public/private/body, and you're
suggesting to add a fourth (not third). And, as I previously indicated, the
three existing areas of visibility have caused no end of problems, both at
the language definition level, and in implementations.

Moreover, this idea would require a large number of additional rules to
explain, and almost certainly would introduce lots of new bugs.

"I don't think is needs to be this complicated an issue." Visibility is an
extremely complicated issue; changes to it have to be made with extreme
care. Limited with proved to be very, very difficult to get right (mostly
because of obscure issues with use clauses and renames of child packages
that no one would ever try to do in practice). Your suggestion would be much
worse.

It also would make Ada programs harder to read and write, because you'd have
to declare things out of the usual order to put them into the right "part".

In any case, infinite repetition that your solution is "simple" is not going
to make it so. Putting private types in the body is the right solution,
because it hides the information without adding new visibility. But that too
is too big a leap for right now.

                     Randy.

Re: Possible Ada deficiency?

[Robert A Duff]

danmcleran@hotmail.com writes:

> I don't think it needs to be this complicated an issue. The only
> mechanism I'm proposing is that a parent package can choose to hide
> detail(s) from child packages. There would be 3 areas of visibilty:
> public, private, & concealed.

(It would be helpful if you would quote what you're responding to,
so people can see the context.)

I *think* you are claiming that the 'concealed' feature is simple and
easy to implement.  In fact, the existing visibility rules are already
quite hard to implement.  (I've done it; either I'm stupid, or it's hard
to get right. ;-) ) I suspect 'concealed' would add a fairly large hunk
of complexity.  Not impossible, but probably not worth it.

- Bob

Re: Possible Ada deficiency?

[danmcleran]

>Putting private types in the body is the right solution,
>because it hides the information without adding new visibility. But
that too
>is too big a leap for right now.
I would agree that this is a good solution.

Re: Possible Ada deficiency?

[danmcleran]

>I *think* you are claiming that the 'concealed' feature is simple and
>easy to implement.
I'm not claiming anything, I'm just saying I'd like to have it.

Re: Possible Ada deficiency?

[Robert A Duff]

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

> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
> news:wccwtun9481.fsf@shell01.TheWorld.com...
> ...
> > So I guess the Ada 83 designers invented the private part so the
> > compiler wouldn't have to look at the body to generate efficient code.
> > But the compiler has to look at the body anyway, in order to implement
> > generics (unless they are always code-shared) and pragmas Inline.
> > So the decision seems somewhat inconsistent to me.
> 
> I viewed the intent of the Ada 83 design to be exactly that: no looking at
> the body is required. Generics should be shared,

"Generics should be shared", says the man who wrote the only Ada
compiler in the world that always shares generics.  ;-)

I tend to agree, if we're talking about an "ideal world".  Ideally, the
semantics of generics would be defined in a way that makes sharing the
obvious default choice.  (Eiffel does this.)  Then macro expansion would
be an optimization, just like inlining.

And (in that ideal world) I would view a compiler that doesn't support
inlining, or doesn't support non-shared generics, as insufficient.

But this would be a radical change to the language.  For example, the
rules about whether parameters are passed by copy or reference should
not depend on the actual type passed to a generic formal type.

>... inline is a hint and the
> dependencies need not (and should not) be used. Do any inlining/macro
> expansion at link-time.

I don't see link-time as an improvement.  Whether you do this work at
compile time or link time, it still costs in terms of rebuild time.
And either way, you have to redo the work when the body changes.

>...Certainly I wasn't the only one who thought that was
> the intent.

But you're the only one who implemented it that way!

>...Machines of the era weren't really powerful enough to implement
> that intent, thus the hacks of the generic dependency and the inline
> dependency were allowed.
> 
> Of course, Ada 95 came along and changed that intent.

I don't understand that.  Maybe I don't understand what you mean by
"that intent".  Which rules of Ada 95 are you talking about, here?

>... Which is too bad, as
> machines now are powerful enough to implement the Ada 83 intent!

I don't understand that, either.  Are you saying that the run-time
overhead of the always-share model is now acceptable?

- Bob

Re: Possible Ada deficiency?

[Robert A Duff]

danmcleran@hotmail.com writes:

> Well, then why not make everything public and forget the whole idea of
> encapsulation altogether?

I've no idea what you're replying to here, but note that the point of
the visibility rules is documentation: you can tell, by reading the
code, which hunks of code can access which variables.  There is no
security goal here (i.e. prevent evil programmers from accessing
variables they shouldn't).

Why not go even further than your 'concealed' idea?  As in Eiffel, where
each class can name which other classes are allowed to meddle with
particular features of this class.

By the way, there's one question you haven't answered.  You desire to
prevent children from accessing parent-private stuff.  OK, that's a
legitimate concern.  But if you have a package X.Y that does not want to
access private-X stuff, then why do you want it to be a child in the
first place?

In my suggested solution, X could declare "I have no children", and then
Y would have to be *not* a child of X.  But obviously it doesn't *need*
to be a child of X, since it does not access private-X stuff.

Note that you can always declare an *empty* root package X, and have
children Y and Z that cannot access each other's private stuff.
And with my suggestion you could declare X.Y and/or X.Z to have no
children.  No children implies children cannot access private stuff!

- Bob

Re: Possible Ada deficiency?

[danmcleran]

>But if you have a package X.Y that does not want to
>access private-X stuff, then why do you want it to be a child in the
>first place?

That's not the point. If I am writing a package, I want to be able to
hide certain stuff from all future child packages. I may be the one
writing the child package, I may not be. The way I'm thinking in this
discussion is I am not the one writing the child package. So, that
being said, I want to have a way to hide certain implementation details
from all future child packages, written by whomever.

The private area would remain as-is, with child packages having full
visibility there. The 'concealed' area is an area that I do not want
child packages messing with. I would only put things, (mostly type(s)),
in the 'concealed' area that I want fully encapsulated from the outside
world, including child packages. This would force a child package to
use the public or private interface of the parent package for types
declared 'concealed'.

>In my suggested solution, X could declare "I have no children", and
then
>Y would have to be *not* a child of X.

I would like a variation of this idea. If one could specify that a
package could not have child packages, then the compiler could prevent
someone from even compiling X.Y. It would be nice to prevent future
developers from writing child packages if you don't want them to.

>But obviously it doesn't *need*
>to be a child of X, since it does not access private-X stuff.

That's not what I'm saying. I would not propose re-defining private. I
would propose the addition of 'concealed'.

Re: Possible Ada deficiency?

[Jeffrey Carter]

Robert A Duff wrote:

> By the way, there's one question you haven't answered.  You desire to
> prevent children from accessing parent-private stuff.  OK, that's a
> legitimate concern.  But if you have a package X.Y that does not want to
> access private-X stuff, then why do you want it to be a child in the
> first place?

Another way to phrase this question is, "Why does package Ada have 
children, since it has no private part?"

Obviously, there are uses for children that do not access their parents' 
private stuff.

-- 
Jeff Carter
"That was the most fun I've ever had without laughing."
Annie Hall
43

Re: Possible Ada deficiency?

[Robert A Duff]

Jeffrey Carter <spam@spam.com> writes:

> Robert A Duff wrote:
> 
> > By the way, there's one question you haven't answered.  You desire to
> > prevent children from accessing parent-private stuff.  OK, that's a
> > legitimate concern.  But if you have a package X.Y that does not want to
> > access private-X stuff, then why do you want it to be a child in the
> > first place?
> 
> Another way to phrase this question is, "Why does package Ada have
> children, since it has no private part?"

Good point!

> Obviously, there are uses for children that do not access their parents'
> private stuff.

Yes, I guess I have to admit I was wrong...

- Bob

Re: Possible Ada deficiency?

[Vinzent 'Gadget' Hoefler]

Dmitry A. Kazakov wrote:

> On 10 Jan 2005 18:58:12 +0100, Pascal Obry wrote:
> 
>> Duncan Sands <baldrick@free.fr> writes:
>> 
>>>> Another thing *I* would remove from the language is pragmas! At
>>>> least I would not allow them anywhere except bodies.
>>> 
>>> What about pragma Inline?
> 
> I would leave all optimization issues to the compiler.

Hmm. Then: What about pragma Volatile? pragma Atomic? Or all these
interesting ones from Annexes D, E & H?


Vinzent.

Re: Possible Ada deficiency?

[Dmitry A. Kazakov]

On Tue, 11 Jan 2005 07:24:10 +0000, Vinzent 'Gadget' Hoefler wrote:

> Dmitry A. Kazakov wrote:
> 
>> On 10 Jan 2005 18:58:12 +0100, Pascal Obry wrote:
>> 
>>> Duncan Sands <baldrick@free.fr> writes:
>>> 
>>>>> Another thing *I* would remove from the language is pragmas! At
>>>>> least I would not allow them anywhere except bodies.
>>>> 
>>>> What about pragma Inline?
>> 
>> I would leave all optimization issues to the compiler.
> 
> Hmm. Then: What about pragma Volatile? pragma Atomic?

Atomic and volatile are not about optimization. They describe a contract.
It is wrong to use pragmas for them. Maybe in C++, which does not deal with
concurrency it would be appropriate, but definitely not in Ada. It is clear
why these pragmas appeared. But it is also clear how they could disappear.
With full  ADT an "atomic Integer" will implement abstract protected
object. No need in any pragmas!

> Or all these interesting ones from Annexes D, E & H?

It depends on each concrete case. But the principle is simple, there should
be no pragmas influencing contracts. So they need not appear in
specifications. Therefore they should be forbidden there.

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

Re: Possible Ada deficiency?

[Dmitry A. Kazakov]

On 10 Jan 2005 20:44:42 +0100, Pascal Obry wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> You mean that there is a non-Ada body. But for Import I would provide an
>> Ada body and place the pragma there (if that should be a pragma). Later one
>> could replace the body with an Ada implementation and vise versa *without*
>> touching specifications.
> 
> Ok, but it seems wrong to me to hide Export/Import. This is definitly part of
> the interface.

To me it is just an implementation.

> Reviewers/Users must know if this is imported or not.

What for? What about specifying the library version number of the imported
thing? Reviewer must rely on the contract. Linkage issues are not a
contract to me.

> Idem for
> Inline, this is really part of the spec and tells you that the code will be
> inline in yours. If you have size considerations for your code it seems quite
> important to note this just by reading the spec.

If so, then it must be a syntax like in C++ not a pragma. And the issue
here is not the code size. Because it is quite difficult to predict. The
only issue I see here is evaluation of constants at compile time. For
example:

procedure Trace (Text : String);
pragma Inline Trace;

procedure Trace (Text : String) is
begin
   if Trace_On then
      Put (Text);
   end if;
end Trace;

When Trace_On is statically False we hope the compiler will remove calls to
Trace upon inlining. In my view this issue should be controlled not by
pragmas by the contract. If that were possible in some reasonably general
way then we could do much more useful things than Trace above. We could
allow user-defined array dopes, remove statically known discriminants, have
specific object without tags.

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

Re: Possible Ada deficiency?

[Vinzent 'Gadget' Hoefler]

Dmitry A. Kazakov wrote:

> On Tue, 11 Jan 2005 07:24:10 +0000, Vinzent 'Gadget' Hoefler wrote:
> 
>> Dmitry A. Kazakov wrote:
>> 
>>> I would leave all optimization issues to the compiler.
>> 
>> Hmm. Then: What about pragma Volatile? pragma Atomic?
> 
> Atomic and volatile are not about optimization. They describe a
> contract. It is wrong to use pragmas for them. Maybe in C++, which
> does not deal with concurrency it would be appropriate, but definitely
> not in Ada. It is clear why these pragmas appeared.

Atomic and/or Volatile are not necessarily about concurrency. Sometimes
they are just about hardware.

> With full  ADT an "atomic Integer" will implement abstract protected
> object. No need in any pragmas!

Hmm. So instead of

|   type Timer_Mode is
|   record
|      BCD : Count;
|      CM  : Count_Mode;
|      RWM : Read_Write_Mode;
|      SC  : Counter_Select;
|   end record;
|   [aspect clauses]
|   pragma Atomic (Timer_Mode);

you'd like to write

|   type Timer_Mode is
|   atomic record
|     [...]

?

Hmm.

>> Or all these interesting ones from Annexes D, E & H?
> 
> It depends on each concrete case.

Remote_Call_Interface? Interrupt_Priority? Attach_Handler?
Inspection_Point?


Vinzent.

Re: Possible Ada deficiency? (goto)

[Peter Hermann]

Robert A Duff <bobduff@shell01.theworld.com> wrote:
> I don't much like the rules about goto labels.  They cause a lot of

I like them because they are useful.

> As a compiler writer, I find it very dissatisfying to do extra work that
> doesn't benefit my user community.

As a bus driver, I find it very dissatisfying to have those 
annoying passengers.

-- 
--Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de
--Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
--http://www.csv.ica.uni-stuttgart.de/homes/ph/
--Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: Possible Ada deficiency? (goto)

[Nick Roberts]

Peter Hermann <ica2ph@sinus.csv.ica.uni-stuttgart.de> wrote:

> Robert A Duff <bobduff@shell01.theworld.com> wrote:

> > As a compiler writer, I find it very dissatisfying to do extra work that
> > doesn't benefit my user community.
> 
> As a bus driver, I find it very dissatisfying to have those annoying
> passengers.

I don't think Bob was complaining about the passengers, I think he was
complaining about having to drive an empty bus, Hermann.

-- 
Nick Roberts

Re: Possible Ada deficiency?

[Georg Bauhaus]

danmcleran@hotmail.com wrote:
 


:  It would be nice to prevent future
: developers from writing child packages if you don't want them to.

If you prevent programmers from extending software I can't see
how that's nice. ;-)
If the software depends on things staying concealed, why not just
write a short comment explaining this and possible consequences of
misuse?
 Or, if children/body need consistent common "service variables"
or servicing components of a tagged type, or ... or service routines
from the private part of parent, why not use some totally separate service
package together with a has-a relation? You could even use
a protected type in the service package for regulating how access is
granted to the service.
 OK it's not the same as Java's private, or as Ada's body.


-- Georg

Re: Possible Ada deficiency?

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wccbrbx3qbp.fsf@shell01.TheWorld.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
...
> >... inline is a hint and the
> > dependencies need not (and should not) be used. Do any inlining/macro
> > expansion at link-time.
>
> I don't see link-time as an improvement.  Whether you do this work at
> compile time or link time, it still costs in terms of rebuild time.
> And either way, you have to redo the work when the body changes.

Sure, but if the extra rebuild time isn't significant, who cares?

> >...Certainly I wasn't the only one who thought that was
> > the intent.
>
> But you're the only one who implemented it that way!

I certainly wasn't the only one to share generics by default. I'm pretty
sure the old Rational compiler worked the same way. I'm the only one
bull-headed enough to maintain that approach in the face of Ada 95, though.
:-)

> >...Machines of the era weren't really powerful enough to implement
> > that intent, thus the hacks of the generic dependency and the inline
> > dependency were allowed.
> >
> > Of course, Ada 95 came along and changed that intent.
>
> I don't understand that.  Maybe I don't understand what you mean by
> "that intent".  Which rules of Ada 95 are you talking about, here?

There are many rules of Ada 95 that make sharing impractical (not
impossible, just impractical). For instance, there was no reason in Ada 83
to make the size of generic formal types the same as the actual type. (Ada
95 requires that because of aliased objects.) Whereas, Ada 83 had just one
(the previously mentioned parameter passing style), and there never has been
a test written that could show the difference (such a test would be very
dubious anyway).

> >... Which is too bad, as
> > machines now are powerful enough to implement the Ada 83 intent!
>
> I don't understand that, either.  Are you saying that the run-time
> overhead of the always-share model is now acceptable?

No, I was thinking of the time/space requirements for building such a
compiler "properly". We didn't really implement my design because our hosts
didn't have enough memory to store the intermediate code for the entire
program, and a disk-based solution would be way too slow. It would be
practical on modern machines (other than that I can't predict the
performance of the optimization pass, which would be critical to making the
scheme work. We'd have to build it to see).

Note that with the design that I had in mind, the run-time overhead of
"always share" (as you put it) would be greatly reduced by partial
evaluation and inlining optimizations -- done at link-time so that all of
the instantiations and calls are known. Plus, pragma Inline could be used to
reduce the overhead to nearly nil on critical stuff. The problem isn't the
run-time overhead so much as it is supporting the optimizations necessary to
mitigate it.

                                Randy.



> - Bob

Re: Possible Ada deficiency?

[danmcleran]

>If the software depends on things staying concealed, why not just
>write a short comment explaining this and possible consequences of
>misuse?

For the same reason that all these higher-level languages have any of
the visibility constructs, so that the compiler can enforce desired
information hiding.

IMO, a construct that allows the compiler to ensure information hiding
is the best way to solve these problems.

Re: Possible Ada deficiency?

[danmcleran]

>I've no idea what you're replying to here,

What I'm replying to is the argument that additional visibility
restrictions aren't warranted because anyone can change the code to
change the visibility. That seems like a pretty silly argument. If one
takes this to the logical extreme, what's the point of having any
information hiding capabilities at all? Couldn't someone always just
change the code and change the visibility? Of course they could.

>but note that the point of
>the visibility rules is documentation

I don't buy this at all. I don't believe that the sole reason for
visibility rules is documentation. There's obviously an intent to
provide some information hiding and separation of interface from
implementation.

Re: Possible Ada deficiency?

[Robert A Duff]

danmcleran@hotmail.com writes:

> >I've no idea what you're replying to here,
> 
> What I'm replying to is the argument that additional visibility
> restrictions aren't warranted because anyone can change the code to
> change the visibility. That seems like a pretty silly argument. If one
> takes this to the logical extreme, what's the point of having any
> information hiding capabilities at all? Couldn't someone always just
> change the code and change the visibility? Of course they could.

OK, I agree with that.  I certainly don't advocate eliminating the
visibility rules.

> >but note that the point of
> >the visibility rules is documentation
> 
> I don't buy this at all. I don't believe that the sole reason for
> visibility rules is documentation. There's obviously an intent to
> provide some information hiding and separation of interface from
> implementation.

I agree, but I call that documentation.  All this good info hiding and
whatnot doesn't affect the input/output behavior of the program.  But it
does document the logical structure of the program (such as which parts
of the code can meddle with which variables).  And (as you pointed out
in another note), the advantage of *this* kind of documentation (over
comments) is that it is trustworthy, whereas comments can and often do
contain misinformation.

- Bob

Re: Possible Ada deficiency?

[Robert A Duff]

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

> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
> news:wccbrbx3qbp.fsf@shell01.TheWorld.com...
> > "Randy Brukardt" <randy@rrsoftware.com> writes:
> ...
> > >... inline is a hint and the
> > > dependencies need not (and should not) be used. Do any inlining/macro
> > > expansion at link-time.
> >
> > I don't see link-time as an improvement.  Whether you do this work at
> > compile time or link time, it still costs in terms of rebuild time.
> > And either way, you have to redo the work when the body changes.
> 
> Sure, but if the extra rebuild time isn't significant, who cares?

It's still significant today.  I won't be completely satisfied until my
rebuild time (after changing one or several files) is less than 0.2
second (because 0.2 second is unnoticeable at the human interaction
level).

I've used incremental Lisp and Smalltalk compilers that achieved such
compile-time efficiency years ago.  It's really nice (although there are
many things I don't like about those languages).

> > >...Certainly I wasn't the only one who thought that was
> > > the intent.
> >
> > But you're the only one who implemented it that way!
> 
> I certainly wasn't the only one to share generics by default.

I have no problem with sharing by default.  But I wonder if Ichbiah's
team had viewed that as the philosophy, why didn't they define the
semantics that way?  (Analogy with procedure calls: the RM does not
define them in terms of copying the called procedure to the call site,
and then expect pragma Not_Inline to turn that off!)

And why did they forbid recursive instantiations?

>... I'm pretty
> sure the old Rational compiler worked the same way. I'm the only one
> bull-headed enough to maintain that approach in the face of Ada 95, though.
> :-)
> 
> > >...Machines of the era weren't really powerful enough to implement
> > > that intent, thus the hacks of the generic dependency and the inline
> > > dependency were allowed.
> > >
> > > Of course, Ada 95 came along and changed that intent.
> >
> > I don't understand that.  Maybe I don't understand what you mean by
> > "that intent".  Which rules of Ada 95 are you talking about, here?
> 
> There are many rules of Ada 95 that make sharing impractical (not
> impossible, just impractical).

I've heard the same comment from some folks at Rational.
It surprised me at the time, because the design team really
tried to make generic body sharing *easier* in Ada 95.  Honest.

One thing that makes sharing hard (in Ada 83) is the semantics of
exceptions declared in generics.  Tucker pushed quite hard to change
that rule, but it was seen as too incompatible, so we gave up on that
idea.

But don't we get a little credit for tightening up the generic contract
model?  ;-)

>... For instance, there was no reason in Ada 83
> to make the size of generic formal types the same as the actual type. (Ada
> 95 requires that because of aliased objects.) Whereas, Ada 83 had just one
> (the previously mentioned parameter passing style), and there never has been
> a test written that could show the difference (such a test would be very
> dubious anyway).
> 
> > >... Which is too bad, as
> > > machines now are powerful enough to implement the Ada 83 intent!
> >
> > I don't understand that, either.  Are you saying that the run-time
> > overhead of the always-share model is now acceptable?
> 
> No, I was thinking of the time/space requirements for building such a
> compiler "properly". We didn't really implement my design because our hosts
> didn't have enough memory to store the intermediate code for the entire
> program, and a disk-based solution would be way too slow. It would be
> practical on modern machines (other than that I can't predict the
> performance of the optimization pass, which would be critical to making the
> scheme work. We'd have to build it to see).
> 
> Note that with the design that I had in mind, the run-time overhead of
> "always share" (as you put it) would be greatly reduced by partial
> evaluation and inlining optimizations -- done at link-time so that all of
> the instantiations and calls are known. Plus, pragma Inline could be used to
> reduce the overhead to nearly nil on critical stuff. The problem isn't the
> run-time overhead so much as it is supporting the optimizations necessary to
> mitigate it.

If you're doing that sort of inlining, I wouldn't call it "always share"
anymore.  I'd call it "sometimes share" or "partial sharing".  The whole
point would be to reduce or eliminate what I called "the run-time
overhead of the always-share model".

- Bob

Re: Possible Ada deficiency?

[Robert A Duff]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> danmcleran@hotmail.com wrote:
> 
> :  It would be nice to prevent future
> : developers from writing child packages if you don't want them to.
> 
> If you prevent programmers from extending software I can't see
> how that's nice. ;-)

The issue is not one of preventing anybody from doing anything.
The issue is *allowing* programmers to state their design intentions
(e.g. "the package has no children").  And if some future programmer
changes those intentions, they change the code to say so.

> If the software depends on things staying concealed, why not just
> write a short comment explaining this and possible consequences of
> misuse?

Because comments do not state the truth -- they state what the original
programmer *thought* was the truth, and even if that's true, they can
become false accidentally during maintenance.

- Bob

Re: Possible Ada deficiency?

[Robert A Duff]

Vinzent 'Gadget' Hoefler <nntp-2005-01@t-domaingrabbing.de> writes:

> you'd like to write
> 
> |   type Timer_Mode is
> |   atomic record
> |     [...]

I believe some syntax like that was proposed for Ada 9X,
and was later changed to pragmas.

I tend to agree with Dmitry: pragmas should not have a strong effect on
the high-level semantics (except it's OK for a pragma to *restrict* the
semantics).  But I have no problem with the fact that pragma Pack
affects the result of the 'Size attribute.  Nor do I have a problem with
pragmas that give optimization hints.

- Bob

Re: Possible Ada deficiency? (goto)

[Robert A Duff]

Peter Hermann <ica2ph@sinus.csv.ica.uni-stuttgart.de> writes:

> Robert A Duff <bobduff@shell01.theworld.com> wrote:
> > I don't much like the rules about goto labels.  They cause a lot of
> 
> I like them because they are useful.

And I don't like them because they are *not* useful.  ;-)

The main thing I'm thinking about is that goto labels are implicitly
declared.  The Pascal rule requires an explicit label declaration.
That makes the code more readable, because you can see up front
that "gotos lurk below", which is a useful thing to know.

Even if you think the extra syntactic overhead is annoying, it can't be
*very* annoying, because people don't write a lot of gotos.

Also, this rule makes the language a little bit harder to learn, because
goto labels don't behave like most everything else in the language,
which *do* have to be explicitly declared.

How many Ada programmers know that the following silly example is
illegal:

    procedure P is
    begin
        for Mumble in 1..10 loop
            <<Mumble>> -- Illegal!
            null;
        end loop;
    end P;

but the following equally silly example is legal:

    procedure P is
    begin
        <<Mumble>>
        for Mumble in 1..10 loop
            null;
        end loop;
    end P;

and can explain why?

Compiler writers have to work hard to get those little details exactly
right, and it's of zero benefit to programmers.

> > As a compiler writer, I find it very dissatisfying to do extra work that
> > doesn't benefit my user community.
> 
> As a bus driver, I find it very dissatisfying to have those 
> annoying passengers.

If my passengers bought tickets from New York to Boston, I don't like to
have a rule saying I have to drive the bus via Los Angeles!  ;-)

- Bob

Re: Possible Ada deficiency? (goto)

[Peter Hermann]

Robert A Duff <bobduff@shell01.theworld.com> wrote:
> The main thing I'm thinking about is that goto labels are implicitly
> declared.  The Pascal rule requires an explicit label declaration.
> That makes the code more readable, because you can see up front
> that "gotos lurk below", which is a useful thing to know.

maybe

> Even if you think the extra syntactic overhead is annoying, it can't be
> *very* annoying, because people don't write a lot of gotos.

yes. I was astonished after changing from Fortran to Ada
when I detected to never need any goto.
There are rare cases where a goto is useful.
(I am assuming you do not ban goto at all)
E.g. automatic translation from Fortran spaghetti into Ada.
The increase of workload of the translator is neglectable
(when translator=machine, annoying when man)
but the resulting code would be cluttered with label declarations,
which IMHO are of no added value.

> Also, this rule makes the language a little bit harder to learn, because

no

> goto labels don't behave like most everything else in the language,
> which *do* have to be explicitly declared.
> 
> How many Ada programmers know that the following silly example is
> illegal:
> 
>     procedure P is
>     begin
>         for Mumble in 1..10 loop

missing statement in loop

>             <<Mumble>> -- Illegal!
>             null;
>         end loop;
>     end P;
> 
> but the following equally silly example is legal:
> 
>     procedure P is
>     begin
>         <<Mumble>>

why not allow a practical "start over"?
Although my personal taste is to avoid goto_s
I welcome this syntactical feature for the comfort of the programer
in the sense of "let_it_be".

>         for Mumble in 1..10 loop
>             null;
>         end loop;
>     end P;
> 
> and can explain why?
> 
> Compiler writers have to work hard to get those little details exactly

once done, benefit thousandfold.

> right, and it's of zero benefit to programmers.

One of Ada's strengths is keeping mundane syntactical constructs alive
for the benefit(!) of programmer's comfort.
I like Ada for those many improvements concerning the taking over
of activities, now done by the compiler in place of the programmer.
Out of a long list of examples only a few examples:
  o   correct copying of overlapping vector slices
  o   atomic write of protected objects
  o   etc etc etc

Returning to my precious and almost never used goto :
It is carved in stone and I like it the way it is :-)
 
> If my passengers bought tickets from New York to Boston, I don't like to
> have a rule saying I have to drive the bus via Los Angeles!  ;-)
                    "I"   (-: not "they" :-)

anyway: thank you for the good laugh which brightens the day.

-- 
--Peter Hermann(49)0711-685-3611 fax3758 ica2ph@csv.ica.uni-stuttgart.de
--Pfaffenwaldring 27 Raum 114, D-70569 Stuttgart Uni Computeranwendungen
--http://www.csv.ica.uni-stuttgart.de/homes/ph/
--Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: Possible Ada deficiency?

[Dmitry A. Kazakov]

On Tue, 11 Jan 2005 13:57:13 +0000, Vinzent 'Gadget' Hoefler wrote:

> Dmitry A. Kazakov wrote:
> 
>> On Tue, 11 Jan 2005 07:24:10 +0000, Vinzent 'Gadget' Hoefler wrote:
>> 
>>> Dmitry A. Kazakov wrote:
>>> 
>>>> I would leave all optimization issues to the compiler.
>>> 
>>> Hmm. Then: What about pragma Volatile? pragma Atomic?
>> 
>> Atomic and volatile are not about optimization. They describe a
>> contract. It is wrong to use pragmas for them. Maybe in C++, which
>> does not deal with concurrency it would be appropriate, but definitely
>> not in Ada. It is clear why these pragmas appeared.
> 
> Atomic and/or Volatile are not necessarily about concurrency. Sometimes
> they are just about hardware.

...running parallel to CPU...

>> With full  ADT an "atomic Integer" will implement abstract protected
>> object. No need in any pragmas!
> 
> Hmm. So instead of
> 
>|   type Timer_Mode is
>|   record
>|      BCD : Count;
>|      CM  : Count_Mode;
>|      RWM : Read_Write_Mode;
>|      SC  : Counter_Select;
>|   end record;
>|   [aspect clauses]
>|   pragma Atomic (Timer_Mode);
> 
> you'd like to write
> 
>|   type Timer_Mode is
>|   atomic record
>|     [...]

Probably:

type Timer_Mode is
   new Ada.Atomic.Protected_Object with
record ...

(I don't like new keywords)
 
>>> Or all these interesting ones from Annexes D, E & H?
>> 
>> It depends on each concrete case.
> 
> Remote_Call_Interface? Interrupt_Priority? Attach_Handler?
> Inspection_Point?

Oh! (:-))

OK, Remote_Call_Interface could be moved to a pseudo-body. Priority could
be a parameter of a task constructor or a discriminant (a long story).
Attach_Handler should be a representation clause ("for ...").
Inspection_Point is OK to me.

---
Pragmas are supposed to be advises to the compiler, not to the program
reader. That means, if you remove all pragmas from the program it should
still have sense, same sense. This principle is violated too often, most
notoriously, by the pragmas appearing in the specifications. I'm afraid
pragmas might become a kind of Ada's preprocessor.

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

Re: Possible Ada deficiency?

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wcc4qhn4q26.fsf@shell01.TheWorld.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
> > Sure, but if the extra rebuild time isn't significant, who cares?
>
> It's still significant today.  I won't be completely satisfied until my
> rebuild time (after changing one or several files) is less than 0.2
> second (because 0.2 second is unnoticeable at the human interaction
> level).

OK, but I was talking about significant compared to the "normal" build time.
I don't think that sort of build time will ever be practical for Ada. My
goal is the next "step" up in human response, which is somwhere between
10-30 seconds. As long as the build is done before I finish taking a drink,
its quick enough. (You're going to pause anyway, 'cause you can't work
continuously for hours...).

> > I certainly wasn't the only one to share generics by default.
>
> I have no problem with sharing by default.  But I wonder if Ichbiah's
> team had viewed that as the philosophy, why didn't they define the
> semantics that way?  (Analogy with procedure calls: the RM does not
> define them in terms of copying the called procedure to the call site,
> and then expect pragma Not_Inline to turn that off!)

I don't know; I presume they were confused as to what they were defining
(that happens when it hasn't really been done before).

> And why did they forbid recursive instantiations?

Probably to allow alternate implementations; they were not sure which model
made sense, so they allowed them all.

...
> > There are many rules of Ada 95 that make sharing impractical (not
> > impossible, just impractical).
>
> I've heard the same comment from some folks at Rational.
> It surprised me at the time, because the design team really
> tried to make generic body sharing *easier* in Ada 95.  Honest.

Certainly, the effects of "aliased" were more in the "unintended
consequences" category.

> One thing that makes sharing hard (in Ada 83) is the semantics of
> exceptions declared in generics.  Tucker pushed quite hard to change
> that rule, but it was seen as too incompatible, so we gave up on that
> idea.
>
> But don't we get a little credit for tightening up the generic contract
> model?  ;-)

Sure. But "assume-the-best" means lots of additional stuff to pass to the
generic, and not all at the head. So it makes it harder than just having it
illegal as appeared to be the case in Ada 83.

> > > I don't understand that, either.  Are you saying that the run-time
> > > overhead of the always-share model is now acceptable?
> >
> > No, I was thinking of the time/space requirements for building such a
> > compiler "properly". We didn't really implement my design because our
hosts
> > didn't have enough memory to store the intermediate code for the entire
> > program, and a disk-based solution would be way too slow. It would be
> > practical on modern machines (other than that I can't predict the
> > performance of the optimization pass, which would be critical to making
the
> > scheme work. We'd have to build it to see).
> >
> > Note that with the design that I had in mind, the run-time overhead of
> > "always share" (as you put it) would be greatly reduced by partial
> > evaluation and inlining optimizations -- done at link-time so that all
of
> > the instantiations and calls are known. Plus, pragma Inline could be
used to
> > reduce the overhead to nearly nil on critical stuff. The problem isn't
the
> > run-time overhead so much as it is supporting the optimizations
necessary to
> > mitigate it.
>
> If you're doing that sort of inlining, I wouldn't call it "always share"
> anymore.  I'd call it "sometimes share" or "partial sharing".  The whole
> point would be to reduce or eliminate what I called "the run-time
> overhead of the always-share model".

I find that confused. Inlining and partial evaluation are optimizations,
applied after the semantics of the program is encoded. After all, automated
inlining and partial evaluation would be useful in many cases having nothing
to do with generics. OTOH, "always share" is a basic part of the semantics,
and it is the only thing that the front-end knows. The front-end never does
any inlining.

I suppose from the point of view of a user, the effect is essentially the
same. But from the point of view of the processor design, the optimizer and
the front-end know almost nothing about each other, and things that happen
in one have no bearing on what happens in the other. (In our case, that
distinction is quite strictly enforced. I've fixed the optimizer
independently of the front-end on many occassions, even giving customers the
fixed back-end to use with an older front-end.)

As I've said before, this is all in theory; we never built the link-time
optimizer, these days because of tiny little problems (like the fact that
our debugger format assumes one source file per generated code file; and
that intemediate code label numbers would have to resequenced; etc.). So
perhaps it wouldn't work well in practice.

                               Randy.

Re: Possible Ada deficiency? (goto)

[Robert A Duff]

Peter Hermann <ica2ph@sinus.csv.ica.uni-stuttgart.de> writes:

> Robert A Duff <bobduff@shell01.theworld.com> wrote:
> > The main thing I'm thinking about is that goto labels are implicitly
> > declared.  The Pascal rule requires an explicit label declaration.
> > That makes the code more readable, because you can see up front
> > that "gotos lurk below", which is a useful thing to know.
> 
> maybe
> 
> > Even if you think the extra syntactic overhead is annoying, it can't be
> > *very* annoying, because people don't write a lot of gotos.
> 
> yes. I was astonished after changing from Fortran to Ada
> when I detected to never need any goto.
> There are rare cases where a goto is useful.
> (I am assuming you do not ban goto at all)

True.

> E.g. automatic translation from Fortran spaghetti into Ada.
> The increase of workload of the translator is neglectable
> (when translator=machine, annoying when man)
> but the resulting code would be cluttered with label declarations,
> which IMHO are of no added value.

Well, if I were writing a Fortran-to-Ada translator, it would be smart
enough to generate nearly-goto-free Ada.  At least, if the Ada code is
intended to be read by humans.

> > Also, this rule makes the language a little bit harder to learn, because
> 
> no
> 
> > goto labels don't behave like most everything else in the language,
> > which *do* have to be explicitly declared.
> > 
> > How many Ada programmers know that the following silly example is
> > illegal:
> > 
> >     procedure P is
> >     begin
> >         for Mumble in 1..10 loop
> 
> missing statement in loop

No.  There's a null statement.

> >             <<Mumble>> -- Illegal!
> >             null;
> >         end loop;
> >     end P;

    procedure P is
        --(1)
    begin
        for Mumble in 1..10 loop
            <<Mumble>> --(2)
            null;
        end loop;
    end P;

Here's why the above is illegal:  There is an implicit declaration of
label Mumble at that place marked "--(1)".  At the place marked "--(2)",
this this declaration is not directly visible, because it is hidden by
the loop parameter Mumble.  Thus, the reference to Mumble at "--(2)"
is illegal.  That's just plain weird.

> > but the following equally silly example is legal:
> > 
> >     procedure P is
> >     begin
> >         <<Mumble>>
> 
> why not allow a practical "start over"?
> Although my personal taste is to avoid goto_s
> I welcome this syntactical feature for the comfort of the programer
> in the sense of "let_it_be".
> 
> >         for Mumble in 1..10 loop
> >             null;
> >         end loop;
> >     end P;
> > 
> > and can explain why?
> > 
> > Compiler writers have to work hard to get those little details exactly
> 
> once done, benefit thousandfold.

Thousand times zero = zero.

> > right, and it's of zero benefit to programmers.

> Returning to my precious and almost never used goto :
> It is carved in stone and I like it the way it is :-)

Yes, it's carved in stone.

> > If my passengers bought tickets from New York to Boston, I don't like to
> > have a rule saying I have to drive the bus via Los Angeles!  ;-)
>                     "I"   (-: not "they" :-)
> 
> anyway: thank you for the good laugh which brightens the day.

:-)

- Bob

Re: Possible Ada deficiency? (goto)

[Dmitry A. Kazakov]

On 15 Jan 2005 12:34:59 -0500, Robert A Duff wrote:

>     procedure P is
>         --(1)
>     begin
>         for Mumble in 1..10 loop
>             <<Mumble>> --(2)
>             null;
>         end loop;
>     end P;
> 
> Here's why the above is illegal:  There is an implicit declaration of
> label Mumble at that place marked "--(1)".

Why not in the loop's body? After all one cannot jump into the loop body?

> At the place marked "--(2)",
> this this declaration is not directly visible, because it is hidden by
> the loop parameter Mumble.  Thus, the reference to Mumble at "--(2)"
> is illegal.  That's just plain weird.

Interesting is that labels, types and objects share the same name space.
For labels it looks as if somebody planned to implement FORTRAN's:

ASSIGN 100 K
...
GOTO K

(I like that language! (:-))

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

Re: Possible Ada deficiency? (goto)

[Robert A Duff]

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

> On 15 Jan 2005 12:34:59 -0500, Robert A Duff wrote:
> 
> >     procedure P is
> >         --(1)
> >     begin
> >         for Mumble in 1..10 loop
> >             <<Mumble>> --(2)
> >             null;
> >         end loop;
> >     end P;
> > 
> > Here's why the above is illegal:  There is an implicit declaration of
> > label Mumble at that place marked "--(1)".
> 
> Why not in the loop's body? After all one cannot jump into the loop body?

I don't know.  Perhaps because the rules for goto labels are the same as
for block names, and maybe it makes expanded names work better.

> > At the place marked "--(2)",
> > this this declaration is not directly visible, because it is hidden by
> > the loop parameter Mumble.  Thus, the reference to Mumble at "--(2)"
> > is illegal.  That's just plain weird.
> 
> Interesting is that labels, types and objects share the same name space.

Seems like the simplest rule, for both programmer and compiler.

> For labels it looks as if somebody planned to implement FORTRAN's:
> 
> ASSIGN 100 K
> ...
> GOTO K
> 
> (I like that language! (:-))

;-)

- Bob

Re: Possible Ada deficiency?

[Tucker]

danmcleran@hotmail.com wrote:
> I would like to know if anyone else thinks that the inability to hide
> private information from child packages is a deficiency in Ada95. I
am
> discussing ways to do this on another thread, (See Private area and
> child packages), but it seems wrong that one has to go through a
bunch
> of machinations to do something like this. Wouldn't a language
> construct for this be advantageous?

We considered this during the Ada 95 design process.
Our conclusion was that C++ public/protected/private
was analogous to Ada's "visible part of pkg spec"/
"private part of pkg spec"/"body of pkg".
C++ doesn't really have the equivalent of a "body."
If you want to add a new function that is only usable
within a given class, you generally still have to declare
it in the ".h" (unless you play games with "friends"),
which is a royal pain IMHO.

If you really need to declare something in a package spec,
but you don't want it visible to children, one solution
is to declare it in a nested package.  The private part
of a nested package is not visible to children.

One consideration, however, is that trying to hide something
from all possible future children may be overengineering.
Some C++ coding styles encourage use of "protected" rather
than "private," since it is hard to foresee all of the kinds
of extensions that might be necessary in the future.  However,
in C++, "protected" is troublesome during maintenance, since
*all* derivatives of a type can see its protected components,
no matter where the type is declared.  And the type hierarchy
below a type may be very large, and spread all over the place.

On the other hand, Ada's approach to "partial" privacy forces
any package which needs visibility to be given a name which
essentially makes it part of the "subsystem" where the data
is defined.  Although there is nothing preventing someone
from creating their own child of someone else's subsystem,
when they do that, they generally accept the fact that they
may need to be prepared to do some work next time a new
revision of the subsystem is released.  On the other hand,
in C++, you are generally encouraged to get the advantages
of reuse by creating lots of derivatives of a type, and you
are probably less likely to think you are signing up for
a potential maintenance burden when a new version of the
base type is released.  I agree it is a subtle distinction,
but in my experience, it creates the right kind of subtle
incentive.  When someone creates a child of someone else's
subsystem, they do so to export a bit more information,
rather than dumping all of their own logic into the child.
So the net effect is that the amount of code that has visibility
is smaller, and so the ability to accommodate a change to the
parent package is better.

>
> In C++ and Java, no private data can be seen by child classes. I
think
> that Ada would benefit from extending its information hiding
> capabilities by allowing a package writer to conceal type information
> from child packages.
>
> What if Ada had a keyword, I've chosen 'concealed' for the sake of
> discussion, to indicate that the implementation of a type was not
> visible to the outside world (including child packages)...

Wrapping the type in a nested package can be used to
accomplish approximately what you need.

-Tucker Taft

Re: Possible Ada deficiency?

[danmcleran]

Thanks for the nested package suggestion. This seems to get me exactly
what I was wanting.

Re: Possible Ada deficiency?

[Nick Roberts]

danmcleran@hotmail.com wrote:

> Thanks for the nested package suggestion. This seems to get me exactly
> what I was wanting.

Tuck roolz :-)

-- 
Nick Roberts

Re: Possible Ada deficiency?

[danmcleran]

> Wrapping the type in a nested package can be used to
> accomplish approximately what you need.

What I wanted was a way to prevent child packages from messing with
certain areas of a parent package. Using Tucker's suggestion, I put my
type implementation into a nested package. I believe that this will
prevent any other component, including child packages, from messing
with Secret_Value directly. Here's what I've come up with:

package Some_Package is
package Some_Package_Implementation_Package is
type Some_Type is limited private;

procedure Set_Secret_Value (
Obj : in out Some_Type;
New_Value : in Integer);

function Get_Secret_Value (Obj : in Some_Type) return Integer;

private
type Some_Type is record
Secret_Value : Integer := Integer'First;
end record;
end Some_Package_Implementation_Package;

subtype Some_Type is Some_Package_Implementation_Package.Some_Type;

procedure Set_Secret_Value (
Obj : in out Some_Type;
New_Value : in Integer) renames
Some_Package_Implementation_Package.Set_Secret_Value;

function Get_Secret_Value (Obj : in Some_Type) return Integer
renames Some_Package_Implementation_Package.Get_Secret_Value;
end Some_Package;