Ripple effect

Ripple effect

[Jeffrey R. Carter]

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

Re: Ripple effect

[Maciej Sobczak]

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/

Re: Ripple effect

[Adam Beneschan]

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

Re: Ripple effect

[Jeffrey R. Carter]

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

Re: Ripple effect

[Jeffrey R. Carter]

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

Re: Ripple effect

[Maciej Sobczak]

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/

Re: Ripple effect

[Robert A Duff]

"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

Re: Ripple effect

[Jeffrey R. Carter]

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

Re: Ripple effect

[Robert A Duff]

"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

Re: Ripple effect

[Jeffrey R. Carter]

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

Re: Ripple effect

[Dmitry A. Kazakov]

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

Re: Ripple effect

[Robert A Duff]

"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

Re: Ripple effect

[Robert A Duff]

"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

Re: Ripple effect

[Jeffrey R. Carter]

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

Re: Ripple effect

[Randy Brukardt]

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

Re: Ripple effect

[Randy Brukardt]

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

Re: Ripple effect

[Robert A Duff]

"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

Re: Ripple effect

[Robert A Duff]

"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

Re: Ripple effect

[Adam Beneschan]

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

Re: Ripple effect

[Ed Falis]

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

Re: Ripple effect

[Larry Kilgallen]

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 !

Re: Ripple effect

[Simon Wright]

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???)

Re: Ripple effect

[Randy Brukardt]

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

Re: Ripple effect

[Ed Falis]

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

Re: Ripple effect

[Jeffrey R. Carter]

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

Re: Ripple effect

[adaworks]

"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