* Possible Ada deficiency? @ 2004-12-31 18:15 danmcleran 2004-12-31 19:12 ` Jeffrey Carter ` (6 more replies) 0 siblings, 7 replies; 103+ messages in thread From: danmcleran @ 2004-12-31 18:15 UTC (permalink / raw) 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; ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2004-12-31 18:15 Possible Ada deficiency? danmcleran @ 2004-12-31 19:12 ` Jeffrey Carter 2005-01-01 1:52 ` danmcleran 2005-01-01 2:02 ` danmcleran 2004-12-31 19:16 ` Martin Dowie ` (5 subsequent siblings) 6 siblings, 2 replies; 103+ messages in thread From: Jeffrey Carter @ 2004-12-31 19:12 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2004-12-31 19:12 ` Jeffrey Carter @ 2005-01-01 1:52 ` danmcleran 2005-01-01 2:37 ` Jeffrey Carter 2005-01-01 2:02 ` danmcleran 1 sibling, 1 reply; 103+ messages in thread From: danmcleran @ 2005-01-01 1:52 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-01 1:52 ` danmcleran @ 2005-01-01 2:37 ` Jeffrey Carter 0 siblings, 0 replies; 103+ messages in thread From: Jeffrey Carter @ 2005-01-01 2:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2004-12-31 19:12 ` Jeffrey Carter 2005-01-01 1:52 ` danmcleran @ 2005-01-01 2:02 ` danmcleran 2005-01-01 14:11 ` Martin Krischik ` (2 more replies) 1 sibling, 3 replies; 103+ messages in thread From: danmcleran @ 2005-01-01 2:02 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-01 2:02 ` danmcleran @ 2005-01-01 14:11 ` Martin Krischik 2005-01-01 15:27 ` danmcleran 2005-01-01 15:30 ` Stephen Leake 2005-01-01 23:36 ` tmoran 2 siblings, 1 reply; 103+ messages in thread From: Martin Krischik @ 2005-01-01 14:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-01 14:11 ` Martin Krischik @ 2005-01-01 15:27 ` danmcleran 2005-01-02 17:49 ` Martin Krischik 0 siblings, 1 reply; 103+ messages in thread From: danmcleran @ 2005-01-01 15:27 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-01 15:27 ` danmcleran @ 2005-01-02 17:49 ` Martin Krischik 0 siblings, 0 replies; 103+ messages in thread From: Martin Krischik @ 2005-01-02 17:49 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-01 2:02 ` danmcleran 2005-01-01 14:11 ` Martin Krischik @ 2005-01-01 15:30 ` Stephen Leake 2005-01-01 15:57 ` danmcleran ` (2 more replies) 2005-01-01 23:36 ` tmoran 2 siblings, 3 replies; 103+ messages in thread From: Stephen Leake @ 2005-01-01 15:30 UTC (permalink / raw) To: comp.lang.ada 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-01 15:30 ` Stephen Leake @ 2005-01-01 15:57 ` danmcleran 2005-01-03 23:37 ` Randy Brukardt 2005-01-02 15:51 ` Adrian Hoe 2005-01-04 16:06 ` Peter Hermann 2 siblings, 1 reply; 103+ messages in thread From: danmcleran @ 2005-01-01 15:57 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-01 15:57 ` danmcleran @ 2005-01-03 23:37 ` Randy Brukardt 2005-01-07 17:26 ` Nick Roberts 0 siblings, 1 reply; 103+ messages in thread From: Randy Brukardt @ 2005-01-03 23:37 UTC (permalink / raw) <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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-03 23:37 ` Randy Brukardt @ 2005-01-07 17:26 ` Nick Roberts 2005-01-07 18:26 ` danmcleran 2005-01-07 21:32 ` Randy Brukardt 0 siblings, 2 replies; 103+ messages in thread From: Nick Roberts @ 2005-01-07 17:26 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-07 17:26 ` Nick Roberts @ 2005-01-07 18:26 ` danmcleran 2005-01-07 21:32 ` Randy Brukardt 1 sibling, 0 replies; 103+ messages in thread From: danmcleran @ 2005-01-07 18:26 UTC (permalink / raw) >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; ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-07 17:26 ` Nick Roberts 2005-01-07 18:26 ` danmcleran @ 2005-01-07 21:32 ` Randy Brukardt 2005-01-08 3:56 ` Nick Roberts 1 sibling, 1 reply; 103+ messages in thread From: Randy Brukardt @ 2005-01-07 21:32 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-07 21:32 ` Randy Brukardt @ 2005-01-08 3:56 ` Nick Roberts 2005-01-08 18:15 ` Robert A Duff 0 siblings, 1 reply; 103+ messages in thread From: Nick Roberts @ 2005-01-08 3:56 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-08 3:56 ` Nick Roberts @ 2005-01-08 18:15 ` Robert A Duff 2005-01-08 19:11 ` Jeffrey Carter ` (3 more replies) 0 siblings, 4 replies; 103+ messages in thread From: Robert A Duff @ 2005-01-08 18:15 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-08 18:15 ` Robert A Duff @ 2005-01-08 19:11 ` Jeffrey Carter 2005-01-08 20:03 ` Robert A Duff 2005-01-09 17:23 ` danmcleran ` (2 subsequent siblings) 3 siblings, 1 reply; 103+ messages in thread From: Jeffrey Carter @ 2005-01-08 19:11 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-08 19:11 ` Jeffrey Carter @ 2005-01-08 20:03 ` Robert A Duff 2005-01-09 3:40 ` Jeffrey Carter 0 siblings, 1 reply; 103+ messages in thread From: Robert A Duff @ 2005-01-08 20:03 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-08 20:03 ` Robert A Duff @ 2005-01-09 3:40 ` Jeffrey Carter 2005-01-09 17:30 ` Robert A Duff 0 siblings, 1 reply; 103+ messages in thread From: Jeffrey Carter @ 2005-01-09 3:40 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-09 3:40 ` Jeffrey Carter @ 2005-01-09 17:30 ` Robert A Duff 2005-01-09 19:24 ` Jeffrey Carter 2005-01-09 21:56 ` Nick Roberts 0 siblings, 2 replies; 103+ messages in thread From: Robert A Duff @ 2005-01-09 17:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-09 17:30 ` Robert A Duff @ 2005-01-09 19:24 ` Jeffrey Carter 2005-01-09 21:56 ` Nick Roberts 1 sibling, 0 replies; 103+ messages in thread From: Jeffrey Carter @ 2005-01-09 19:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-09 17:30 ` Robert A Duff 2005-01-09 19:24 ` Jeffrey Carter @ 2005-01-09 21:56 ` Nick Roberts 2005-01-10 13:47 ` Dmitry A. Kazakov 1 sibling, 1 reply; 103+ messages in thread From: Nick Roberts @ 2005-01-09 21:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-09 21:56 ` Nick Roberts @ 2005-01-10 13:47 ` Dmitry A. Kazakov 2005-01-10 16:46 ` Duncan Sands 0 siblings, 1 reply; 103+ messages in thread From: Dmitry A. Kazakov @ 2005-01-10 13:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-10 13:47 ` Dmitry A. Kazakov @ 2005-01-10 16:46 ` Duncan Sands 2005-01-10 17:58 ` Pascal Obry 0 siblings, 1 reply; 103+ messages in thread From: Duncan Sands @ 2005-01-10 16:46 UTC (permalink / raw) To: comp.lang.ada, mailbox > 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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-10 16:46 ` Duncan Sands @ 2005-01-10 17:58 ` Pascal Obry 2005-01-10 18:45 ` Dmitry A. Kazakov 0 siblings, 1 reply; 103+ messages in thread From: Pascal Obry @ 2005-01-10 17:58 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-10 17:58 ` Pascal Obry @ 2005-01-10 18:45 ` Dmitry A. Kazakov 2005-01-10 19:44 ` Pascal Obry 2005-01-11 7:24 ` Vinzent 'Gadget' Hoefler 0 siblings, 2 replies; 103+ messages in thread From: Dmitry A. Kazakov @ 2005-01-10 18:45 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-10 18:45 ` Dmitry A. Kazakov @ 2005-01-10 19:44 ` Pascal Obry 2005-01-11 10:05 ` Dmitry A. Kazakov 2005-01-11 7:24 ` Vinzent 'Gadget' Hoefler 1 sibling, 1 reply; 103+ messages in thread From: Pascal Obry @ 2005-01-10 19:44 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-10 19:44 ` Pascal Obry @ 2005-01-11 10:05 ` Dmitry A. Kazakov 0 siblings, 0 replies; 103+ messages in thread From: Dmitry A. Kazakov @ 2005-01-11 10:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-10 18:45 ` Dmitry A. Kazakov 2005-01-10 19:44 ` Pascal Obry @ 2005-01-11 7:24 ` Vinzent 'Gadget' Hoefler 2005-01-11 9:48 ` Dmitry A. Kazakov 1 sibling, 1 reply; 103+ messages in thread From: Vinzent 'Gadget' Hoefler @ 2005-01-11 7:24 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-11 7:24 ` Vinzent 'Gadget' Hoefler @ 2005-01-11 9:48 ` Dmitry A. Kazakov 2005-01-11 13:57 ` Vinzent 'Gadget' Hoefler 0 siblings, 1 reply; 103+ messages in thread From: Dmitry A. Kazakov @ 2005-01-11 9:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-11 9:48 ` Dmitry A. Kazakov @ 2005-01-11 13:57 ` Vinzent 'Gadget' Hoefler 2005-01-11 21:52 ` Robert A Duff 2005-01-12 11:22 ` Dmitry A. Kazakov 0 siblings, 2 replies; 103+ messages in thread From: Vinzent 'Gadget' Hoefler @ 2005-01-11 13:57 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-11 13:57 ` Vinzent 'Gadget' Hoefler @ 2005-01-11 21:52 ` Robert A Duff 2005-01-12 11:22 ` Dmitry A. Kazakov 1 sibling, 0 replies; 103+ messages in thread From: Robert A Duff @ 2005-01-11 21:52 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-11 13:57 ` Vinzent 'Gadget' Hoefler 2005-01-11 21:52 ` Robert A Duff @ 2005-01-12 11:22 ` Dmitry A. Kazakov 1 sibling, 0 replies; 103+ messages in thread From: Dmitry A. Kazakov @ 2005-01-12 11:22 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-08 18:15 ` Robert A Duff 2005-01-08 19:11 ` Jeffrey Carter @ 2005-01-09 17:23 ` danmcleran 2005-01-09 17:46 ` Robert A Duff 2005-01-09 18:41 ` Nick Roberts 2005-01-10 20:15 ` Possible Ada deficiency? Randy Brukardt 3 siblings, 1 reply; 103+ messages in thread From: danmcleran @ 2005-01-09 17:23 UTC (permalink / raw) >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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-09 17:23 ` danmcleran @ 2005-01-09 17:46 ` Robert A Duff 2005-01-10 3:05 ` danmcleran 0 siblings, 1 reply; 103+ messages in thread From: Robert A Duff @ 2005-01-09 17:46 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-09 17:46 ` Robert A Duff @ 2005-01-10 3:05 ` danmcleran 0 siblings, 0 replies; 103+ messages in thread From: danmcleran @ 2005-01-10 3:05 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-08 18:15 ` Robert A Duff 2005-01-08 19:11 ` Jeffrey Carter 2005-01-09 17:23 ` danmcleran @ 2005-01-09 18:41 ` Nick Roberts 2005-01-09 19:06 ` Martin Krischik ` (2 more replies) 2005-01-10 20:15 ` Possible Ada deficiency? Randy Brukardt 3 siblings, 3 replies; 103+ messages in thread From: Nick Roberts @ 2005-01-09 18:41 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-09 18:41 ` Nick Roberts @ 2005-01-09 19:06 ` Martin Krischik 2005-01-09 20:10 ` Robert A Duff 2005-01-09 20:15 ` Robert A Duff 2 siblings, 0 replies; 103+ messages in thread From: Martin Krischik @ 2005-01-09 19:06 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-09 18:41 ` Nick Roberts 2005-01-09 19:06 ` Martin Krischik @ 2005-01-09 20:10 ` Robert A Duff 2005-01-09 20:15 ` Robert A Duff 2 siblings, 0 replies; 103+ messages in thread From: Robert A Duff @ 2005-01-09 20:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-09 18:41 ` Nick Roberts 2005-01-09 19:06 ` Martin Krischik 2005-01-09 20:10 ` Robert A Duff @ 2005-01-09 20:15 ` Robert A Duff 2005-01-11 14:13 ` Possible Ada deficiency? (goto) Peter Hermann 2 siblings, 1 reply; 103+ messages in thread From: Robert A Duff @ 2005-01-09 20:15 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? (goto) 2005-01-09 20:15 ` Robert A Duff @ 2005-01-11 14:13 ` Peter Hermann 2005-01-11 14:54 ` Nick Roberts 2005-01-11 22:15 ` Robert A Duff 0 siblings, 2 replies; 103+ messages in thread From: Peter Hermann @ 2005-01-11 14:13 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? (goto) 2005-01-11 14:13 ` Possible Ada deficiency? (goto) Peter Hermann @ 2005-01-11 14:54 ` Nick Roberts 2005-01-11 22:15 ` Robert A Duff 1 sibling, 0 replies; 103+ messages in thread From: Nick Roberts @ 2005-01-11 14:54 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? (goto) 2005-01-11 14:13 ` Possible Ada deficiency? (goto) Peter Hermann 2005-01-11 14:54 ` Nick Roberts @ 2005-01-11 22:15 ` Robert A Duff 2005-01-12 10:17 ` Peter Hermann 1 sibling, 1 reply; 103+ messages in thread From: Robert A Duff @ 2005-01-11 22:15 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? (goto) 2005-01-11 22:15 ` Robert A Duff @ 2005-01-12 10:17 ` Peter Hermann 2005-01-15 17:34 ` Robert A Duff 0 siblings, 1 reply; 103+ messages in thread From: Peter Hermann @ 2005-01-12 10:17 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? (goto) 2005-01-12 10:17 ` Peter Hermann @ 2005-01-15 17:34 ` Robert A Duff 2005-01-15 17:58 ` Dmitry A. Kazakov 0 siblings, 1 reply; 103+ messages in thread From: Robert A Duff @ 2005-01-15 17:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? (goto) 2005-01-15 17:34 ` Robert A Duff @ 2005-01-15 17:58 ` Dmitry A. Kazakov 2005-01-15 19:34 ` Robert A Duff 0 siblings, 1 reply; 103+ messages in thread From: Dmitry A. Kazakov @ 2005-01-15 17:58 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? (goto) 2005-01-15 17:58 ` Dmitry A. Kazakov @ 2005-01-15 19:34 ` Robert A Duff 0 siblings, 0 replies; 103+ messages in thread From: Robert A Duff @ 2005-01-15 19:34 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-08 18:15 ` Robert A Duff ` (2 preceding siblings ...) 2005-01-09 18:41 ` Nick Roberts @ 2005-01-10 20:15 ` Randy Brukardt 2005-01-10 21:51 ` Robert A Duff 3 siblings, 1 reply; 103+ messages in thread From: Randy Brukardt @ 2005-01-10 20:15 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-10 20:15 ` Possible Ada deficiency? Randy Brukardt @ 2005-01-10 21:51 ` Robert A Duff 2005-01-11 20:23 ` Randy Brukardt 0 siblings, 1 reply; 103+ messages in thread From: Robert A Duff @ 2005-01-10 21:51 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-10 21:51 ` Robert A Duff @ 2005-01-11 20:23 ` Randy Brukardt 2005-01-11 21:24 ` Robert A Duff 0 siblings, 1 reply; 103+ messages in thread From: Randy Brukardt @ 2005-01-11 20:23 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-11 20:23 ` Randy Brukardt @ 2005-01-11 21:24 ` Robert A Duff 2005-01-12 19:57 ` Randy Brukardt 0 siblings, 1 reply; 103+ messages in thread From: Robert A Duff @ 2005-01-11 21:24 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-11 21:24 ` Robert A Duff @ 2005-01-12 19:57 ` Randy Brukardt 0 siblings, 0 replies; 103+ messages in thread From: Randy Brukardt @ 2005-01-12 19:57 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-01 15:30 ` Stephen Leake 2005-01-01 15:57 ` danmcleran @ 2005-01-02 15:51 ` Adrian Hoe 2005-01-04 16:06 ` Peter Hermann 2 siblings, 0 replies; 103+ messages in thread From: Adrian Hoe @ 2005-01-02 15:51 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-01 15:30 ` Stephen Leake 2005-01-01 15:57 ` danmcleran 2005-01-02 15:51 ` Adrian Hoe @ 2005-01-04 16:06 ` Peter Hermann 2 siblings, 0 replies; 103+ messages in thread From: Peter Hermann @ 2005-01-04 16:06 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-01 2:02 ` danmcleran 2005-01-01 14:11 ` Martin Krischik 2005-01-01 15:30 ` Stephen Leake @ 2005-01-01 23:36 ` tmoran 2005-01-02 3:38 ` danmcleran 2 siblings, 1 reply; 103+ messages in thread From: tmoran @ 2005-01-01 23:36 UTC (permalink / raw) >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." ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-01 23:36 ` tmoran @ 2005-01-02 3:38 ` danmcleran 0 siblings, 0 replies; 103+ messages in thread From: danmcleran @ 2005-01-02 3:38 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2004-12-31 18:15 Possible Ada deficiency? danmcleran 2004-12-31 19:12 ` Jeffrey Carter @ 2004-12-31 19:16 ` Martin Dowie 2005-01-01 2:32 ` Jeffrey Carter 2004-12-31 23:23 ` Nick Roberts ` (4 subsequent siblings) 6 siblings, 1 reply; 103+ messages in thread From: Martin Dowie @ 2004-12-31 19:16 UTC (permalink / raw) 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; ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2004-12-31 19:16 ` Martin Dowie @ 2005-01-01 2:32 ` Jeffrey Carter 0 siblings, 0 replies; 103+ messages in thread From: Jeffrey Carter @ 2005-01-01 2:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2004-12-31 18:15 Possible Ada deficiency? danmcleran 2004-12-31 19:12 ` Jeffrey Carter 2004-12-31 19:16 ` Martin Dowie @ 2004-12-31 23:23 ` Nick Roberts 2005-01-01 1:56 ` danmcleran 2005-01-01 11:43 ` Dmitry A. Kazakov ` (3 subsequent siblings) 6 siblings, 1 reply; 103+ messages in thread From: Nick Roberts @ 2004-12-31 23:23 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2004-12-31 23:23 ` Nick Roberts @ 2005-01-01 1:56 ` danmcleran 0 siblings, 0 replies; 103+ messages in thread From: danmcleran @ 2005-01-01 1:56 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2004-12-31 18:15 Possible Ada deficiency? danmcleran ` (2 preceding siblings ...) 2004-12-31 23:23 ` Nick Roberts @ 2005-01-01 11:43 ` Dmitry A. Kazakov 2005-01-01 15:46 ` danmcleran 2005-01-01 23:28 ` danmcleran 2005-01-01 14:06 ` Martin Krischik ` (2 subsequent siblings) 6 siblings, 2 replies; 103+ messages in thread From: Dmitry A. Kazakov @ 2005-01-01 11:43 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-01 11:43 ` Dmitry A. Kazakov @ 2005-01-01 15:46 ` danmcleran 2005-01-01 17:58 ` Larry Kilgallen 2005-01-01 23:28 ` danmcleran 1 sibling, 1 reply; 103+ messages in thread From: danmcleran @ 2005-01-01 15:46 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-01 15:46 ` danmcleran @ 2005-01-01 17:58 ` Larry Kilgallen 2005-01-01 19:43 ` danmcleran 0 siblings, 1 reply; 103+ messages in thread From: Larry Kilgallen @ 2005-01-01 17:58 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-01 17:58 ` Larry Kilgallen @ 2005-01-01 19:43 ` danmcleran 2005-01-02 0:36 ` Ed Falis 0 siblings, 1 reply; 103+ messages in thread From: danmcleran @ 2005-01-01 19:43 UTC (permalink / raw) 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; ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-01 19:43 ` danmcleran @ 2005-01-02 0:36 ` Ed Falis 2005-01-02 3:36 ` danmcleran 0 siblings, 1 reply; 103+ messages in thread From: Ed Falis @ 2005-01-02 0:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-02 0:36 ` Ed Falis @ 2005-01-02 3:36 ` danmcleran 2005-01-02 15:53 ` Ed Falis 0 siblings, 1 reply; 103+ messages in thread From: danmcleran @ 2005-01-02 3:36 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-02 3:36 ` danmcleran @ 2005-01-02 15:53 ` Ed Falis 2005-01-07 18:31 ` danmcleran 0 siblings, 1 reply; 103+ messages in thread From: Ed Falis @ 2005-01-02 15:53 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-02 15:53 ` Ed Falis @ 2005-01-07 18:31 ` danmcleran 2005-01-07 18:44 ` Pascal Obry 0 siblings, 1 reply; 103+ messages in thread From: danmcleran @ 2005-01-07 18:31 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-07 18:31 ` danmcleran @ 2005-01-07 18:44 ` Pascal Obry 2005-01-07 19:29 ` danmcleran 0 siblings, 1 reply; 103+ messages in thread From: Pascal Obry @ 2005-01-07 18:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-07 18:44 ` Pascal Obry @ 2005-01-07 19:29 ` danmcleran 2005-01-07 21:28 ` Pascal Obry 0 siblings, 1 reply; 103+ messages in thread From: danmcleran @ 2005-01-07 19:29 UTC (permalink / raw) Ooops! I meant it is illegal to compile a child package of Ada. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-07 19:29 ` danmcleran @ 2005-01-07 21:28 ` Pascal Obry 0 siblings, 0 replies; 103+ messages in thread From: Pascal Obry @ 2005-01-07 21:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-01 11:43 ` Dmitry A. Kazakov 2005-01-01 15:46 ` danmcleran @ 2005-01-01 23:28 ` danmcleran 2005-01-02 10:26 ` Dmitry A. Kazakov 2005-01-03 23:48 ` Randy Brukardt 1 sibling, 2 replies; 103+ messages in thread From: danmcleran @ 2005-01-01 23:28 UTC (permalink / raw) 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; ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-01 23:28 ` danmcleran @ 2005-01-02 10:26 ` Dmitry A. Kazakov 2005-01-02 15:51 ` danmcleran 2005-01-03 23:48 ` Randy Brukardt 1 sibling, 1 reply; 103+ messages in thread From: Dmitry A. Kazakov @ 2005-01-02 10:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-02 10:26 ` Dmitry A. Kazakov @ 2005-01-02 15:51 ` danmcleran 0 siblings, 0 replies; 103+ messages in thread From: danmcleran @ 2005-01-02 15:51 UTC (permalink / raw) > * 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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-01 23:28 ` danmcleran 2005-01-02 10:26 ` Dmitry A. Kazakov @ 2005-01-03 23:48 ` Randy Brukardt 1 sibling, 0 replies; 103+ messages in thread From: Randy Brukardt @ 2005-01-03 23:48 UTC (permalink / raw) <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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2004-12-31 18:15 Possible Ada deficiency? danmcleran ` (3 preceding siblings ...) 2005-01-01 11:43 ` Dmitry A. Kazakov @ 2005-01-01 14:06 ` Martin Krischik 2005-01-01 15:53 ` danmcleran 2005-01-07 21:33 ` Robert A Duff 2005-01-17 4:40 ` Tucker 6 siblings, 1 reply; 103+ messages in thread From: Martin Krischik @ 2005-01-01 14:06 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-01 14:06 ` Martin Krischik @ 2005-01-01 15:53 ` danmcleran 0 siblings, 0 replies; 103+ messages in thread From: danmcleran @ 2005-01-01 15:53 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2004-12-31 18:15 Possible Ada deficiency? danmcleran ` (4 preceding siblings ...) 2005-01-01 14:06 ` Martin Krischik @ 2005-01-07 21:33 ` Robert A Duff 2005-01-09 17:15 ` danmcleran 2005-01-17 4:40 ` Tucker 6 siblings, 1 reply; 103+ messages in thread From: Robert A Duff @ 2005-01-07 21:33 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-07 21:33 ` Robert A Duff @ 2005-01-09 17:15 ` danmcleran 2005-01-09 17:38 ` Robert A Duff ` (2 more replies) 0 siblings, 3 replies; 103+ messages in thread From: danmcleran @ 2005-01-09 17:15 UTC (permalink / raw) >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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-09 17:15 ` danmcleran @ 2005-01-09 17:38 ` Robert A Duff 2005-01-10 3:16 ` danmcleran 2005-01-09 18:41 ` Martin Dowie 2005-01-09 19:01 ` Jeffrey Carter 2 siblings, 1 reply; 103+ messages in thread From: Robert A Duff @ 2005-01-09 17:38 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-09 17:38 ` Robert A Duff @ 2005-01-10 3:16 ` danmcleran 0 siblings, 0 replies; 103+ messages in thread From: danmcleran @ 2005-01-10 3:16 UTC (permalink / raw) >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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-09 17:15 ` danmcleran 2005-01-09 17:38 ` Robert A Duff @ 2005-01-09 18:41 ` Martin Dowie 2005-01-10 3:18 ` danmcleran 2005-01-09 19:01 ` Jeffrey Carter 2 siblings, 1 reply; 103+ messages in thread From: Martin Dowie @ 2005-01-09 18:41 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-09 18:41 ` Martin Dowie @ 2005-01-10 3:18 ` danmcleran 2005-01-10 20:32 ` Randy Brukardt 2005-01-10 21:36 ` Robert A Duff 0 siblings, 2 replies; 103+ messages in thread From: danmcleran @ 2005-01-10 3:18 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-10 3:18 ` danmcleran @ 2005-01-10 20:32 ` Randy Brukardt 2005-01-10 21:42 ` danmcleran 2005-01-10 21:36 ` Robert A Duff 1 sibling, 1 reply; 103+ messages in thread From: Randy Brukardt @ 2005-01-10 20:32 UTC (permalink / raw) <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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-10 20:32 ` Randy Brukardt @ 2005-01-10 21:42 ` danmcleran 0 siblings, 0 replies; 103+ messages in thread From: danmcleran @ 2005-01-10 21:42 UTC (permalink / raw) >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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-10 3:18 ` danmcleran 2005-01-10 20:32 ` Randy Brukardt @ 2005-01-10 21:36 ` Robert A Duff 2005-01-10 21:44 ` danmcleran 1 sibling, 1 reply; 103+ messages in thread From: Robert A Duff @ 2005-01-10 21:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-10 21:36 ` Robert A Duff @ 2005-01-10 21:44 ` danmcleran 0 siblings, 0 replies; 103+ messages in thread From: danmcleran @ 2005-01-10 21:44 UTC (permalink / raw) >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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-09 17:15 ` danmcleran 2005-01-09 17:38 ` Robert A Duff 2005-01-09 18:41 ` Martin Dowie @ 2005-01-09 19:01 ` Jeffrey Carter 2005-01-10 3:20 ` danmcleran 2 siblings, 1 reply; 103+ messages in thread From: Jeffrey Carter @ 2005-01-09 19:01 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-09 19:01 ` Jeffrey Carter @ 2005-01-10 3:20 ` danmcleran 2005-01-10 22:16 ` Robert A Duff 0 siblings, 1 reply; 103+ messages in thread From: danmcleran @ 2005-01-10 3:20 UTC (permalink / raw) Well, then why not make everything public and forget the whole idea of encapsulation altogether? ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-10 3:20 ` danmcleran @ 2005-01-10 22:16 ` Robert A Duff 2005-01-10 22:29 ` danmcleran ` (2 more replies) 0 siblings, 3 replies; 103+ messages in thread From: Robert A Duff @ 2005-01-10 22:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-10 22:16 ` Robert A Duff @ 2005-01-10 22:29 ` danmcleran 2005-01-11 20:12 ` Georg Bauhaus 2005-01-11 0:06 ` Jeffrey Carter 2005-01-11 20:37 ` danmcleran 2 siblings, 1 reply; 103+ messages in thread From: danmcleran @ 2005-01-10 22:29 UTC (permalink / raw) >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'. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-10 22:29 ` danmcleran @ 2005-01-11 20:12 ` Georg Bauhaus 2005-01-11 20:30 ` danmcleran 2005-01-11 21:44 ` Robert A Duff 0 siblings, 2 replies; 103+ messages in thread From: Georg Bauhaus @ 2005-01-11 20:12 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-11 20:12 ` Georg Bauhaus @ 2005-01-11 20:30 ` danmcleran 2005-01-11 21:44 ` Robert A Duff 1 sibling, 0 replies; 103+ messages in thread From: danmcleran @ 2005-01-11 20:30 UTC (permalink / raw) >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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-11 20:12 ` Georg Bauhaus 2005-01-11 20:30 ` danmcleran @ 2005-01-11 21:44 ` Robert A Duff 1 sibling, 0 replies; 103+ messages in thread From: Robert A Duff @ 2005-01-11 21:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-10 22:16 ` Robert A Duff 2005-01-10 22:29 ` danmcleran @ 2005-01-11 0:06 ` Jeffrey Carter 2005-01-11 0:46 ` Robert A Duff 2005-01-11 20:37 ` danmcleran 2 siblings, 1 reply; 103+ messages in thread From: Jeffrey Carter @ 2005-01-11 0:06 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-11 0:06 ` Jeffrey Carter @ 2005-01-11 0:46 ` Robert A Duff 0 siblings, 0 replies; 103+ messages in thread From: Robert A Duff @ 2005-01-11 0:46 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-10 22:16 ` Robert A Duff 2005-01-10 22:29 ` danmcleran 2005-01-11 0:06 ` Jeffrey Carter @ 2005-01-11 20:37 ` danmcleran 2005-01-11 21:08 ` Robert A Duff 2 siblings, 1 reply; 103+ messages in thread From: danmcleran @ 2005-01-11 20:37 UTC (permalink / raw) >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. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-11 20:37 ` danmcleran @ 2005-01-11 21:08 ` Robert A Duff 0 siblings, 0 replies; 103+ messages in thread From: Robert A Duff @ 2005-01-11 21:08 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2004-12-31 18:15 Possible Ada deficiency? danmcleran ` (5 preceding siblings ...) 2005-01-07 21:33 ` Robert A Duff @ 2005-01-17 4:40 ` Tucker 2005-01-18 13:46 ` danmcleran 2005-01-24 17:23 ` danmcleran 6 siblings, 2 replies; 103+ messages in thread From: Tucker @ 2005-01-17 4:40 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-17 4:40 ` Tucker @ 2005-01-18 13:46 ` danmcleran 2005-01-18 21:29 ` Nick Roberts 2005-01-24 17:23 ` danmcleran 1 sibling, 1 reply; 103+ messages in thread From: danmcleran @ 2005-01-18 13:46 UTC (permalink / raw) Thanks for the nested package suggestion. This seems to get me exactly what I was wanting. ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-18 13:46 ` danmcleran @ 2005-01-18 21:29 ` Nick Roberts 0 siblings, 0 replies; 103+ messages in thread From: Nick Roberts @ 2005-01-18 21:29 UTC (permalink / raw) danmcleran@hotmail.com wrote: > Thanks for the nested package suggestion. This seems to get me exactly > what I was wanting. Tuck roolz :-) -- Nick Roberts ^ permalink raw reply [flat|nested] 103+ messages in thread
* Re: Possible Ada deficiency? 2005-01-17 4:40 ` Tucker 2005-01-18 13:46 ` danmcleran @ 2005-01-24 17:23 ` danmcleran 1 sibling, 0 replies; 103+ messages in thread From: danmcleran @ 2005-01-24 17:23 UTC (permalink / raw) > 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; ^ permalink raw reply [flat|nested] 103+ messages in thread
* Possible Ada deficiency? @ 2004-12-31 19:06 danmcleran 0 siblings, 0 replies; 103+ messages in thread From: danmcleran @ 2004-12-31 19:06 UTC (permalink / raw) 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; ^ permalink raw reply [flat|nested] 103+ messages in thread
end of thread, other threads:[~2005-01-24 17:23 UTC | newest] Thread overview: 103+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-12-31 18:15 Possible Ada deficiency? danmcleran 2004-12-31 19:12 ` Jeffrey Carter 2005-01-01 1:52 ` danmcleran 2005-01-01 2:37 ` Jeffrey Carter 2005-01-01 2:02 ` danmcleran 2005-01-01 14:11 ` Martin Krischik 2005-01-01 15:27 ` danmcleran 2005-01-02 17:49 ` Martin Krischik 2005-01-01 15:30 ` Stephen Leake 2005-01-01 15:57 ` danmcleran 2005-01-03 23:37 ` Randy Brukardt 2005-01-07 17:26 ` Nick Roberts 2005-01-07 18:26 ` danmcleran 2005-01-07 21:32 ` Randy Brukardt 2005-01-08 3:56 ` Nick Roberts 2005-01-08 18:15 ` Robert A Duff 2005-01-08 19:11 ` Jeffrey Carter 2005-01-08 20:03 ` Robert A Duff 2005-01-09 3:40 ` Jeffrey Carter 2005-01-09 17:30 ` Robert A Duff 2005-01-09 19:24 ` Jeffrey Carter 2005-01-09 21:56 ` Nick Roberts 2005-01-10 13:47 ` Dmitry A. Kazakov 2005-01-10 16:46 ` Duncan Sands 2005-01-10 17:58 ` Pascal Obry 2005-01-10 18:45 ` Dmitry A. Kazakov 2005-01-10 19:44 ` Pascal Obry 2005-01-11 10:05 ` Dmitry A. Kazakov 2005-01-11 7:24 ` Vinzent 'Gadget' Hoefler 2005-01-11 9:48 ` Dmitry A. Kazakov 2005-01-11 13:57 ` Vinzent 'Gadget' Hoefler 2005-01-11 21:52 ` Robert A Duff 2005-01-12 11:22 ` Dmitry A. Kazakov 2005-01-09 17:23 ` danmcleran 2005-01-09 17:46 ` Robert A Duff 2005-01-10 3:05 ` danmcleran 2005-01-09 18:41 ` Nick Roberts 2005-01-09 19:06 ` Martin Krischik 2005-01-09 20:10 ` Robert A Duff 2005-01-09 20:15 ` Robert A Duff 2005-01-11 14:13 ` Possible Ada deficiency? (goto) Peter Hermann 2005-01-11 14:54 ` Nick Roberts 2005-01-11 22:15 ` Robert A Duff 2005-01-12 10:17 ` Peter Hermann 2005-01-15 17:34 ` Robert A Duff 2005-01-15 17:58 ` Dmitry A. Kazakov 2005-01-15 19:34 ` Robert A Duff 2005-01-10 20:15 ` Possible Ada deficiency? Randy Brukardt 2005-01-10 21:51 ` Robert A Duff 2005-01-11 20:23 ` Randy Brukardt 2005-01-11 21:24 ` Robert A Duff 2005-01-12 19:57 ` Randy Brukardt 2005-01-02 15:51 ` Adrian Hoe 2005-01-04 16:06 ` Peter Hermann 2005-01-01 23:36 ` tmoran 2005-01-02 3:38 ` danmcleran 2004-12-31 19:16 ` Martin Dowie 2005-01-01 2:32 ` Jeffrey Carter 2004-12-31 23:23 ` Nick Roberts 2005-01-01 1:56 ` danmcleran 2005-01-01 11:43 ` Dmitry A. Kazakov 2005-01-01 15:46 ` danmcleran 2005-01-01 17:58 ` Larry Kilgallen 2005-01-01 19:43 ` danmcleran 2005-01-02 0:36 ` Ed Falis 2005-01-02 3:36 ` danmcleran 2005-01-02 15:53 ` Ed Falis 2005-01-07 18:31 ` danmcleran 2005-01-07 18:44 ` Pascal Obry 2005-01-07 19:29 ` danmcleran 2005-01-07 21:28 ` Pascal Obry 2005-01-01 23:28 ` danmcleran 2005-01-02 10:26 ` Dmitry A. Kazakov 2005-01-02 15:51 ` danmcleran 2005-01-03 23:48 ` Randy Brukardt 2005-01-01 14:06 ` Martin Krischik 2005-01-01 15:53 ` danmcleran 2005-01-07 21:33 ` Robert A Duff 2005-01-09 17:15 ` danmcleran 2005-01-09 17:38 ` Robert A Duff 2005-01-10 3:16 ` danmcleran 2005-01-09 18:41 ` Martin Dowie 2005-01-10 3:18 ` danmcleran 2005-01-10 20:32 ` Randy Brukardt 2005-01-10 21:42 ` danmcleran 2005-01-10 21:36 ` Robert A Duff 2005-01-10 21:44 ` danmcleran 2005-01-09 19:01 ` Jeffrey Carter 2005-01-10 3:20 ` danmcleran 2005-01-10 22:16 ` Robert A Duff 2005-01-10 22:29 ` danmcleran 2005-01-11 20:12 ` Georg Bauhaus 2005-01-11 20:30 ` danmcleran 2005-01-11 21:44 ` Robert A Duff 2005-01-11 0:06 ` Jeffrey Carter 2005-01-11 0:46 ` Robert A Duff 2005-01-11 20:37 ` danmcleran 2005-01-11 21:08 ` Robert A Duff 2005-01-17 4:40 ` Tucker 2005-01-18 13:46 ` danmcleran 2005-01-18 21:29 ` Nick Roberts 2005-01-24 17:23 ` danmcleran -- strict thread matches above, loose matches on Subject: below -- 2004-12-31 19:06 danmcleran
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox