Child Package Operator Visibility

Child Package Operator Visibility

[pakman]

Recently, in the process of illustrating Ada 95 child packages in a course I 
teach, I implemented the Fractions.Comparisons package from N. Cohen's Ada 
as a Second Language, 2nd ed text. In the test program, I withed the 
Fractions and Fractions.Comparisons packages, and then specified the use 
type Fractions.Fraction_Type for direct visibility of the Fractions package 
operators. I was surprised that the Fractions.Comparisons package operators 
were not directly visible (that is, I was not able to test for A < B). To 
make the example work, I added the use Fractions.Comparisons statement.

So, my questions are: 1) Why didn't the use type work for the 
Fractions.Comparisons operators, and 2) how do I make the operators directly 
visible?

While this is an academic exercise, actual projects using this combination 
of parent and child packages have experienced similar problems.

Thanks,
John Cupak 

Re: Child Package Operator Visibility

[(see below)]

On 05/04/2008 15:03, in article
L-udnRBPxNSpGWranZ2dnUVZ_gKdnZ2d@comcast.com, "pakman"
<pakman744@nospam.com> wrote:

> Recently, in the process of illustrating Ada 95 child packages in a course I
> teach, I implemented the Fractions.Comparisons package from N. Cohen's Ada
> as a Second Language, 2nd ed text. In the test program, I withed the
> Fractions and Fractions.Comparisons packages, and then specified the use
> type Fractions.Fraction_Type for direct visibility of the Fractions package
> operators. I was surprised that the Fractions.Comparisons package operators
> were not directly visible (that is, I was not able to test for A < B). To
> make the example work, I added the use Fractions.Comparisons statement.
> 
> So, my questions are: 1) Why didn't the use type work for the
> Fractions.Comparisons operators, and 2) how do I make the operators directly
> visible?

(1) Because the operations in Fractions.Comparisons are not primitive
operations of the fraction type.

(2) Redesign the package structure (abolish Fractions.Comparisons) so that
the comparisons are primitive.

Cohen is illustrating child packages here. The example should not be taken
as a paradigm of good ADT methodology in Ada, because it is far from that.

(Moreover, the comparison algorithm is excessively prone to overflow.)

> 
> While this is an academic exercise, actual projects using this combination
> of parent and child packages have experienced similar problems.

Refactoring needed!

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Child Package Operator Visibility

[Adam Beneschan]

On Apr 5, 7:19 am, "(see below)" <yaldni...@blueyonder.co.uk> wrote:
> On 05/04/2008 15:03, in article
> L-udnRBPxNSpGWranZ2dnUVZ_gKdn...@comcast.com, "pakman"
>
> <pakman...@nospam.com> wrote:
> > Recently, in the process of illustrating Ada 95 child packages in a course I
> > teach, I implemented the Fractions.Comparisons package from N. Cohen's Ada
> > as a Second Language, 2nd ed text. In the test program, I withed the
> > Fractions and Fractions.Comparisons packages, and then specified the use
> > type Fractions.Fraction_Type for direct visibility of the Fractions package
> > operators. I was surprised that the Fractions.Comparisons package operators
> > were not directly visible (that is, I was not able to test for A < B). To
> > make the example work, I added the use Fractions.Comparisons statement.
>
> > So, my questions are: 1) Why didn't the use type work for the
> > Fractions.Comparisons operators, and 2) how do I make the operators directly
> > visible?
>
> (1) Because the operations in Fractions.Comparisons are not primitive
> operations of the fraction type.
>
> (2) Redesign the package structure (abolish Fractions.Comparisons) so that
> the comparisons are primitive.

Or just "use Fractions.Comparisons"?  I don't actually have this book,
so I'm just making a guess as what might work.

In fact, this sort of thing is an idiom I used to use a lot, before
Ada 95 gave us "use type".  I would declare a package with the types I
wanted to declare, and then define a nested package Operators which
redefined all the operator symbols on those types using renaming, so
that another package could say "use Pkg.Operators" without having to
"use Pkg" which would make too much visible.

                               -- Adam

Re: Child Package Operator Visibility

[Anh Vo]

On Apr 7, 8:03 am, Adam Beneschan <a...@irvine.com> wrote:
> On Apr 5, 7:19 am, "(see below)" <yaldni...@blueyonder.co.uk> wrote:
>
> In fact, this sort of thing is an idiom I used to use a lot, before
> Ada 95 gave us "use type".  I would declare a package with the types I
> wanted to declare, and then define a nested package Operators which
> redefined all the operator symbols on those types using renaming, so
> that another package could say "use Pkg.Operators" without having to
> "use Pkg" which would make too much visible.
>
I like your design. It is a very creative idea. This can even be
applied for non-primitive operators.

