Bases for the Design of a Standard Container Library for Ada

Bases for the Design of a Standard Container Library for Ada

[Mário Amado Alves]

I'm submiting this document to the Ada community as a request for
comments:

  BASES FOR THE DESIGN OF A STANDARD CONTAINER LIBRARY FOR ADA

  ... an attempt to put together a complete,
  consistent, and correct set of bases for the design of a
  standard container library for Ada.

Please find the full 130 paragraph long document in

  http://www.liacc.up.pt/~maa/bases_1.txt
  (public access)

or in

  http://groups.yahoo.com/group/asclwg/files/Bases
  (might require Yahoo! login)

The document includes a Bibliography, and instructions on how to
convey specific comments. Of course general comments are welcome as
immediate replies right here.

Thanks a lot,
--MAA

Re: Bases for the Design of a Standard Container Library for Ada

[Warren W. Gay VE3WWG]

M�rio Amado Alves wrote:
> I'm submiting this document to the Ada community as a request for
> comments:
> 
>   BASES FOR THE DESIGN OF A STANDARD CONTAINER LIBRARY FOR ADA

You may want to fix the spelling error: "basIS" vs your "basES".
This error is propagated everywhere you use the word.

>   ... an attempt to put together a complete,
>   consistent, and correct set of bases for the design of a
>   standard container library for Ada.
> 
> Please find the full 130 paragraph long document in
> 
>   http://www.liacc.up.pt/~maa/bases_1.txt
>   (public access)
> 
> or in
> 
>   http://groups.yahoo.com/group/asclwg/files/Bases
>   (might require Yahoo! login)
> 
> The document includes a Bibliography, and instructions on how to
> convey specific comments. Of course general comments are welcome as
> immediate replies right here.
> 
> Thanks a lot,
> --MAA

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Bases for the Design of a Standard Container Library for Ada

[David C. Hoos]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
news:Jbs5b.2317$I_2.362367@news20.bellglobal.com...
> M�rio Amado Alves wrote:
> > I'm submiting this document to the Ada community as a request for
> > comments:
> >
> >   BASES FOR THE DESIGN OF A STANDARD CONTAINER LIBRARY FOR ADA
>
> You may want to fix the spelling error: "basIS" vs your "basES".
> This error is propagated everywhere you use the word.

Perhaps the author intended the plural of "basis,"  which is "bases."

David Hoos, W1DCH

<snip>

Re: Bases for the Design of a Standard Container Library for Ada

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1917 bytes --]

"M�rio Amado Alves" <maa@liacc.up.pt> wrote in message
news:4a4de33a.0309021059.53f71234@posting.google.com...
> I'm submiting this document to the Ada community as a request for
> comments:
>
>   BASES FOR THE DESIGN OF A STANDARD CONTAINER LIBRARY FOR ADA

What's missing in this document is a discussion of what the library is
trying to accomplish. You really have to have that before you can even talk
about other requirements.

If I was writing such a purpose statement, I would come up with something
like:

"The library is intended to provide a standard set of building blocks to
make it easier and faster to create the non-critical parts of applications."

Once a purpose statement is agreed to, you can evaluate technical
requirements based on it. For instance, my purpose statement would allow
drawing the following conclusions:
    -- Ease of use is paramount. There should be as few instantiations and
other complications as possible. (Ideally, exactly one, simple
instantiation.)
    -- "Non-critical" means that multiple versions of a component tailored
for specific patterns of use are not needed. When performance is critical,
the standard library is not intended to be used. (Build your own data
structures.) Note, however, that performance is rarely critical, so this
won't make much difference in practice.
    -- Similarly, concurrency protection isn't needed. (But any standard
library in Ada has to work from multiple tasks as long as the objects are
disjoint.)

And so on. I don't want to impose my statement on the process; it's just an
example. But I think we need such a statement with some level of agreement
before anything else can be (or should be) said.

(We do have to be careful of trying to make the standard library all things
to all people. That isn't possible, and we shouldn't be encapsulating a load
of complexity for that.)

                            Randy Brukardt.

Re: Bases for the Design of a Standard Container Library for Ada

[Mário Amado Alves]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message news:<vld85u3hhifved@corp.supernews.com>...
> What's missing in this document is a discussion of what the library is
> trying to accomplish. You really have to have that before you can even talk
> about other requirements.
> ...

The document rests on the assumption that the general concept of a
standard container library for Ada is well understood. But a short
explicitation wouldn't hurt I guess. Make the document selfsufficient.
Thanks for your text. The "body of knowledge" already contains many
statements of need and high level requirements (including now your
message). The work plan includes adding such statments to it. I was
thinking of doing that focusedly i.e. attaching them as rationalia to
each of the design decisions which are the main items of the document.
This sounds like working backwards, but actually the design items were
made with the requirements in mind. The requirements were not
explicitly expressed in the document yet simply because lack of time I
guess.

The Bases body of knowledge is an informal account of the collective
mind. Actually what matters is the collective mind. My hope is this
mind will look at the Bases and find most of their requirements
honored there.

Time is an issue here because the Ada 2005 process includes really
near deadlines now. Particularly, the first deadline for the standard
container library proposal is the end of this monht (September 2003).
That deadline has something to do with AI302, I'm not sure what and
how exactly, and how exactly the Bases relate to the AI302
processwise, and in fact I'm hoping people more knowledgeable of this
here on CLA will help here.

Re: Bases for the Design of a Standard Container Library for Ada

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1705 bytes --]

"M�rio Amado Alves" <maa@liacc.up.pt> wrote in message
news:4a4de33a.0309040356.6706bdc4@posting.google.com...
...
> Time is an issue here because the Ada 2005 process includes really
> near deadlines now. Particularly, the first deadline for the standard
> container library proposal is the end of this monht (September 2003).
> That deadline has something to do with AI302, I'm not sure what and
> how exactly, and how exactly the Bases relate to the AI302
> processwise, and in fact I'm hoping people more knowledgeable of this
> here on CLA will help here.

To clarify this:
   The end of September deadline is for the submission of issues/proposals
from "non-invited" groups. (That is, the general public.) The basic idea is
to stop looking at new ideas at that point and start deciding on exactly
what will be in the Amendment.

    There is a secondary deadline of the end of December for "invited"
groups -- which means all proposals need to be submitted by then, or there
is little chance that they would be included in Ada 200Y. That even includes
Tucker. :-)

   The basic reason for the deadlines is the need to cut off input so that
we can really finish a document in the intended timetable. If we got input
forever, we'd never really have a chance to finish.

   In any case, which deadline a particular proposal falls under depends on
whether prior arrangements have been made with the ARG. AI-302-01 (Jeffrey
Carter's proposal) is essentially complete, so it is obviously on time. (I
still have a lot of editing to do on it, but that is not Jeff's fault.) But
(complete) alternative proposals would need to be submitted before the
appropriate deadline.

                    Randy.

Re: Bases for the Design of a Standard Container Library for Ada

[Matthew Heaney]

"Randy Brukardt" <randy@rrsoftware.com> writes:

>    In any case, which deadline a particular proposal falls under depends on
> whether prior arrangements have been made with the ARG. AI-302-01 (Jeffrey
> Carter's proposal) is essentially complete, so it is obviously on time. (I
> still have a lot of editing to do on it, but that is not Jeff's fault.) But
> (complete) alternative proposals would need to be submitted before the
> appropriate deadline.

The ASCLWG proposal will definitely be submitted this month -- it should
be finished in a couple of weeks.

The proposal is based on the Charles algorithms and container library,
which is available from my home page.

<http://home.earthlink.net/~matthewjheaney/charles/index.html>

Re: Bases for the Design of a Standard Container Library for Ada

[Amado Alves]

Randy wrote:
   "The end of September deadline is for the submission of issues/proposals
from "non-invited" groups. (That is, the general public.)"
Through what channel, please? An email address would be the best I guess.

    "There is a secondary deadline of the end of December for "invited"
groups -- which means all proposals need to be submitted by then"
Same channel?
   "In any case, which deadline a particular proposal falls under depends on
whether prior arrangements have been made with the ARG."
Is there still time to make these arragements? Same channel?
Thanks a lot. These are roadmap questions. Sorry if I seem to be the only
one lost in this territory.
--MAA

Re: Bases for the Design of a Standard Container Library for Ada

[Randy Brukardt]

"Amado Alves" <maa@liacc.up.pt> wrote in message
news:bj9shb$qeq$1@news.up.pt...
> Randy wrote:
>    "The end of September deadline is for the submission of
issues/proposals
> from "non-invited" groups. (That is, the general public.)"
> Through what channel, please? An email address would be the best I guess.

Submissions ought to be sent to the Ada-Comment mailing list (like all
questions/comments on the standard). The address is
ada-comment@ada-auth.org. The list is open to the public; if you make a
submission, you ought to join the list; see
http://www.adaic.org/standards/articles/comment.html for details.

                 Randy.

Re: Bases for the Design of a Standard Container Library for Ada

[Martin Krischik]

Matthew Heaney wrote:

> The proposal is based on the Charles algorithms and container library,
> which is available from my home page.
 
> <http://home.earthlink.net/~matthewjheaney/charles/index.html>

You think you will be successfull with your proposal?

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Bases for the Design of a Standard Container Library for Ada

[Matthew Heaney]

Martin Krischik <krischik@users.sourceforge.net> writes:

> Matthew Heaney wrote:
> 
> > The proposal is based on the Charles algorithms and container library,
> > which is available from my home page.
>  
> > <http://home.earthlink.net/~matthewjheaney/charles/index.html>
> 
> You think you will be successfull with your proposal?

Well, I don't know -- it's up the the ARG.  I hope so.  I think Charles
is at the right level of abstraction, and satisfies the goals that a
library should be safe, easy-to-use, flexible, and efficient.

One thing Charles has going for it is that it's modeled on the C++ STL,
which has emerged as the defacto standard by which other libraries are
measured.  The STL is a very, very good container library, and there is
absolutely no reason why the STL can't be written in Ada95.

Realize of course that even though Charles is modeled on the STL, it is
not a literal translation of the C++ version.  Charles is first and
foremost an Ada library.

Re: Bases for the Design of a Standard Container Library for Ada

[Mário Amado Alves]

> I think Charles ... satisfies the goals that a
> library should be safe, easy-to-use, flexible, and efficient.

Great summary of top level requirements. However I have my
reservations about the easiness-of-use of Charles. Specs too long.
I'll try to evolve this critique soon. Obviously it is linked to the
small specs requirement proposed before.

Bases 1.57

[Martin Krischik]

57   The container type shall not be tagged.

This will prevent users from expanding the container. I have made good
experiences with specialized containers derived from a standart container
library. Doing that with a "has a" relation ship is far harder.

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Bases 1.58

[Martin Krischik]

<verï¿œffentlicht & per Mail versendet>

58   The container type shall not be visibly controlled.

All containers need to be controlled. Doing that privatly will prevent users
from extending the container. So I have the same reservations as in 57.

Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Bases 1.52

[Martin Krischik]

Bases 1.52

51   This parameter shall have the signature
       type Element (<>) is private;

Why restrict to just one signature?

I have made very good experiences with containers based on:

   type Item (<>) is abstract tagged private;

This frees my applications from using heap memory when I need to store
Item'Class instances.

Well of course, heap memory is then used inside the container. But there its
use is localized there and far easier to manage.

For examples see:

http://adacl.sourceforge.net/html/files/B.htm

especialy:

http://adacl.sourceforge.net/html/______Include__bc-support-tagged_reference__ads.htm
http://adacl.sourceforge.net/html/______Include__bc-support-tagged_reference__adb.htm

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Bases 1.52

[Mário Amado Alves]

Martin Krischik wrote:
> Bases 1.52
> 
> 51   This parameter shall have the signature
>        type Element (<>) is private;
> 
> Why restrict to just one signature?
> 
> I have made very good experiences with containers based on:
> 
>    type Item (<>) is abstract tagged private;
> 
> This frees my applications from using heap memory when I need to store
> Item'Class instances....

I'm not sure about the memory management implications, but doesn't the
first signature include the second, in the sense that it accepts
tagged actuals?

Restricting to just one signature is simply to keep the library small.

Re: Bases 1.52

[Martin Krischik]

Mï¿œrio Amado Alves wrote:

> Martin Krischik wrote:
>> Bases 1.52
>> 
>> 51   This parameter shall have the signature
>>        type Element (<>) is private;
>> 
>> Why restrict to just one signature?
>> 
>> I have made very good experiences with containers based on:
>> 
>>    type Item (<>) is abstract tagged private;
>> 
>> This frees my applications from using heap memory when I need to store
>> Item'Class instances....
> 
> I'm not sure about the memory management implications, but doesn't the
> first signature include the second, in the sense that it accepts
> tagged actuals?

Yes, but to my knowlege you cant say:

type Item'Class is private;
 
so I use:

generic

    type Element(<>) is abstract tagged private;

    --  Pointer to be used
    type P is access T'Class;

package
    BC.Support.Tagged_Reference
is

    function Create (
        Value : T'Class)
    return
        Pointer;

Function Create uses T'Class - that is an kind of class. As for the memory
management implications, Ada - unline C++, allows:

    function Create (
        Value : T'Class)
    return
        Pointer
    is
    begin
        return Pointer'(Ada.Finalization.Controlled with
                    Value  => new T'Class'(Value));
    end Create;

No T::clone () needed.

> Restricting to just one signature is simply to keep the library small.

Shure, but one often likes to store Strings or a decendant of a tagged type.
With Strings one can use Unbounded_Strings but with tagged type on is lost.

Besides, Sun did not keep the Java Library small. In fact the Java Library
is huge. And Java is more successfull.

Or Python. The Python Library is huge and there are 2641 python project on
source forge and ony 67 Ada projects. 

And creating additional collection class from one which allready exists is
not that difficult. In fact is is so easy that I create them with a text
search and replace tool.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Bases 1.52

[Mário Amado Alves]

(I'm sorry if my replies are so delayed. Currently I have no news
server except Google.)

Martin Krischik <krischik@users.sourceforge.net> wrote in message news:<1301057.xhkpTmYQhd@linux1.krischik.com>...
> M�rio Amado Alves wrote:
> 
> > Martin Krischik wrote:
> >> 51   This parameter shall have the signature
> >>        type Element (<>) is private;
> >> 
> >> Why restrict to just one signature?
> >> 
> >> I have made very good experiences with containers based on:
> >> 
> >>    type Item (<>) is abstract tagged private;
> >> 
> >> This frees my applications from using heap memory when I need to store
> >> Item'Class instances....
> > 
> > I'm not sure about the memory management implications, but doesn't the
> > first signature include the second, in the sense that it accepts
> > tagged actuals?
> 
> Yes, but to my knowlege you cant say:
> 
> type Item'Class is private;

I don't follow. Do you mean the formal in 1.51 does not accept a class
wide actual? But it does.

But you're right in that the formal in 1.51 does not accept abstract
actuals. However I'm not sure about the usefulness--or even
legality--of a container of abstract elements. Note the Bases requires
"value semantics". Abstract types don't have values.

>...
> > Restricting to just one signature is simply to keep the library small.
> 
> Shure, but one often likes to store Strings or a decendant of a tagged type.
> With Strings one can use Unbounded_Strings but with tagged type on is lost.

Sorry, I don't see the problem.

> Besides, Sun did not keep the Java Library small. In fact the Java Library
> is huge. And Java is more successfull.
> 
> Or Python. The Python Library is huge and there are 2641 python project on
> source forge and ony 67 Ada projects. 

Do you mean the *containers* library?

Anyway, I think I'm ok with reformulating requirement 1.51 to just
"the library shall support containers of indefinite elements." This
covers class wide, and leaves open the decision for abstracts. However
we should check in the body of knowledge (or right here and now) if
there is consensus.

As for the library size, the tendency is to recommend a maximum of 50
lines per package spec. And the Bases requires Vectors, Lists and
Tables (maps), but leaves open the inclusion of others.

BTW, Bases 2 has been submited to the ARG.

Re: Bases 1.52

[Martin Dowie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 506 bytes --]

"M�rio Amado Alves" <amado.alves@netcabo.pt> wrote in message > As for the
library size, the tendency is to
> recommend a maximum of 50
> lines per package spec. And the Bases requires Vectors, Lists and
> Tables (maps), but leaves open the inclusion of others.

I don't really see the point of such a recommendation - the
size of an spec is the size the problem demands. Ada.Strings.
Unbounded is >200 lines (after stripping comments and
context clauses) - because that's what the problem requires.

maximum number of lines per spec (was: Bases 1.52)

[Mário Amado Alves]

> > ... maximum of 50 lines per package spec... (Marius)
> I don't really see the point of such a recommendation - the
> size of an spec is the size the problem demands. Ada.Strings.
> Unbounded is >200 lines (after stripping comments and
> context clauses) - because that's what the problem requires.

You're right in principle of course, but the problem is that the
problem is not perfectly defined a priori in the case of containers
i.e. the range of possible extensions of the problem is still wide and
saying 50 lines is one way of focusing on one region of that range.

Ada.String.Unbounded is so big because of all the (a) combinations
with String and Character for construction and conversion, and (b)
pairs procedure/function for the same operation.  In the case of a
generic container package (a) is reduced if not eliminated.  And (b)
is not essential, and can be rethinked considering other forces at
play (including desired sizes).

All existing generic container packages have an essential signature
that fits well within 50 lines.

Anyway you're right if you permit the future standard to be any number
of pages long. Just note there might be objections to this from the
educational world at least. I for one.

Another force at play here is the general proposal to have a *minimal*
standard and a *big* Conventional Ada Library (outside the standard
but supported by a strong coalition of users and compiler vendors).

Re: maximum number of lines per spec (was: Bases 1.52)

[Marin David Condic]

I generally don't like arbitrary length constraints, but if you have to 
have one, why not aim for something a little more "functional" rather 
than number of lines? Say that a spec should not include more than a 
dozen types or two dozen subprograms as a goal - and overshooting the 
goal only means review & justification?

MDC


M�rio Amado Alves wrote:

> 
> 
> You're right in principle of course, but the problem is that the
> problem is not perfectly defined a priori in the case of containers
> i.e. the range of possible extensions of the problem is still wide and
> saying 50 lines is one way of focusing on one region of that range.
> 
> Ada.String.Unbounded is so big because of all the (a) combinations
> with String and Character for construction and conversion, and (b)
> pairs procedure/function for the same operation.  In the case of a
> generic container package (a) is reduced if not eliminated.  And (b)
> is not essential, and can be rethinked considering other forces at
> play (including desired sizes).
> 
> All existing generic container packages have an essential signature
> that fits well within 50 lines.
> 
> Anyway you're right if you permit the future standard to be any number
> of pages long. Just note there might be objections to this from the
> educational world at least. I for one.
> 
> Another force at play here is the general proposal to have a *minimal*
> standard and a *big* Conventional Ada Library (outside the standard
> but supported by a strong coalition of users and compiler vendors).


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jast.mil/

Send Replies To: m c o n d i c @ a c m . o r g

     "In general the art of government consists in taking as
     much money as possible from one class of citizens to give
     to the other."

         --  Voltaire
======================================================================

Re: Bases 1.52

[Martin Krischik]

Mï¿œrio Amado Alves wrote:

> But you're right in that the formal in 1.51 does not accept abstract
> actuals. However I'm not sure about the usefulness--or even
> legality--of a container of abstract elements. Note the Bases requires
> "value semantics". Abstract types don't have values.

But there child classes have. Nobody just defines an abstract type for the
sake of it. They are allways defined to be derived by concred types. And
they have values which one might like to store inside a container.

>> Besides, Sun did not keep the Java Library small. In fact the Java
>> Library is huge. And Java is more successfull.
>> 
>> Or Python. The Python Library is huge and there are 2641 python project
>> on source forge and ony 67 Ada projects.
> 
> Do you mean the *containers* library?

No. I want to point out that the success of a language depends (partly) on
the size of its standart library.
 
There is a good Article here:

Re: How to get a ￜConventional Ada Libraryￜ (Was: Ideas for Ada 200X)
Von: Marin David Condic <nobody@noplace.com>
Message-ID: <3F61C185.4020005@noplace.com>

Actualy I would advovate a "reference implementation" instead of just a
description of how the library should be done. Sun did it for the java lib
and was successful in doing so.

> As for the library size, the tendency is to recommend a maximum of 50
> lines per package spec. And the Bases requires Vectors, Lists and
> Tables (maps), but leaves open the inclusion of others.

Ok. It is just that I think of a library as a collection of packages. I am
advocation more packages not larger once.

I would like to invite you to read my "containers and garbage collections."
artivle as well.

With Regards

Martin.

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Bases 1.52

[Matthew Heaney]

Martin Krischik <krischik@users.sourceforge.net> writes:

> Yes, but to my knowlege you cant say:
> 
> type Item'Class is private;

This is all wrong.  If you have this generic formal type:

generic
   type T (<>) is private;
package GP is ...;

and this actual type:

package Q is
   type T is tagged private;
...
end Q;

Then you can instantiate the generic package like this:

package P is new GP (Q.T'Class);

The type T'Class is a real type.  It has a funny spelling, but it's a
real type.

You can declare objects of that type, both on the stack, like this:

  O : T'Class := ...;

and on the heap, like this:

  O : T_Class_Access := new T'Class'(Item);

You can write subprogram parameters --including function return types--
with that type.

And you can use T'Class as the generic actual type in a generic
instantiation.

Re: Bases 1.52

[Martin Krischik]

Matthew Heaney wrote:

> Martin Krischik <krischik@users.sourceforge.net> writes:
 
>> Yes, but to my knowlege you cant say:
 
>> type Item'Class is private;
 
> The type T'Class is a real type.  It has a funny spelling, but it's a
> real type.

Interesting. I will try your examples.

Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Bases 1.52

[Robert I. Eachus]

Matthew Heaney wrote:

 > The type T'Class is a real type.  It has a funny spelling, but it's a
 >  real type.
 >
 > You can declare objects of that type, both on the stack, like this:

But like unbounded string types, or a discriminated record type without
a default value for the discriminant, you must provide an initial value 
for any objects of type T'Class you declare.  (Matt's examples showed 
this.) It would be nice in Ada 200Y to add a short technical term to 
describe these types of types.

-- 
                                           Robert I. Eachus

"As far as I'm concerned, war always means failure." -- Jacques Chirac,
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: Bases 1.52

[Nick Roberts]

"Robert I. Eachus" <rieachus@attbi.com> wrote in message
news:3F64B1B3.2070305@attbi.com...

> But like unbounded string types, or a discriminated record
> type without a default value for the discriminant, you must
> provide an initial value

An initial value is not required for an object of type
Ada.Strings.Unbounded.Unbounded_String. It is initialised by default to an
empty string [RM95 A.4.5.(73)]. I guess you meant "... like objects declared
as being of an unconstrained subtype with no constraint, such as 'String',
or of a discriminated record subtype which does not have default expressions
for the discriminants and with no constraint, ...".

> for any objects of type T'Class you declare.  (Matt's
> examples showed  this.) It would be nice in Ada 200Y
> to add a short technical term to describe these types
> of types.

Do you mean other than the term "indefinite"? [RM95 3.3(23), 3.7(26)]

--
Nick Roberts
Jabber: debater@charente.de [ICQ: 159718630]

Re: Bases 1.52

[Robert I. Eachus]

Nick Roberts wrote:
> "Robert I. Eachus" <rieachus@attbi.com> wrote in message
> news:3F64B1B3.2070305@attbi.com...
> 
> 
>>But like unbounded string types, or a discriminated record
>>type without a default value for the discriminant, you must
>>provide an initial value
> 
> 
> An initial value is not required for an object of type
> Ada.Strings.Unbounded.Unbounded_String. It is initialised by default to an
> empty string [RM95 A.4.5.(73)]. I guess you meant "... like objects declared
> as being of an unconstrained subtype with no constraint, such as 'String',
> or of a discriminated record subtype which does not have default expressions
> for the discriminants and with no constraint, ...".

That is why I said unbounded string types--all lower case--not type 
Unbounded_String.  But I did make a mistake, I really meant to write 
unbounded array types, which is a lot clearer.


> Do you mean other than the term "indefinite"? [RM95 3.3(23), 3.7(26)]

Yes.  But it is really hard to express what I meant.  There are types 
whose subtype is indefinite, where you can either add a constraint when 
declaring an object, or provide an initial value.  But there are also 
indefinite types where you cannot provide a constraint, and must provide 
an initial value.  These are currently "types with unknown 
discriminants" all types with unknown discriminants are indefinite, but 
not all indefinite subtypes are types with unknown discriminants.

I think in one ARG discussion we called these types "really indefinite 
types" and in another discussion "initial value only types" but neither 
of those names is much shorter than "types with unknown discriminants." 
  (Notice that classwide types are not really types with unknown 
discriminants, but 3.3(29) defines them to be.)

This may seem to be much ado about nothing, but these types are those 
that cannot be subcomponents, so it is a pretty important group.

-- 
"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh

Re: Bases 1.52

[Matthew Heaney]

Martin Krischik <krischik@users.sourceforge.net> writes:

> Bases 1.52
> 
> 51   This parameter shall have the signature
>        type Element (<>) is private;
> 
> Why restrict to just one signature?
> 
> I have made very good experiences with containers based on:
> 
>    type Item (<>) is abstract tagged private;

This actual type will match the generic formal type above.  You don't
need both signatures -- the top one will do.