* Ripple effect @ 2006-08-23 22:29 Jeffrey R. Carter 2006-08-24 9:21 ` Maciej Sobczak ` (2 more replies) 0 siblings, 3 replies; 26+ messages in thread From: Jeffrey R. Carter @ 2006-08-23 22:29 UTC (permalink / raw) On the Ada-Comment mailing list recently, Robert Duff shared some ideas on language design for a language he is thinking about (which may be called Nada, but is definitely not called Duff). In this language, there is no equivalent of the Ada "use" and primitive operators ("+", "-") of a type are directly visible wherever the type is used. I recall that during the Ada-9X revision process, it was proposed that primitive operators of a type have this kind of visibility. IIRC, one of the reasons that this was not accepted was that it would lead to Ripple effects: adding or removing a unit from a context clause could change one legal program to a different legal program. If Herr Doktor Professor Duff is interested, I'd like to hear his thoughts on the matter, and how Nada (or whatever) deals with this. -- Jeff Carter "Brave Sir Robin ran away." Monty Python and the Holy Grail 59 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Ripple effect 2006-08-23 22:29 Ripple effect Jeffrey R. Carter @ 2006-08-24 9:21 ` Maciej Sobczak 2006-08-24 23:39 ` Jeffrey R. Carter 2006-08-24 18:22 ` Adam Beneschan 2006-09-04 13:52 ` Robert A Duff 2 siblings, 1 reply; 26+ messages in thread From: Maciej Sobczak @ 2006-08-24 9:21 UTC (permalink / raw) Jeffrey R. Carter wrote: > I recall that during the Ada-9X revision process, it was proposed that > primitive operators of a type have this kind of visibility. IIRC, one of > the reasons that this was not accepted was that it would lead to Ripple > effects: adding or removing a unit from a context clause could change > one legal program to a different legal program. Why? If you remove some use clause that might affect the visibility of some primitive operation, then it will also remove the whole type that is involved in a given expression, rendering the whole as illegal. Could you provide a short example of this Ripple effect? -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/ ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Ripple effect 2006-08-24 9:21 ` Maciej Sobczak @ 2006-08-24 23:39 ` Jeffrey R. Carter 2006-08-25 7:03 ` Maciej Sobczak 0 siblings, 1 reply; 26+ messages in thread From: Jeffrey R. Carter @ 2006-08-24 23:39 UTC (permalink / raw) Maciej Sobczak wrote: > > Why? > If you remove some use clause that might affect the visibility of some > primitive operation, then it will also remove the whole type that is > involved in a given expression, rendering the whole as illegal. > > Could you provide a short example of this Ripple effect? No. I'm simply aware that STT cites direct operator visibility as potentially giving rise to the Ripple effect in the Ada FAQ http://www.adapower.com/index.php?Command=Class&ClassID=FAQ&CID=358 -- Jeff Carter "Now go away or I shall taunt you a second time." Monty Python & the Holy Grail 07 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Ripple effect 2006-08-24 23:39 ` Jeffrey R. Carter @ 2006-08-25 7:03 ` Maciej Sobczak 0 siblings, 0 replies; 26+ messages in thread From: Maciej Sobczak @ 2006-08-25 7:03 UTC (permalink / raw) Jeffrey R. Carter wrote: >> Why? >> If you remove some use clause that might affect the visibility of some >> primitive operation, then it will also remove the whole type that is >> involved in a given expression, rendering the whole as illegal. >> >> Could you provide a short example of this Ripple effect? > > No. I'm simply aware that STT cites direct operator visibility as > potentially giving rise to the Ripple effect in the Ada FAQ > > http://www.adapower.com/index.php?Command=Class&ClassID=FAQ&CID=358 Yes, I've seen it already. Still, something is missing. As a C++ programmer, I like the idea of doing this: std::cout << "Hello"; without writing using namespace std - the stream insertion operator will be found in the appropriate namespace (std in this case) and it's enough to qualify std::cout to make it happen. Without this feature, I would need to write this: std::operator<<(std::cout, "Hello"); Now, adding or removing #include directives might change one legal C++ program into another legal program, but this is due to implicit conversions - without them I don't see any way for this to happen. That's why the assertion that such effect is possible in Ada strikes me a little bit. Waiting for examples. -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/ ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Ripple effect 2006-08-23 22:29 Ripple effect Jeffrey R. Carter 2006-08-24 9:21 ` Maciej Sobczak @ 2006-08-24 18:22 ` Adam Beneschan 2006-08-24 23:40 ` Jeffrey R. Carter 2006-09-04 13:52 ` Robert A Duff 2 siblings, 1 reply; 26+ messages in thread From: Adam Beneschan @ 2006-08-24 18:22 UTC (permalink / raw) Jeffrey R. Carter wrote: > I recall that during the Ada-9X revision process, it was proposed that > primitive operators of a type have this kind of visibility. IIRC, one of > the reasons that this was not accepted was that it would lead to Ripple > effects: adding or removing a unit from a context clause could change > one legal program to a different legal program. This has nothing to do with the topic. But my understanding is that the Beaujolais effect was named because Jean Ichbiah offered a bottle of Beaujolais wine to anyone who could find a certain anomaly in the language. So are you saying that if someone finds a Ripple effect, you're going to offer them a bottle of .... ??? Aaahh... I don't even think they sell it any more. -- Adam ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Ripple effect 2006-08-24 18:22 ` Adam Beneschan @ 2006-08-24 23:40 ` Jeffrey R. Carter 0 siblings, 0 replies; 26+ messages in thread From: Jeffrey R. Carter @ 2006-08-24 23:40 UTC (permalink / raw) Adam Beneschan wrote: > > This has nothing to do with the topic. But my understanding is that > the Beaujolais effect was named because Jean Ichbiah offered a bottle > of Beaujolais wine to anyone who could find a certain anomaly in the > language. So are you saying that if someone finds a Ripple effect, > you're going to offer them a bottle of .... ??? What topic? I started this thread about the Ripple effect and direct operator visibility. It has little to do with the Beaujolais effect. Information about the Ripple effect is available at http://www.adapower.com/index.php?Command=Class&ClassID=FAQ&CID=358 -- Jeff Carter "Now go away or I shall taunt you a second time." Monty Python & the Holy Grail 07 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Ripple effect 2006-08-23 22:29 Ripple effect Jeffrey R. Carter 2006-08-24 9:21 ` Maciej Sobczak 2006-08-24 18:22 ` Adam Beneschan @ 2006-09-04 13:52 ` Robert A Duff 2006-09-04 15:15 ` Jeffrey R. Carter 2006-09-07 19:09 ` Adam Beneschan 2 siblings, 2 replies; 26+ messages in thread From: Robert A Duff @ 2006-09-04 13:52 UTC (permalink / raw) "Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org> writes: > On the Ada-Comment mailing list recently, Robert Duff shared some ideas > on language design for a language he is thinking about (which may be > called Nada, but is definitely not called Duff). The "Nada" thing was a joke. I would not call a language "Nada", and certainly not "Duff". ;-) But Jeff is correct that I'm continually thinking about designing a programming langage -- at this point, it's merely a hobby, and I have no name for the language. >...In this language, there > is no equivalent of the Ada "use" and primitive operators ("+", "-") of > a type are directly visible wherever the type is used. I think you mean there is no equivalent of "use type". > I recall that during the Ada-9X revision process, it was proposed that > primitive operators of a type have this kind of visibility. IIRC, one of > the reasons that this was not accepted was that it would lead to Ripple > effects: adding or removing a unit from a context clause could change > one legal program to a different legal program. No, I think you misunderstand the "Ripple Effect". As I understand it, the Ripple Effect means that adding/removing a with_clause can cause compilation units that do not depend DIRECTLY on the modified thing to become illegal. For example, suppose C with's B and B with's A. Can a with_clause on A affect the legality of C? If so, there's a Ripple Effect. There's no issue of changing the meaning from one legal program to another, as can happen with the Beaujolais Effect. Therefore, the Ripple Effect is (IMHO) merely an annoyance, rather than a bug-causing language-design flaw. I believe Tucker coined the term "Ripple Effect", and that one is supposed to imagine the addition of a with_clause rippling through the transitive closure of semantic dependences. Also, it's a joke because Ripple is a wine -- that's the main similarity to Beaujolais Effect. I've never tasted Ripple, but I think it's considered to be of somewhat lower quality than Beaujolais. ;-) Anyway, to answer Jeff's question: I think with_clauses should be transitive in the first place, so that the Ripple Effect is not an issue. One problem with Ada 83 is that with_clauses cannot appear inside the private part. I think that's the root of the idea that transitive with_clauses are somehow evil. - Bob ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Ripple effect 2006-09-04 13:52 ` Robert A Duff @ 2006-09-04 15:15 ` Jeffrey R. Carter 2006-09-04 18:06 ` Robert A Duff 2006-09-07 19:09 ` Adam Beneschan 1 sibling, 1 reply; 26+ messages in thread From: Jeffrey R. Carter @ 2006-09-04 15:15 UTC (permalink / raw) Robert A Duff wrote: > > The "Nada" thing was a joke. I would not call a language "Nada", and > certainly not "Duff". ;-) Nada sounds like a great name for a language :) "What's so great about this language?" "Oh, Nada." You did indicate that you would probably name it after someone. > I think you mean there is no equivalent of "use type". IIRC, there is no equivalent of "use" or "use type". Of course, I may have misunderstood. > No, I think you misunderstand the "Ripple Effect". As I understand it, > the Ripple Effect means that adding/removing a with_clause can cause > compilation units that do not depend DIRECTLY on the modified thing to > become illegal. For example, suppose C with's B and B with's A. Can a > with_clause on A affect the legality of C? If so, there's a Ripple > Effect. I've just rechecked the answer in the FAQ at adapower.com, and I think we're both mistaken: 'In brief, the (undesirable) Ripple effect was related to whether the legality of a compilation unit could be affected by adding or removing an otherwise unneeded "with" clause on some compilation unit on which the unit depended, directly or indirectly.' (Tucker Taft) So it's not a with on C, as I thought, and can be a with on B, which you exclude. It also refers only to unneeded withs. So, if B withs A unnecessarily, that could cause a Ripple effect. > Anyway, to answer Jeff's question: I think with_clauses should be > transitive in the first place, so that the Ripple Effect is not an > issue. So you mean, in the example you give above, that because C withs B and B withs A, that C withs A? Is that how your language works? -- Jeff Carter "Now look, Col. Batguano, if that really is your name." Dr. Strangelove 31 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Ripple effect 2006-09-04 15:15 ` Jeffrey R. Carter @ 2006-09-04 18:06 ` Robert A Duff 2006-09-05 2:33 ` Jeffrey R. Carter 0 siblings, 1 reply; 26+ messages in thread From: Robert A Duff @ 2006-09-04 18:06 UTC (permalink / raw) "Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org> writes: > Robert A Duff wrote: > > The "Nada" thing was a joke. I would not call a language "Nada", and > > certainly not "Duff". ;-) > > Nada sounds like a great name for a language :) "What's so great about > this language?" "Oh, Nada." Nah. > You did indicate that you would probably name it after someone. Who or whom? ;-) > > I think you mean there is no equivalent of "use type". > > IIRC, there is no equivalent of "use" or "use type". Of course, I may > have misunderstood. Not sure about "use" but "use type" is a bad idea -- should be the default. > > No, I think you misunderstand the "Ripple Effect". As I understand it, > > the Ripple Effect means that adding/removing a with_clause can cause > > compilation units that do not depend DIRECTLY on the modified thing to > > become illegal. For example, suppose C with's B and B with's A. Can a > > with_clause on A affect the legality of C? If so, there's a Ripple > > Effect. > > I've just rechecked the answer in the FAQ at adapower.com, and I think > we're both mistaken: Could be. >...'In brief, the (undesirable) Ripple effect was > related to whether the legality of a compilation unit could be affected > by adding or removing an otherwise unneeded "with" clause on some > compilation unit on which the unit depended, directly or indirectly.' > (Tucker Taft) Sorry, but I've lost the context here. What does "otherwise unneeded" mean? > So it's not a with on C, as I thought, and can be a with on B, which you > exclude. It also refers only to unneeded withs. So, if B withs A > unnecessarily, that could cause a Ripple effect. Not sure what "unnecessarily" means. I mean, if you say "with A" and refer to A.Mumble, that's "necessary", right? > > Anyway, to answer Jeff's question: I think with_clauses should be > > transitive in the first place, so that the Ripple Effect is not an > > issue. > > So you mean, in the example you give above, that because C withs B and B > withs A, that C withs A? Is that how your language works? Yes. Do you think it should be otherwise? - Bob ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Ripple effect 2006-09-04 18:06 ` Robert A Duff @ 2006-09-05 2:33 ` Jeffrey R. Carter 2006-09-05 7:23 ` Dmitry A. Kazakov ` (2 more replies) 0 siblings, 3 replies; 26+ messages in thread From: Jeffrey R. Carter @ 2006-09-05 2:33 UTC (permalink / raw) Robert A Duff wrote: > > Who or whom? ;-) [did he say he'd probably name the language after] You didn't say. I mentioned the main groups of language names: acronyms, things (Java), and people (Ada, Dylan). You said you'd probably go the people route. > Not sure about "use" but "use type" is a bad idea -- should be the > default. OK. In the discussion, your language used "use" in context clauses as equivalent to Ada's "with" (which sounds like a good idea), and you didn't show any equivalent to Ada's "use". I thought I recalled you saying that the language didn't have one, but I guess IDRC. If you do have an equivalent to Ada's "use", maybe it should be called "see". > Sorry, but I've lost the context here. What does "otherwise unneeded" > mean? > Not sure what "unnecessarily" means. I mean, if you say "with A" and > refer to A.Mumble, that's "necessary", right? My understanding is that B has "with A;" but doesn't reference A; A is "otherwise unneeded" because it's needed to make C (il)legal. > Yes. Do you think it should be otherwise? [transitive context clauses] It seems awkward. We're working on a project. I create package B, which has "with A;" on it. I thought B would need it, but I was wrong, and forgot to remove it. You're developing C and need to use B, so you have "with B;" on C. Then you realize you need to use A and write some code that references A. You forget to put "with A;" on C, but it compiles OK because B references A. Then I clean up B and remove the reference to A from it. Now C doesn't compile. That seems undesirable. -- Jeff Carter "Now look, Col. Batguano, if that really is your name." Dr. Strangelove 31 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Ripple effect 2006-09-05 2:33 ` Jeffrey R. Carter @ 2006-09-05 7:23 ` Dmitry A. Kazakov 2006-09-05 16:28 ` Robert A Duff 2006-09-05 16:23 ` Robert A Duff 2006-09-05 23:52 ` Randy Brukardt 2 siblings, 1 reply; 26+ messages in thread From: Dmitry A. Kazakov @ 2006-09-05 7:23 UTC (permalink / raw) On Tue, 05 Sep 2006 02:33:47 GMT, Jeffrey R. Carter wrote: > OK. In the discussion, your language used "use" in context clauses as > equivalent to Ada's "with" (which sounds like a good idea), and you > didn't show any equivalent to Ada's "use". I thought I recalled you > saying that the language didn't have one, but I guess IDRC. > > If you do have an equivalent to Ada's "use", maybe it should be called > "see". You don't need it, if the language offers constructs to handle namespaces, especially to compose them out of existing ones. Then you could merge specifications of several packages into a new specification and re-use it where needed. >> Yes. Do you think it should be otherwise? [transitive context clauses] > > It seems awkward. We're working on a project. I create package B, which > has "with A;" on it. I thought B would need it, but I was wrong, and > forgot to remove it. You're developing C and need to use B, so you have > "with B;" on C. Then you realize you need to use A and write some code > that references A. You forget to put "with A;" on C, but it compiles OK > because B references A. Then I clean up B and remove the reference to A > from it. Now C doesn't compile. That seems undesirable. You complain that missing "with" could be a lie, but it so anyway. I think that management of non-transitive "with" is an unnecessary burden. If you have 20+ packages, then it becomes unrealistic to inspect all with-clauses each time you change something. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Ripple effect 2006-09-05 7:23 ` Dmitry A. Kazakov @ 2006-09-05 16:28 ` Robert A Duff 0 siblings, 0 replies; 26+ messages in thread From: Robert A Duff @ 2006-09-05 16:28 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > You don't need it, if the language offers constructs to handle namespaces, > especially to compose them out of existing ones. Then you could merge > specifications of several packages into a new specification and re-use it > where needed. It would certainly be useful to be able to say "package X exports everything declared in packages A, B, C, and D", in a maintainable way (so that if you add something to A it automatically appears in X). Ada allows renaming, but that's unmaintainable, because you have to rename each thing separately. Ada also allows derived types, which automatically suck in the primitive ops, but that doesn't work for generics, exceptions, etc, and it breaks when you have two related types. - Bob ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Ripple effect 2006-09-05 2:33 ` Jeffrey R. Carter 2006-09-05 7:23 ` Dmitry A. Kazakov @ 2006-09-05 16:23 ` Robert A Duff 2006-09-05 21:36 ` Jeffrey R. Carter 2006-09-06 0:10 ` Randy Brukardt 2006-09-05 23:52 ` Randy Brukardt 2 siblings, 2 replies; 26+ messages in thread From: Robert A Duff @ 2006-09-05 16:23 UTC (permalink / raw) "Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org> writes: > Robert A Duff wrote: > > Not sure about "use" but "use type" is a bad idea -- should be the > > default. > > OK. In the discussion, your language used "use" in context clauses as > equivalent to Ada's "with" (which sounds like a good idea), and you > didn't show any equivalent to Ada's "use". I thought I recalled you > saying that the language didn't have one, but I guess IDRC. I think I want something like Ada's "use". Pascal calls it "with" (for records, as opposed to packages). It has nasty Beaujolais-like effects, but that's not necessary. One of the brilliant things Ichbiah did was to eliminate Beaujolais effects. Well, almost -- Ada 9X finished the job. And Ichbiah didn't go far enough in that regard -- I would eliminate hiding entirely. But I think perhaps the "use"-like thing belongs on the package, rather than on the clients of the package, because the person who writes the package needs to use naming conventions that make sense for use or not-use. I've considered calling it "open" -- it opens up the scope for visibility. An "open" module provides direct visibility of its contents to clients. And perhaps an "open" statement in addition, to be used by clients. > If you do have an equivalent to Ada's "use", maybe it should be called > "see". Perhaps. But if it goes on the package/module, it should be an adjective. > > Yes. Do you think it should be otherwise? [transitive context clauses] > > It seems awkward. We're working on a project. I create package B, which > has "with A;" on it. I thought B would need it, but I was wrong, and > forgot to remove it. You're developing C and need to use B, so you have > "with B;" on C. Then you realize you need to use A and write some code > that references A. You forget to put "with A;" on C, but it compiles OK > because B references A. Then I clean up B and remove the reference to A > from it. Now C doesn't compile. That seems undesirable. It does not bother me that a change to the visible part of A affects clients, transitively. That has to be true, in general. My thinking is that if B uses A in a visible way, C pretty-much has to know about A. E.g.: with A; package B is procedue Mumble(X: A.T); end B; If C uses B.Mumble, it most likely needs to declare objects of type A.T. C certainly knows about type A.T! So non-transitive with's cause a lot of clutter -- C needs to 'with' everything it uses, plus everything those things are (visibly) based on, transitively. So high-level packages tend to have so many with_clauses that nobody wants to read them, largely defeating the purpose. OTOH, if B uses A only for implementation, that's a different story. Then the import of A belongs on the body of B, and C shouldn't know about it. (My language doesn't have private parts.) By the way, the issue of bogus with_clauses is a real maintenance problem -- nobody ever deletes a with_clause, so they tend to accumulate. This problem is easily solved. The compiler should give an error message. An error that can be suppressed, so that you can temporarily have bogus with_clauses during development. That's essentially what GNAT does, with appropriate warning switches. - Bob ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Ripple effect 2006-09-05 16:23 ` Robert A Duff @ 2006-09-05 21:36 ` Jeffrey R. Carter 2006-09-07 18:18 ` Robert A Duff 2006-09-06 0:10 ` Randy Brukardt 1 sibling, 1 reply; 26+ messages in thread From: Jeffrey R. Carter @ 2006-09-05 21:36 UTC (permalink / raw) Robert A Duff wrote: > > I think I want something like Ada's "use". Pascal calls it "with" (for > records, as opposed to packages). It has nasty Beaujolais-like effects, > but that's not necessary. One of the brilliant things Ichbiah did was > to eliminate Beaujolais effects. Well, almost -- Ada 9X finished the > job. And Ichbiah didn't go far enough in that regard -- I would > eliminate hiding entirely. OK. I'm leaning the other way. > But I think perhaps the "use"-like thing belongs on the package, rather > than on the clients of the package, because the person who writes the > package needs to use naming conventions that make sense for use or > not-use. > > I've considered calling it "open" -- it opens up the scope for > visibility. An "open" module provides direct visibility of its contents > to clients. And perhaps an "open" statement in addition, to be used by > clients. Thanks for the description. Are you saying that only an open module can be opened by a client, but clients can not open a module and treated like a closed module? > My thinking is that if B uses A in a visible way, C pretty-much has to > know about A. E.g.: > > with A; > package B is > procedue Mumble(X: A.T); > end B; > > If C uses B.Mumble, it most likely needs to declare objects of type A.T. > C certainly knows about type A.T! So non-transitive with's cause a lot > of clutter -- C needs to 'with' everything it uses, plus everything > those things are (visibly) based on, transitively. So high-level > packages tend to have so many with_clauses that nobody wants to read > them, largely defeating the purpose. True, but we're talking about the case where B doesn't actually reference A (the with of A is "otherwise unneeded"). > OTOH, if B uses A only for implementation, that's a different story. > Then the import of A belongs on the body of B, and C shouldn't know > about it. (My language doesn't have private parts.) Agreed. > By the way, the issue of bogus with_clauses is a real maintenance > problem -- nobody ever deletes a with_clause, so they tend to > accumulate. This problem is easily solved. The compiler should give an > error message. An error that can be suppressed, so that you can > temporarily have bogus with_clauses during development. That's > essentially what GNAT does, with appropriate warning switches. My sediments exactly. In fact, I do delete unneeded withs when I find them. -- Jeff Carter "There's no messiah here. There's a mess all right, but no messiah." Monty Python's Life of Brian 84 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Ripple effect 2006-09-05 21:36 ` Jeffrey R. Carter @ 2006-09-07 18:18 ` Robert A Duff 2006-09-08 22:02 ` Jeffrey R. Carter 0 siblings, 1 reply; 26+ messages in thread From: Robert A Duff @ 2006-09-07 18:18 UTC (permalink / raw) "Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org> writes: > Robert A Duff wrote: > > I think I want something like Ada's "use". Pascal calls it "with" (for > > records, as opposed to packages). It has nasty Beaujolais-like effects, > > but that's not necessary. One of the brilliant things Ichbiah did was > > to eliminate Beaujolais effects. Well, almost -- Ada 9X finished the > > job. And Ichbiah didn't go far enough in that regard -- I would > > eliminate hiding entirely. > > OK. I'm leaning the other way. I suppose there are many other ways; I'm not sure which one you're leaning toward. ;-) Surely not to increase Beaujolais-like effects!? > Thanks for the description. Are you saying that only an open module can > be opened by a client, but clients can not open a module and treated > like a closed module? I'm not sure. The user can declare a module "open". If you say "use X", you get visibility on X (remember this is not Ada's "use"). If X is open, you also get (direct) visibility on the contents of X. The part I'm not sure about is whether to _also_ provide something like Ada's "use" clause, which allows clients of a non-open module to open it. It could work for records, too, like Pascal's "with" statement -- except that I would eliminate the nasty Beaujolais-like effects of Pascal. > > My thinking is that if B uses A in a visible way, C pretty-much has to > > know about A. E.g.: > > with A; > > package B is > > procedue Mumble(X: A.T); > > end B; > > If C uses B.Mumble, it most likely needs to declare objects of type > > A.T. > > C certainly knows about type A.T! So non-transitive with's cause a lot > > of clutter -- C needs to 'with' everything it uses, plus everything > > those things are (visibly) based on, transitively. So high-level > > packages tend to have so many with_clauses that nobody wants to read > > them, largely defeating the purpose. > > True, but we're talking about the case where B doesn't actually > reference A (the with of A is "otherwise unneeded"). I guess I'm confused as to what the issue is, then. If B doesn't reference A, then it shouldn't import it -- and the compiler should give a (suppressable) error. Suppressable because you might want unused imports temporarily during construction. Also, there are some cases where unused imports are needed. > > OTOH, if B uses A only for implementation, that's a different story. > > Then the import of A belongs on the body of B, and C shouldn't know > > about it. (My language doesn't have private parts.) > > Agreed. > > > By the way, the issue of bogus with_clauses is a real maintenance > > problem -- nobody ever deletes a with_clause, so they tend to > > accumulate. This problem is easily solved. The compiler should give an > > error message. An error that can be suppressed, so that you can > > temporarily have bogus with_clauses during development. That's > > essentially what GNAT does, with appropriate warning switches. > > My sediments exactly. In fact, I do delete unneeded withs when I find them. Sure, so do I, but they're hard to find by hand. Once when I turned on the GNAT warning for unused with's on a program of about 200,000 lines, I found hundreds and hundreds of them. - Bob ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Ripple effect 2006-09-07 18:18 ` Robert A Duff @ 2006-09-08 22:02 ` Jeffrey R. Carter 0 siblings, 0 replies; 26+ messages in thread From: Jeffrey R. Carter @ 2006-09-08 22:02 UTC (permalink / raw) Robert A Duff wrote: > > I suppose there are many other ways; I'm not sure which one you're > leaning toward. ;-) Surely not to increase Beaujolais-like effects!? The world would be a different place if we all drank a bottle of Beaujolais a day. I'm leaning toward not have "use". It seems to work pretty well in SPARK. It also tends to make you think up good names. > I'm not sure. The user can declare a module "open". If you say > "use X", you get visibility on X (remember this is not Ada's "use"). If > X is open, you also get (direct) visibility on the contents of X. The > part I'm not sure about is whether to _also_ provide something like > Ada's "use" clause, which allows clients of a non-open module to open > it. It could work for records, too, like Pascal's "with" statement -- > except that I would eliminate the nasty Beaujolais-like effects of > Pascal. Thanks for the explanation. I never found Pascal's "with" to be very useful. > I guess I'm confused as to what the issue is, then. If B doesn't > reference A, then it shouldn't import it -- and the compiler should > give a (suppressable) error. Suppressable because you might want unused > imports temporarily during construction. Also, there are some cases > where unused imports are needed. I would probably outlaw them completely, with a way to create exceptions when they're actually needed. -- Jeff Carter "Pray that there's intelligent life somewhere up in space, 'cause there's bugger all down here on earth." Monty Python's Meaning of Life 61 ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Ripple effect 2006-09-05 16:23 ` Robert A Duff 2006-09-05 21:36 ` Jeffrey R. Carter @ 2006-09-06 0:10 ` Randy Brukardt 2006-09-07 18:30 ` Robert A Duff 2006-09-09 14:55 ` adaworks 1 sibling, 2 replies; 26+ messages in thread From: Randy Brukardt @ 2006-09-06 0:10 UTC (permalink / raw) "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message news:wccpseab7u4.fsf@shell01.TheWorld.com... > "Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org> writes: > > It seems awkward. We're working on a project. I create package B, which > > has "with A;" on it. I thought B would need it, but I was wrong, and > > forgot to remove it. You're developing C and need to use B, so you have > > "with B;" on C. Then you realize you need to use A and write some code > > that references A. You forget to put "with A;" on C, but it compiles OK > > because B references A. Then I clean up B and remove the reference to A > > from it. Now C doesn't compile. That seems undesirable. > > It does not bother me that a change to the visible part of A affects > clients, transitively. That has to be true, in general. > > My thinking is that if B uses A in a visible way, C pretty-much has to > know about A. E.g.: > > with A; > package B is > procedue Mumble(X: A.T); > end B; > > If C uses B.Mumble, it most likely needs to declare objects of type A.T. > C certainly knows about type A.T! I guess I disagree -- simply knowing about a type doesn't require objects to be created. Indeed, I spent a lot of effort (and other did too, I don't want to appear to be taking all of the credit) to ensure that limited withs don't require a regular with of a unit unless that unit actually needs to create an object. (If the object comes from somewhere else -- a common case, such as when an access to it is passed in -- no with is needed). In any case, most of the problem withs are either unused completely (because of maintenance) or only exist for the private part (a good package has very few visible dependencies). > So non-transitive with's cause a lot > of clutter -- C needs to 'with' everything it uses, plus everything > those things are (visibly) based on, transitively. So high-level > packages tend to have so many with_clauses that nobody wants to read > them, largely defeating the purpose. Only if the lower level packages have a lot of dependencies, and way too many things are used in one place. The Janus/Ada compiler's code looks like you suggest (although I think it is a benefit, not a problem, because it encourages better structure), but most of our more modern programs either don't have such things at all, or have them specifically to solve elaboration issues [that's a different subject altogether]. Even for Janus/Ada, no one reads the top-level packages, because they consist of little more than "parse program", "load predefined symbols", "load symbols for context clause", "handle semantics for program, making intermediate code", "optimize intermediate code", and "generate code for intermediate code". Rarely does that need maintenance! > OTOH, if B uses A only for implementation, that's a different story. > Then the import of A belongs on the body of B, and C shouldn't know > about it. (My language doesn't have private parts.) > > By the way, the issue of bogus with_clauses is a real maintenance > problem -- nobody ever deletes a with_clause, so they tend to > accumulate. Huh? I often check for unused with clauses in my programs - by hand, and generally not because of compiler warnings (although we get those, too). I often try to eliminate things that are used only once. I guess I'd agree more if you said "rarely" as opposed to "ever". > This problem is easily solved. The compiler should give an > error message. An error that can be suppressed, so that you can > temporarily have bogus with_clauses during development. That's > essentially what GNAT does, with appropriate warning switches. Don't all Ada compilers at least have a warning? Janus/Ada always has (perhaps because of our focus on space -- loading unnecessary junk into an already tight space doesn't make sense). Unusued with clauses can be a significant performance drag on compilation, among other things. As I said, I often check with clauses, even before compiling (so I don't see the warning). Randy. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Ripple effect 2006-09-06 0:10 ` Randy Brukardt @ 2006-09-07 18:30 ` Robert A Duff 2006-09-07 21:21 ` Simon Wright 2006-09-08 2:08 ` Randy Brukardt 2006-09-09 14:55 ` adaworks 1 sibling, 2 replies; 26+ messages in thread From: Robert A Duff @ 2006-09-07 18:30 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> writes: > I guess I disagree -- simply knowing about a type doesn't require objects to > be created. True. But if you know about a type, why are you not allowed to create objects, or parameters, or do anything else that requires its name? >... Indeed, I spent a lot of effort (and other did too, I don't want > to appear to be taking all of the credit) to ensure that limited withs don't > require a regular with of a unit unless that unit actually needs to create > an object. I agree with you about this aspect of limited withs. >... (If the object comes from somewhere else -- a common case, such > as when an access to it is passed in -- no with is needed). I'm not sure I understand. Can you give a realistic example? > In any case, most of the problem withs are either unused completely (because > of maintenance) or only exist for the private part (a good package has very > few visible dependencies). Yeah. The syntax should have the imports INSIDE the package, not BEFORE it. Something like: package P is with A; ... private with B; ... end P; although my preference would be to eliminate private parts altogether. > > So non-transitive with's cause a lot > > of clutter -- C needs to 'with' everything it uses, plus everything > > those things are (visibly) based on, transitively. So high-level > > packages tend to have so many with_clauses that nobody wants to read > > them, largely defeating the purpose. > > Only if the lower level packages have a lot of dependencies, and way too > many things are used in one place. It's certainly a good design principle to try to avoid visible imports as much as possible. >... The Janus/Ada compiler's code looks like > you suggest (although I think it is a benefit, not a problem, because it > encourages better structure), but most of our more modern programs either > don't have such things at all, or have them specifically to solve > elaboration issues [that's a different subject altogether]. > > Even for Janus/Ada, no one reads the top-level packages, because they > consist of little more than "parse program", "load predefined symbols", > "load symbols for context clause", "handle semantics for program, making > intermediate code", "optimize intermediate code", and "generate code for > intermediate code". Rarely does that need maintenance! > > > OTOH, if B uses A only for implementation, that's a different story. > > Then the import of A belongs on the body of B, and C shouldn't know > > about it. (My language doesn't have private parts.) > > > > By the way, the issue of bogus with_clauses is a real maintenance > > problem -- nobody ever deletes a with_clause, so they tend to > > accumulate. > > Huh? I often check for unused with clauses in my programs - by hand, and > generally not because of compiler warnings (although we get those, too). I > often try to eliminate things that are used only once. I guess I'd agree > more if you said "rarely" as opposed to "ever". OK, "rarely" then. It's hard to do that sort of thing by hand. It's not just unused with_clauses that accumulate during maintenance, but all kinds of other unused things (use clauses, variables, etc). > > This problem is easily solved. The compiler should give an > > error message. An error that can be suppressed, so that you can > > temporarily have bogus with_clauses during development. That's > > essentially what GNAT does, with appropriate warning switches. > > Don't all Ada compilers at least have a warning? I don't know. They should. But I'd prefer the language to require it, partly because the notion of what's "unused" is subtle, and I'd like it to be portable. And the ability to suppress that warning/error is important enough that I'd put that in the language, too. >... Janus/Ada always has > (perhaps because of our focus on space -- loading unnecessary junk into an > already tight space doesn't make sense). Unusued with clauses can be a > significant performance drag on compilation, among other things. As I said, > I often check with clauses, even before compiling (so I don't see the > warning). - Bob ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Ripple effect 2006-09-07 18:30 ` Robert A Duff @ 2006-09-07 21:21 ` Simon Wright 2006-09-08 2:08 ` Randy Brukardt 1 sibling, 0 replies; 26+ messages in thread From: Simon Wright @ 2006-09-07 21:21 UTC (permalink / raw) Sounds as though you could write the binding as a generic? (you'd need to have the C code compiled in the three different ways and choose which to link against -- could you build 3 dynamic libraries from the C and use pragma Linker_Options in the Ada to choose the right one???) ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Ripple effect 2006-09-07 18:30 ` Robert A Duff 2006-09-07 21:21 ` Simon Wright @ 2006-09-08 2:08 ` Randy Brukardt 1 sibling, 0 replies; 26+ messages in thread From: Randy Brukardt @ 2006-09-08 2:08 UTC (permalink / raw) "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message news:wccodtr4jhx.fsf@shell01.TheWorld.com... > "Randy Brukardt" <randy@rrsoftware.com> writes: > > > I guess I disagree -- simply knowing about a type doesn't require objects to > > be created. > > True. But if you know about a type, why are you not allowed to create > objects, or parameters, or do anything else that requires its name? Knowing about a type is a completely separate issue from knowing its name. That's required here simply because the syntax of declarations requires giving the name, not because you actually intend to use that name for anything. ... > >... (If the object comes from somewhere else -- a common case, such > > as when an access to it is passed in -- no with is needed). > > I'm not sure I understand. Can you give a realistic example? Well, a relistic example would be large and take a long time to create. What I'm thinking about is cases where you have a private type that is simply passed through a routine to another layer. I find this sort of thing common in some designs (it depends on how the low-level types are encapsulated). So, if you have a routine something like: procedure Foo (Obj : in Something; Other_Data : in Integer) is begin if Other_Data < 0 then X.Flob (Obj); else X.Flub (Obj, Other_Data); end if; end Foo; Assume that the parameters of Flob and Flub are classwide (and Something is tagged). In this case, no other information is needed, and it isn't necessary to "with" the place where X.Flob's parameter is declared, and drag all kinds of stuff you're not going to use into visibility. This is quite common, except that the need to repeat the name of the type in the subprogram declarations often causes an otherwise unnecessary dependency. "Limited with" can break that in some cases. ... > > Huh? I often check for unused with clauses in my programs - by hand, and > > generally not because of compiler warnings (although we get those, too). I > > often try to eliminate things that are used only once. I guess I'd agree > > more if you said "rarely" as opposed to "ever". > > OK, "rarely" then. It's hard to do that sort of thing by hand. > It's not just unused with_clauses that accumulate during maintenance, > but all kinds of other unused things (use clauses, variables, etc). Unused withs are easy to do by hand if you rarely use 'use' clauses: simply use your editor to show all occurrences of the name of the unit. If there is no hit other than the with clause itself, its unused. If there is only a use clause, (and no other uses), I'll comment out the use clause and see what happens in a recompile (and add comments if it turns out to be needed so I don't do it next time). I generally don't bother eliminating other unused things, although the technique is the same. Well, I'll do variables if cut-and-paste operations are potentially creating a lot of them. (Janus/Ada does not have any unused warnings other than for with clauses; it's almost one-pass design makes that very hard). Randy. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Ripple effect 2006-09-06 0:10 ` Randy Brukardt 2006-09-07 18:30 ` Robert A Duff @ 2006-09-09 14:55 ` adaworks 1 sibling, 0 replies; 26+ messages in thread From: adaworks @ 2006-09-09 14:55 UTC (permalink / raw) "Randy Brukardt" <randy@rrsoftware.com> wrote in message news:upmdnWsSlagGjGPZnZ2dnUVZ_rudnZ2d@megapath.net... > > Huh? I often check for unused with clauses in my programs - by hand, and > generally not because of compiler warnings (although we get those, too). I > often try to eliminate things that are used only once. I guess I'd agree > more if you said "rarely" as opposed to "ever". > I recall an early DoD system programmed in Ada where the dependency chart looked like a hairball. The reason was that all the with clauses were in the package specifications. Sad to say, the compiler did not alert anyone to the problem the way some compilers of today will. Everytime any unit had to be compiled, all the packages in the with clauses also had to be recompiled. OK. This was a silly design. But Ada was new and it took time to catch on the fact that with clauses, when pushed down to the package body would eliminate a lot of compilation time. Eventually, when somone figured out the usefulness of subunits, those dependencies were often pushed down to that level. Much of the grumbling about Ada, in those early days, was due to the ignorance about just how it worked. As people discovered how to use it correctly, the programs got better and better. However, a lot of programmer got discouraged because they never learned this lessons. And Ada got a lot of bad press, not because of its own faults, but because of the ignorance of the people trying to use it. Some of this ignorance persists even today. Richard Riehle ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Ripple effect 2006-09-05 2:33 ` Jeffrey R. Carter 2006-09-05 7:23 ` Dmitry A. Kazakov 2006-09-05 16:23 ` Robert A Duff @ 2006-09-05 23:52 ` Randy Brukardt 2 siblings, 0 replies; 26+ messages in thread From: Randy Brukardt @ 2006-09-05 23:52 UTC (permalink / raw) "Jeffrey R. Carter" <spam.not.jrcarter@acm.not.spam.org> wrote in message news:fm5Lg.947292$084.573762@attbi_s22... > It seems awkward. We're working on a project. I create package B, which > has "with A;" on it. I thought B would need it, but I was wrong, and > forgot to remove it. You're developing C and need to use B, so you have > "with B;" on C. Then you realize you need to use A and write some code > that references A. You forget to put "with A;" on C, but it compiles OK > because B references A. Then I clean up B and remove the reference to A > from it. Now C doesn't compile. That seems undesirable. It *is* undesirable. Janus/Ada had a bug like that, and it caused no end of trouble (especially porting code to other compilers, but also with unrelated units suddenly going bad when something is changed). Of course, I recently fixed the bug, and that turned out to be undesirable, too, because a lot of things fail to compile now... Sigh. Randy. ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Ripple effect 2006-09-04 13:52 ` Robert A Duff 2006-09-04 15:15 ` Jeffrey R. Carter @ 2006-09-07 19:09 ` Adam Beneschan 2006-09-07 19:21 ` Ed Falis 1 sibling, 1 reply; 26+ messages in thread From: Adam Beneschan @ 2006-09-07 19:09 UTC (permalink / raw) Robert A Duff wrote: > I believe Tucker coined the term "Ripple Effect", and that one is > supposed to imagine the addition of a with_clause rippling through the > transitive closure of semantic dependences. Also, it's a joke because > Ripple is a wine -- that's the main similarity to Beaujolais Effect. > I've never tasted Ripple, but I think it's considered to be of somewhat > lower quality than Beaujolais. ;-) I think it's considered to be of somewhat lower quality than drinking transmission fluid, but I've never personally tasted it so I don't know. -- Adam ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Ripple effect 2006-09-07 19:09 ` Adam Beneschan @ 2006-09-07 19:21 ` Ed Falis 2006-09-07 19:46 ` Larry Kilgallen 0 siblings, 1 reply; 26+ messages in thread From: Ed Falis @ 2006-09-07 19:21 UTC (permalink / raw) Adam Beneschan wrote: > Robert A Duff wrote: >> Ripple is a wine -- that's the main similarity to Beaujolais Effect. >> I've never tasted Ripple, but I think it's considered to be of > somewhat >> lower quality than Beaujolais. ;-) > > I think it's considered to be of somewhat lower quality than drinking > transmission fluid, but I've never personally tasted it so I don't > know. I have. Your assessment is about right. - Ed ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Ripple effect 2006-09-07 19:21 ` Ed Falis @ 2006-09-07 19:46 ` Larry Kilgallen 2006-09-08 13:06 ` Ed Falis 0 siblings, 1 reply; 26+ messages in thread From: Larry Kilgallen @ 2006-09-07 19:46 UTC (permalink / raw) In article <PM00041CE1FA120255@tilopa.unknown.dom>, Ed Falis <falis@verizon.net> writes: > Adam Beneschan wrote: >> Robert A Duff wrote: >>> Ripple is a wine -- that's the main similarity to Beaujolais Effect. >>> I've never tasted Ripple, but I think it's considered to be of >> somewhat >>> lower quality than Beaujolais. ;-) >> >> I think it's considered to be of somewhat lower quality than drinking >> transmission fluid, but I've never personally tasted it so I don't >> know. > > I have. Your assessment is about right. Wow ! Ed knows what transmission fluid tastes like ! ^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: Ripple effect 2006-09-07 19:46 ` Larry Kilgallen @ 2006-09-08 13:06 ` Ed Falis 0 siblings, 0 replies; 26+ messages in thread From: Ed Falis @ 2006-09-08 13:06 UTC (permalink / raw) Larry Kilgallen wrote: > Wow ! Ed knows what transmission fluid tastes like ! Yes, it's amazing what you can run into doing Ada for 25 years ;-) (actually, I just have an overactive imagination). ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2006-09-09 14:55 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-08-23 22:29 Ripple effect Jeffrey R. Carter 2006-08-24 9:21 ` Maciej Sobczak 2006-08-24 23:39 ` Jeffrey R. Carter 2006-08-25 7:03 ` Maciej Sobczak 2006-08-24 18:22 ` Adam Beneschan 2006-08-24 23:40 ` Jeffrey R. Carter 2006-09-04 13:52 ` Robert A Duff 2006-09-04 15:15 ` Jeffrey R. Carter 2006-09-04 18:06 ` Robert A Duff 2006-09-05 2:33 ` Jeffrey R. Carter 2006-09-05 7:23 ` Dmitry A. Kazakov 2006-09-05 16:28 ` Robert A Duff 2006-09-05 16:23 ` Robert A Duff 2006-09-05 21:36 ` Jeffrey R. Carter 2006-09-07 18:18 ` Robert A Duff 2006-09-08 22:02 ` Jeffrey R. Carter 2006-09-06 0:10 ` Randy Brukardt 2006-09-07 18:30 ` Robert A Duff 2006-09-07 21:21 ` Simon Wright 2006-09-08 2:08 ` Randy Brukardt 2006-09-09 14:55 ` adaworks 2006-09-05 23:52 ` Randy Brukardt 2006-09-07 19:09 ` Adam Beneschan 2006-09-07 19:21 ` Ed Falis 2006-09-07 19:46 ` Larry Kilgallen 2006-09-08 13:06 ` Ed Falis
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox