Re: What is wrong here? (Generic and controlled types)

Re: What is wrong here? (Generic and controlled types)

[Ted Dennison]

In article <38E871E6.8D9EBE71@lufmech.rwth-aachen.de>,
Alexander Boucke <alexb@lufmech.rwth-aachen.de> wrote:
> Hello!
>
> I am writing a vector-package using controlled types.
> I implemented some sort of reference-counting to access
> the arrays. This is why I used the controlled types and
> do not access the arrays directly. A non-generic version
> of the packge is running fine and giving good
> improvements in speed and memory-usage against the
> "trivial" implementation.
>
> While converting the package to be generic I encounter
> an error while compiling my test-program. I must admit,

> 29. package Real_Vectors is new Generic_Vectors(Real, Index, Zero);
> |
> >>> instantiation error at generic_vectors.ads:23
> >>> controlled type must be declared at the library level
> >>> instantiation error at generic_vectors.ads:75
> >>> controlled type must be declared at the library level

:-)

I posted here with almost exactly the same question about 3 months ago.
You can't derive a type from a tagged type at a lower visibility level
than the parent tagged type is declared at. Since controlled types are
tagged and declared directly within a package spec, any types derived
from a controlled type must be declared within a library-level package
spec or body. That means controlled types are not useable if you want to
define your type in a local generic. :-(

The good news is that since this was just a test program, there's a
decent chance you will never again need to instantiate a your generic in
a procedure. If that's the case, just declare a package spec to be the
instantiation of your generic, and you can go on your merry way.

I personally feel Ada really falls on its face here. The only time I
ever felt I needed to create a controlled type was in this context.

--
T.E.D.
http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: What is wrong here? (Generic and controlled types)

[Robert Dewar]

In article <8caebe$6us$1@nnrp1.deja.com>,
  Ted Dennison <dennison@telepath.com> wrote:

> I personally feel Ada really falls on its face here. The only
> time I ever felt I needed to create a controlled type was in
> this context.

It is almost always possible to work around this trivially by
simply including a controlled component in the type instead
of making the entire type controlled.

P.S. it is hard to see how the GNAT message could be any
clearer, suggestions welcome!



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: What is wrong here? (Generic and controlled types)

[Ted Dennison]

In article <8cahmn$apq$1@nnrp1.deja.com>,
Robert Dewar <robert_dewar@my-deja.com> wrote:
> In article <8caebe$6us$1@nnrp1.deja.com>,
> Ted Dennison <dennison@telepath.com> wrote:
>
> > I personally feel Ada really falls on its face here. The only
> > time I ever felt I needed to create a controlled type was in
> > this context.
>
> It is almost always possible to work around this trivially by
> simply including a controlled component in the type instead
> of making the entire type controlled.

You've said this before, and I still don't quite understand what you are
getting at. I see two possibilites. One is that you saying that people
who do this are almost always trying to control fields they don't need
to control. Thus they could just put off the fields they *do* need
to control into some subrecord defined at a higher level. I wouldn't
call that a workaround. That's simply proper design. *Given* that the
design is proper, such a solution will help in exactly %0 of the time
the problem comes up.

The other possibility is that there is some other subfield technique
that I'm missing and can't puzzle out for myself. The only way for a
controlled subrecord to modify its parent record when one of the
controlled operations occurs is for it to have some kind of field that
refers back to the parent record. This requires knowledge of the
structure of that parent record. But such knowledge cannot exist until
that parent record is declared. The definition of the subrecord and/or
the overloading of the controlled operations needs to have visibility to
that parent record. That requires that the controlled subrecord be
declared at a level no higher than the parent record. So now we have the
exact same problem: The subrecord type must be declared at the library
level because its derived from controlled, but it must be declared at a
lower level if the type it refers to is declared at a lower level.

--
T.E.D.
http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: What is wrong here? (Generic and controlled types)

[swhalen]

Robert Dewar <robert_dewar@my-deja.com> wrote:
: It is almost always possible to work around this trivially by
: simply including a controlled component in the type instead
: of making the entire type controlled.

: P.S. it is hard to see how the GNAT message could be any
: clearer, suggestions welcome!


29.    package Real_Vectors is new Generic_Vectors(Real, Index, Zero);
       |
    >>> instantiation error at generic_vectors.ads:23
    >>> controlled type must be declared at the library level
    >>>   (consider including controlled component instead
    >>>    of making entire type controlled?)

I know I'd appreciate getting a helpful hint like this, even
though I have no reason to expect the compiler to do so.

Steve

-- 
{===--------------------------------------------------------------===}
                Steve Whalen     swhalen@netcom.com
{===--------------------------------------------------------------===}

Re: What is wrong here? (Generic and controlled types)

[tmoran]

>AFAIK, the term "library level" is not mentioned in Cohen's book --
>the one I used (at least, it's not listed in the index).
  Of seven Ada 95 books handy on the shelves here, just one (John
English's) has "library level" in the index.
  Perhaps technical terms and phrases in error messages need to
be checked for their presence in books the user is likely to
have at hand.

What is wrong here? (Generic and controlled types)

[Alexander Boucke]

Hello!

I am writing a vector-package using controlled types. 
I implemented some sort of reference-counting to access 
the arrays. This is why I used the controlled types and 
do not access the arrays directly. A non-generic version 
of the packge is running fine and giving good 
improvements in speed and memory-usage against the 
"trivial" implementation. 

While converting the package to be generic I encounter 
an error while compiling my test-program. I must admit, 
that my routine using Ada is not very big yet, so I 
did not find the cause for the error. Here comes a bit 
of code and the error gnat3.12p reports on my HP-UX 10.20:

-----
with Ada.Finalization;
with Unchecked_Deallocation;

generic

   type Real is private;
   type Index is (<>);
   Zero : in Real;

package Generic_Vectors is

   type Vector is new Ada.Finalization.Controlled with private;

private

   Variable_Counter : Natural := 0;
   Object_Counter : Natural := 0;

   type Value_Vector is array (Index range <>) of Real;

   type Handled_Vector(First,Last: Index) is
      record
         Value : Value_Vector(First..Last);
         Count : Natural := 1;
         Object_No : Natural;
      end record;

   type Handled_Vector_Access is access Handled_Vector;

   type Vector is new Ada.Finalization.Controlled with
      record
         Variable_Id : Natural := 0;
         The_Vector : Handled_Vector_Access := null;
      end record;

end Generic_Vectors;
---
In the test-program:

   type Real is digits 10;
   subtype Index is Integer;
   Zero: constant Real := 0.0;

   package Real_Vectors is new Generic_Vectors(Real, Index, Zero);

Of course there are more things around these lines...

gnat reports while compiling:
    29.    package Real_Vectors is new Generic_Vectors(Real, Index, Zero);
           |
        >>> instantiation error at generic_vectors.ads:23
        >>> controlled type must be declared at the library level
        >>> instantiation error at generic_vectors.ads:75
        >>> controlled type must be declared at the library level

Lines 23 and 75 are the lines defining the type Vector.

It would be nice if anybody could point where to find the
solution for doing it right.

Kind regards,

Alexander Boucke
-- 
"I try to write idiot proof code, but they keep making better idiots."

A. Stanley in comp.sys.sgi.admin

Re: What is wrong here? (Generic and controlled types)

[Ehud Lamm]

This really should be in the FAQ

Ehud Lamm mslamm@mscc.huji.ac.il
http://purl.oclc.org/NET/ehudlamm <== My home on the web 
Check it out and subscribe to the E-List- for interesting essays and more!

Re: What is wrong here? (Generic and controlled types)

[Florian Weimer]

Robert Dewar <robert_dewar@my-deja.com> writes:

|    29.    package Real_Vectors is new Generic_Vectors(Real, Index, Zero);
|           |
|        >>> instantiation error at generic_vectors.ads:23
|        >>> controlled type must be declared at the library level
|        >>> instantiation error at generic_vectors.ads:75
|        >>> controlled type must be declared at the library level

> P.S. it is hard to see how the GNAT message could be any
> clearer, suggestions welcome!

I didn't understand this message, either.  AFAIK, the term "library
level" is not mentioned in Cohen's book -- the one I used (at least,
it's not listed in the index).  The RM definition is easy to find, but
it's not very easy to understand (you must already know the concept of
"accessibility level").  Therefore, I think a message like "controlled
type cannot be declared locally" is more helpful, although it gives
less information (it doesn't say explicitly how to correct this error,
but the original message does).

Re: What is wrong here? (Generic and controlled types)

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> P.S. it is hard to see how the GNAT message could be any
> clearer, suggestions welcome!

I'm not sure it's possible -- the accessibility rules seem to be
inherently difficult to understand.  We totally rewrote that section of
the RM several times, and people found it confusing every time.  I think
the terminology we ended up with is just whatever it happened to be when
the RM was done -- if we had had more time, we probably would have
rewritten it again, without improvement.  ;-)

Part of the problem is that people don't think of the main procedure as
being a real procedure -- its stack frame lasts more-or-less forever,
just like library packages (unless you have tasks or a recursive main
procedure, which is unlikely in a simple test program).

But anyway, how about something like this:

     >>> instantiation error at generic_vectors.ads:75
     >>> controlled type must be declared at the library level
     >>> Move instantiation out of procedure Main and into a library package.

- Bob

Re: What is wrong here? (Generic and controlled types)

[Alexander Boucke]

Ted Dennison wrote:
> 
> The good news is that since this was just a test program, there's a
> decent chance you will never again need to instantiate a your generic in
> a procedure. If that's the case, just declare a package spec to be the
> instantiation of your generic, and you can go on your merry way.
> 

You are right, the future use will be inside of other packages... And it
works nicely, I just followed your advice to put the instantiation in a
package spec.

Thanks,

Alexander Boucke

-- 
"I try to write idiot proof code, but they keep making better idiots."

A. Stanley in comp.sys.sgi.admin

Re: What is wrong here? (Generic and controlled types)

[Alexander Boucke]

Florian Weimer wrote:
> 
> Robert Dewar <robert_dewar@my-deja.com> writes:
> 
> |    29.    package Real_Vectors is new Generic_Vectors(Real, Index, Zero);
> |           |
> |        >>> instantiation error at generic_vectors.ads:23
> |        >>> controlled type must be declared at the library level
> |        >>> instantiation error at generic_vectors.ads:75
> |        >>> controlled type must be declared at the library level
> 
> > P.S. it is hard to see how the GNAT message could be any
> > clearer, suggestions welcome!
> 
> I didn't understand this message, either.  AFAIK, the term "library
> level" is not mentioned in Cohen's book -- the one I used (at least,
> it's not listed in the index).  The RM definition is easy to find, but
> it's not very easy to understand (you must already know the concept of
> "accessibility level"). 

This was the same for me (using Barnes/RM). BTW: if the 
f77-Compiler I used before would have put so good (and 
so many) Error-messages... :-) After all, that's one of the reasons to
use Ada now.

Alexander Boucke
-- 
"I try to write idiot proof code, but they keep making better idiots."

A. Stanley in comp.sys.sgi.admin

Re: What is wrong here? (Generic and controlled types)

[Robert Dewar]

In article <873dp3hv8x.fsf@deneb.cygnus.argh.org>,
  Florian Weimer <fw-usenet@deneb.cygnus.argh.org> wrote:
> Robert Dewar <robert_dewar@my-deja.com> writes:
>
> |    29.    package Real_Vectors is new Generic_Vectors(Real,
Index, Zero);
> |           |
> |        >>> instantiation error at generic_vectors.ads:23
> |        >>> controlled type must be declared at the library
level
> |        >>> instantiation error at generic_vectors.ads:75
> |        >>> controlled type must be declared at the library
level
>
> > P.S. it is hard to see how the GNAT message could be any
> > clearer, suggestions welcome!
>
> I didn't understand this message, either.  AFAIK, the term
"library
> level" is not mentioned in Cohen's book -- the one I used (at
least,
> it's not listed in the index).


Actually I think library level is a pretty fundamental concept,
it simply corresponds to the intuitive and informal notion
of global. You certainly do NOT need to understand accessibility
levels to understand this concept, and it is a very basic one.
Odd that Cohen does not mention it, one is always at the mercy
of idiosyncrasies of text books :-)

But you are right, probably the use of the term local or global,
while not so technically accurate would be clearer.

perhaps something like

library (global) level

might get the best of both worlds?


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: What is wrong here? (Generic and controlled types)

[Robert Dewar]

In article <8catei$n8$1@slb6.atl.mindspring.net>,
  swhalen@netcom.com wrote:
> Robert Dewar <robert_dewar@my-deja.com> wrote:
> : It is almost always possible to work around this trivially
by
> : simply including a controlled component in the type instead
> : of making the entire type controlled.
>
> : P.S. it is hard to see how the GNAT message could be any
> : clearer, suggestions welcome!
>
> 29.    package Real_Vectors is new Generic_Vectors(Real,
Index, Zero);
>        |
>     >>> instantiation error at generic_vectors.ads:23
>     >>> controlled type must be declared at the library level
>     >>>   (consider including controlled component instead
>     >>>    of making entire type controlled?)
>
> I know I'd appreciate getting a helpful hint like this, even
> though I have no reason to expect the compiler to do so.


For me that's going too far, since most often the solution is
simply to avoid the nesting that is causing the trouble, and
there are dozens of other possible solutions. TO fix on this
one would be misleading more often than not.

Yes, it would be nice if compilers could help write your
program for you, and they do try to help a bit, but if they
go too far in this direction, they start becoming actively
unhelpful. Finding just the right balance is not always easy.

