Re: advice on package design

[Robert A Duff <bobduff@shell01.TheWorld.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On 12 Mar 2005 16:59:26 -0500, Robert A Duff wrote:
> 
> > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> > 
> >> On 12 Mar 2005 14:57:17 -0500, Robert A Duff wrote:
> >> 
> >>> If I were [re]designing Ada, I would make 'use' transitive. That is,
> >>> if Foo says "use Linked_List" that would make the contents of
> >>> Linked_List directly visible in Foo, and anything that says "use Foo;"
> >>> would have direct visibility on everything directly visible in Foo --
> >>> not just the things *declared* in Foo.  Or something like that.
> >> 
> >> Yes, I really miss it. What about:
> >> 
> >>    use all <package-name>;
> >> 
> >> or
> >> 
> >>   use package <package-name>;
> >> 
> >> with the effect importing the specification of the package? Also,
> >> differently to use, it should prevent hiding. So:
> >> 
> >> package A is
> >>    Foo (X : Integer);
> >> end A;
> >> 
> >> with A;
> >> package B is
> >>    use all A;
> >>    Foo (X : out Integer); -- Illegal, can't hide A.Foo
> >> end B;
> > 
> > Well, I happen to think that *all* hiding is evil.
> > I would make the above legal, but all calls to Foo would be ambiguous,
> > and therefore illegal.
> 
> That makes sense, but it might be difficult for the programmer to resolve
> the problem. Somewhere in 20th child package of B he calls Foo and, oops,
> it is ambiguous. I think it is better to keep all scopes clean from the
> beginning.

I see your point, but I think that can be dealt with by having good
error messages.  In any language that allows overloading, there are
going to potential ambiguities, and when they happen, I expect more from
the compiler than just "error: I'm confused".

In Ada, if you have:

procedure Foo(X: Integer);
procedure Foo(Y: Integer);

in the same package, it's illegal.  But if they're in two different
packages, both use-visible, then it's legal, and you can call them
using named notation: Foo(X => 1) vs. Foo(Y => 1).  That seems odd
to me.  Should that use clause be illegal?

I would prefer to allow declaring of anything, but then declare
potentially-confusing uses ambiguous.  And don't make the
overload-resolution rules too "smart", so they make many things
ambiguous (and therefore illegal).  And rely on compilers to give useful
error messages for ambiguity.

That seems better than trying to prevent possibly-ambiguous things ahead
of time, at the declaration points.

> > Ichbiah defined "Beaujolais Effect" to mean that if you add a subprogram
> > to a use-d package, and that causes a legal program to change it's
> > meaning (to another legal program) you have a Beaujolais Effect.
> > And Beaujolais Effects are bad.  Ada 83 had some Beaujolais Effects,
> > but they were pretty obscure, and we eliminated them in Ada 95.
> > 
> > But I think he should have extended that definition to include all
> > visibility, not just use-visibility.  So a local X should not hide a
> > use-visible X, but be ambiguous with it.
> 
> Yes. Even in the cases like:
> 
> declare
>    I : Integer;
> begin
>    for I in A'Range loop
>       A (I) := 0;
>    end loop;

Yes, I agree.

> However I'd like to get error message one line above than you.

OK, but I'm willing to trust the compiler to do that (i.e. say,
"I" is ambiguous here, because one-line-above you have an I that
conflicts with the I three-lines-above).

> > And similar rules for record
> > (extension) components.
> 
> I think that this case is not so simple. IMO record components should be
> treated as primitive operations (getter/setter pair). As such they could be
> overridden upon extension. At the same time some of the components might be
> declared as a kind of "class-wide". For these the rules preventing hiding
> should apply.
> 
> > In Pascal, a 'with' statement opens up the visibility of the record
> > components, and if 'with R' is nested within some place where X is
> > declared, then record component X hides that X.  That's bad, and Ichbiah
> > wisely designed 'use' clauses to not do that bad thing.  The trick is to
> > avoid "preference rules", where one decl takes precedence over another.
> > But hiding is exactly a preference rule (preferring the inner one over
> > an outer one, or preferring an outer one over a use-visible one).
> 
> Alas, but preference rules cannot be avoided. Overriding is just that
> preference.

I don't see why.  Overriding is different -- the old thing goes away.
It's explicit, so it's OK.  If we had this language:

declare
   I : Integer;
begin
   hide I;     <<<<<<<<<<<<<<<<<<<<<<<<
   for I in A'Range loop
      A (I) := 0;
   end loop;

then the hiding would be OK, IMHO.

- Bob