Re: Ripple effect

["Randy Brukardt" <randy@rrsoftware.com>]

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