Generally we avoid programming advice in messages unless it
is VERY likely to be correct, e.g. it is almost certainly
right to suggest adding ALL to make an access type general
when aliased is used incorrectly with a pool specific
access type


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: What is wrong here? (Generic and controlled types)

[Robert Dewar]

In article <wcc7ledkf8j.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:


> But anyway, how about something like this:
>
>      >>> instantiation error at generic_vectors.ads:75
>      >>> controlled type must be declared at the library level
>      >>> Move instantiation out of procedure Main and into a
library package.


Well you saw my reply to the previous suggestion giving quite
different advice. Please consider it copied here.

And indeed the fact that we have two people suggesting different
messages with different advice shows how risky it is for
compilers to get into the advice business :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: What is wrong here? (Generic and controlled types)

[Robert Dewar]

In article <38EC6B3E.9225F1D4@mail.com>,
  Mats Weber <matsw@mail.com> wrote:

> I think the message is misleading (both the actual GNAT
message and the
> above modified version) in the sense that it does not direct
the user to
> the actual rule he is violating, which is that one cannot
derive a
> tagged type at a level deeper than its parent.

Now there (to me) speaks the expert who knows far too much.
An error message that said

"tagged type cannot be derived at a level deeper than its
parent"

would be truly useless to almost all users. Most people don't
even think of controlled types as tagged, and almost no one
understands the concept of "level deeper".

Yes, to the expert, many GNAT error messages are not 100%
technically correct. This is by design. The issue is whether
the message would mislead an expert, and the answer is of
course no, because they understand the underlying reason.

Many compilers to me generate far too much technical term
gobbledygook. Indeed note that the objection that has arisen
to this message is the (to me unanticipated) objection that
library level is an obscure technical term.

I consider this objection valid, and we will think about how
to avoid this mistake.

There may be an argument for making the RM technically precise
and thus much less accessible (even there as you know I am a bit
dubious), but arguing to make error messages more
technically precise at the expense of accessibility would be
a huge mistake I think.

It is interesting to argue about whether an RM reference would
help. The RM reference would indeed be to the section in the
RM talking about rules for deriving tagged types in terms of
accessibility levels.

For putting the RM reference in:

  This helps to explain to an experienced and knolwedgable
  Ada programmer *where* the restriction comes from in the
  language design, but does not help fix the problem.