AV

Re: Child Package Operator Visibility

[(see below)]

On 07/04/2008 16:03, in article
6b08d1d0-1896-4951-8528-e11bef196dd7@1g2000prf.googlegroups.com, "Adam
Beneschan" <adam@irvine.com> wrote:

> On Apr 5, 7:19 am, "(see below)" <yaldni...@blueyonder.co.uk> wrote:
>> On 05/04/2008 15:03, in article
>> L-udnRBPxNSpGWranZ2dnUVZ_gKdn...@comcast.com, "pakman"
>> 
>> <pakman...@nospam.com> wrote:
>>> Recently, in the process of illustrating Ada 95 child packages in a course I
>>> teach, I implemented the Fractions.Comparisons package from N. Cohen's Ada
>>> as a Second Language, 2nd ed text. In the test program, I withed the
>>> Fractions and Fractions.Comparisons packages, and then specified the use
>>> type Fractions.Fraction_Type for direct visibility of the Fractions package
>>> operators. I was surprised that the Fractions.Comparisons package operators
>>> were not directly visible (that is, I was not able to test for A < B). To
>>> make the example work, I added the use Fractions.Comparisons statement.
>> 
>>> So, my questions are: 1) Why didn't the use type work for the
>>> Fractions.Comparisons operators, and 2) how do I make the operators directly
>>> visible?
>> 
>> (1) Because the operations in Fractions.Comparisons are not primitive
>> operations of the fraction type.
>> 
>> (2) Redesign the package structure (abolish Fractions.Comparisons) so that
>> the comparisons are primitive.
> 
> Or just "use Fractions.Comparisons"?  I don't actually have this book,
> so I'm just making a guess as what might work.

That is what the OP seemed to want to avoid, but sure, it's not a big deal.
However, I see no plausible reason for the comparison operations being
segregated from their comparand type in a child package.

As it happens I have a rationals package of my own and it has two children,
but the parent contains all of the type-defining operations.
The children are (a) an I/O package and (b) a combinatorics package.
Neither should be forced on users of the rational arithmetic facilities.
 
> In fact, this sort of thing is an idiom I used to use a lot, before
> Ada 95 gave us "use type".  I would declare a package with the types I
> wanted to declare, and then define a nested package Operators which
> redefined all the operator symbols on those types using renaming, so
> that another package could say "use Pkg.Operators" without having to
> "use Pkg" which would make too much visible.

"use Pkg" really shouldn't do that if Pkg is well designed.
-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk

Re: Child Package Operator Visibility

[Robert A Duff]

Adam Beneschan <adam@irvine.com> writes:

> In fact, this sort of thing is an idiom I used to use a lot, before
> Ada 95 gave us "use type".

Me, too.

>...I would declare a package with the types I
> wanted to declare, and then define a nested package Operators which
> redefined all the operator symbols on those types using renaming, so
> that another package could say "use Pkg.Operators" without having to
> "use Pkg" which would make too much visible.

Nobody would type:

    function "+" (X, Y: T) return T renames Pkg."+";
    function "-" (X, Y: T) return T renames Pkg."-";
    ...

Instead, you type:

    function "+" (X, Y: T) return T renames Pkg."+";

Cut&paste, to get:

    function "+" (X, Y: T) return T renames Pkg."+";
    function "+" (X, Y: T) return T renames Pkg."+";
    ...

Then fix it up:

    function "+" (X, Y: T) return T renames Pkg."+";
    function "-" (X, Y: T) return T renames Pkg."+";
    ...

Oops.  Now you've got a nasty bug, which is hard to see.  ;-)

The problem is that you don't want to "rename" anything -- you want to
import it into a different scope with the _same_ name, and Ada's
renaming declaration is too powerful for that job.

- Bob

Re: Child Package Operator Visibility

[Jean-Pierre Rosen]

Robert A Duff a �crit :

> Nobody would type:
> 
>     function "+" (X, Y: T) return T renames Pkg."+";
>     function "-" (X, Y: T) return T renames Pkg."-";
>     ...
> 
> Instead, you type:
> 
>     function "+" (X, Y: T) return T renames Pkg."+";
> 
> Cut&paste, to get:
> 
>     function "+" (X, Y: T) return T renames Pkg."+";
>     function "+" (X, Y: T) return T renames Pkg."+";
>     ...
> 
> Then fix it up:
> 
>     function "+" (X, Y: T) return T renames Pkg."+";
>     function "-" (X, Y: T) return T renames Pkg."+";
>     ...
> 
> Oops.  Now you've got a nasty bug, which is hard to see.  ;-)
> 
Unless you use AdaControl's rule:
"check declarations (non_identical_renaming)"

(Yes, it's a plug. Sorry, couldn't resist)
-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr