Re: Ripple effect

[Robert A Duff <bobduff@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?

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