Against putting the RM reference in:

  There are two kinds of programmers. Some will understand
  the message without the RM reference, and go fix things,
  without bothering to look at the RM. They don't need the
  RM reference!

  The second kind can't understand what the message means
  (note that we had some pretty skilled programmers responding
  in this thread that they were in this class). They will go
  looking up the RM reference hoping it will help them
  understand. The trouble is that this particular RM reference
  is very unlikely to be enlightening (remember we are talking
  about programmers who don't know what library level means).

To me the balance of this argument says don't put in RM
references. I notice that whenever we argue about the RM
reference issue, it is almost always pretty expert programmers
who want those references :-)

But whereever that argument leads, to me the major task is to
improve the quality of the error messages so that *in practice*
more programmers fall into class one.

Robert Dewar



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: What is wrong here? (Generic and controlled types)

[Robert Dewar]

In article <38E9A380.2E850EFC@lufmech.rwth-aachen.de>,
  Alexander Boucke <alexb@lufmech.rwth-aachen.de> wrote:

> You are right, the future use will be inside of other
> packages... And it works nicely, I just followed your advice
> to put the instantiation in a package spec.


So it is surely a good thing that the compiler did not advise
him to use a controlled component, thus sending him off on a
wild goose chase (of course Bob's advice would have been just
right in this case :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: What is wrong here? (Generic and controlled types)

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> It is interesting to argue about whether an RM reference would
> help. The RM reference would indeed be to the section in the
> RM talking about rules for deriving tagged types in terms of
> accessibility levels.

If you were to put in RM references, surely you would refer
to all the relevant paragraphs: the rule about deriving tagged types,
the definition of "library level", and the line of code in package
Finalization that says Controlled is tagged.

Still, I agree that this error message (and probably most error
messages) shouldn't bother with RM references (at least not by default).

I've seen some pretty useless ones.  Eg overload resolution fails to
find a unique interpretation, so it sends you into the bowels of chapter 8.

- Bob

Re: What is wrong here? (Generic and controlled types)

[Robert Dewar]

In article <wccn1n7mbax.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> Robert Dewar <robert_dewar@my-deja.com> writes:
>
> > It is interesting to argue about whether an RM reference
would
> > help. The RM reference would indeed be to the section in the
> > RM talking about rules for deriving tagged types in terms of
> > accessibility levels.
>
> If you were to put in RM references, surely you would refer
> to all the relevant paragraphs

I would mostly react "surely not", one RM reference is dubious,
a whole list of related RM references seems even less likely
to be useful.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: What is wrong here? (Generic and controlled types)

[Mats Weber]

Robert A Duff wrote:

>      >>> instantiation error at generic_vectors.ads:75
>      >>> controlled type must be declared at the library level
>      >>> Move instantiation out of procedure Main and into a library package.

I think the message is misleading (both the actual GNAT message and the
above modified version) in the sense that it does not direct the user to
the actual rule he is violating, which is that one cannot derive a
tagged type at a level deeper than its parent.

Re: What is wrong here? (Generic and controlled types)

[Vincent Marciante]

Robert Dewar <robert_dewar@my-deja.com> writes:

|    29.    package Real_Vectors is new Generic_Vectors(Real, Index,
Zero);
|           |
|        >>> instantiation error at generic_vectors.ads:23
|        >>> controlled type must be declared at the library level
|        >>> instantiation error at generic_vectors.ads:75
|        >>> controlled type must be declared at the library level

> P.S. it is hard to see how the GNAT message could be any
> clearer, suggestions welcome!

   
29.    package Real_Vectors is new Generic_Vectors(Real, Index, Zero);
       |
    >>> instantiation error at generic_vectors.ads:23

    >>> controlled type must be declared in a package
                                         ^^^^^^^^^^^^
    >>> that is a library unit
    ^^^^^^^^^^^^^^^^^^^^^^^^^^         

Both "package" and "library unit" are in the ARM's index.

Re: What is wrong here? (Generic and controlled types)

[Robert Dewar]

In article <38FFFDEE.431A@li.net>,
  Vincent Marciante <marciant@li.net> wrote:
> Robert Dewar <robert_dewar@my-deja.com> writes:
>
> |    29.    package Real_Vectors is new Generic_Vectors(Real,
Index,
> Zero);
> |           |
> |        >>> instantiation error at generic_vectors.ads:23
> |        >>> controlled type must be declared at the library
level
> |        >>> instantiation error at generic_vectors.ads:75
> |        >>> controlled type must be declared at the library
level
>
> > P.S. it is hard to see how the GNAT message could be any
> > clearer, suggestions welcome!
>
> 29.    package Real_Vectors is new Generic_Vectors(Real,
Index, Zero);
>        |
>     >>> instantiation error at generic_vectors.ads:23
>
>     >>> controlled type must be declared in a package
>                                          ^^^^^^^^^^^^
>     >>> that is a library unit
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Both "package" and "library unit" are in the ARM's index.


Well so is "library level", and if we are going to use technical
terms in the error messages we might as well use them
accurately. A library level package is definitely NOT the same
thing as a package that is a library unit, so your replacement
is inaccurate.

I don't mind considering replacing the formal correct existing
message with an informal message that might not be quite as
correct but is more informative, but surely it is not a good
idea to replace it with a message using formal terms that is
just wrong :-)

The fact that something is in the index of the RM is really
not good enough for two reasons:

1. There is no reason to expect beginning programmers to have
the RM, and indeed every reason to expect them NOT to have it.

2. If they do have it, sending them off to the index of this
document is often not likely to be as helpful as you think.

But you can see the bind of choosing such messages, I suggested
that the very familiar term "global" might be better, but
Florian thinks that is equally obscure.

Probably for really difficult messages like this you want an
auxiliary wizard that can provide additional information at an
appropriate level of sophistication -- we have envisioned such
a tool for some time. I even have had a name for it which I
thought up 8 years ago, GNOME - GNAT On-line Message Explainer.
Of course we delayed too long implementing it, and now we can't
use that name, so now we don't even have a name :-(


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: What is wrong here? (Generic and controlled types)

[Robert Dewar]

One more thought: In practice CLA itself is not such a bad
GNOME ("GNAT online message explainer"). We may not feel like
doing students homework for them, but as a group we are quite
happy to answer questions about specific error messages people
don't like, and indeed the thread that such questions generate
can be quite instructive :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: What is wrong here? (Generic and controlled types)

[Florian Weimer]

Robert Dewar <robert_dewar@my-deja.com> writes:

> But you are right, probably the use of the term local or global,
> while not so technically accurate would be clearer.
> 
> perhaps something like
> 
> library (global) level
> 
> might get the best of both worlds?

Maybe "global" isn't as helpful as it could be, I'm afraid.  When you
have no idea about "library level", you probably don't know that a
declaration at library level is more "global" than one in the main
subprogram, either.

Perhaps "outmost package" instead of "global" is better?

Re: What is wrong here? (Generic and controlled types)

[Vincent Marciante]

Robert Dewar wrote:
> 

<snip>

> >
> > Both "package" and "library unit" are in the ARM's index.
> 
> Well so is "library level", 

Sorry, must have been awake too long. 

> and if we are going to use technical
> terms in the error messages we might as well use them
> accurately. A library level package is definitely NOT the same
> thing as a package that is a library unit, so your replacement
> is inaccurate.

I guess I need to correct my understanding of the term.
Where (in addition to the ARM) is there an expanded 
description of this? 

I just searched deja and found the reference to 
John English's book.  I'll find and check it first.  
(I guess that I remembered that "library level" was not in the 
index of many Ada books from this discussion but mistakenly 
"remembered" that the ARM was mentioned :(

Re: What is wrong here? (Generic and controlled types)

[Robert Dewar]

In article <39013702.6063@li.net>,
  Vincent Marciante <marciant@li.net> wrote:
> Robert Dewar wrote:
> > A library level package is definitely NOT the
> > same thing as a package that is a library unit, so your
> > replacement is inaccurate.
>
> I guess I need to correct my understanding of the term.
> Where (in addition to the ARM) is there an expanded
> description of this?

No idea :-) and the RM definition is indeed difficult. Just
to set your thinking in the right direction: a package nested
inside a library unit package is not itself a library unit,
but it is a library level package.



Sent via Deja.com http://www.deja.com/
Before you buy.