* Bases for the Design of a Standard Container Library for Ada @ 2003-09-02 18:59 Mário Amado Alves 2003-09-03 20:30 ` Warren W. Gay VE3WWG ` (4 more replies) 0 siblings, 5 replies; 28+ messages in thread From: Mário Amado Alves @ 2003-09-02 18:59 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Bases for the Design of a Standard Container Library for Ada 2003-09-02 18:59 Bases for the Design of a Standard Container Library for Ada Mário Amado Alves @ 2003-09-03 20:30 ` Warren W. Gay VE3WWG 2003-09-03 21:07 ` David C. Hoos 2003-09-04 2:19 ` Randy Brukardt ` (3 subsequent siblings) 4 siblings, 1 reply; 28+ messages in thread From: Warren W. Gay VE3WWG @ 2003-09-03 20:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Bases for the Design of a Standard Container Library for Ada 2003-09-03 20:30 ` Warren W. Gay VE3WWG @ 2003-09-03 21:07 ` David C. Hoos 0 siblings, 0 replies; 28+ messages in thread From: David C. Hoos @ 2003-09-03 21:07 UTC (permalink / raw) To: Warren W. Gay VE3WWG, comp.lang.ada "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> ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Bases for the Design of a Standard Container Library for Ada 2003-09-02 18:59 Bases for the Design of a Standard Container Library for Ada Mário Amado Alves 2003-09-03 20:30 ` Warren W. Gay VE3WWG @ 2003-09-04 2:19 ` Randy Brukardt 2003-09-04 11:56 ` Mário Amado Alves 2003-09-08 17:02 ` Bases 1.57 Martin Krischik ` (2 subsequent siblings) 4 siblings, 1 reply; 28+ messages in thread From: Randy Brukardt @ 2003-09-04 2:19 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Bases for the Design of a Standard Container Library for Ada 2003-09-04 2:19 ` Randy Brukardt @ 2003-09-04 11:56 ` Mário Amado Alves 2003-09-05 3:55 ` Randy Brukardt 0 siblings, 1 reply; 28+ messages in thread From: Mário Amado Alves @ 2003-09-04 11:56 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Bases for the Design of a Standard Container Library for Ada 2003-09-04 11:56 ` Mário Amado Alves @ 2003-09-05 3:55 ` Randy Brukardt 2003-09-05 5:17 ` Matthew Heaney 0 siblings, 1 reply; 28+ messages in thread From: Randy Brukardt @ 2003-09-05 3:55 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Bases for the Design of a Standard Container Library for Ada 2003-09-05 3:55 ` Randy Brukardt @ 2003-09-05 5:17 ` Matthew Heaney 2003-09-05 11:45 ` Amado Alves 2003-09-05 15:10 ` Martin Krischik 0 siblings, 2 replies; 28+ messages in thread From: Matthew Heaney @ 2003-09-05 5:17 UTC (permalink / raw) "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> ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Bases for the Design of a Standard Container Library for Ada 2003-09-05 5:17 ` Matthew Heaney @ 2003-09-05 11:45 ` Amado Alves 2003-09-05 19:40 ` Randy Brukardt 2003-09-05 15:10 ` Martin Krischik 1 sibling, 1 reply; 28+ messages in thread From: Amado Alves @ 2003-09-05 11:45 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Bases for the Design of a Standard Container Library for Ada 2003-09-05 11:45 ` Amado Alves @ 2003-09-05 19:40 ` Randy Brukardt 0 siblings, 0 replies; 28+ messages in thread From: Randy Brukardt @ 2003-09-05 19:40 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Bases for the Design of a Standard Container Library for Ada 2003-09-05 5:17 ` Matthew Heaney 2003-09-05 11:45 ` Amado Alves @ 2003-09-05 15:10 ` Martin Krischik 2003-09-07 18:03 ` Matthew Heaney 1 sibling, 1 reply; 28+ messages in thread From: Martin Krischik @ 2003-09-05 15:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Bases for the Design of a Standard Container Library for Ada 2003-09-05 15:10 ` Martin Krischik @ 2003-09-07 18:03 ` Matthew Heaney 2003-09-08 12:54 ` Mário Amado Alves 0 siblings, 1 reply; 28+ messages in thread From: Matthew Heaney @ 2003-09-07 18:03 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Bases for the Design of a Standard Container Library for Ada 2003-09-07 18:03 ` Matthew Heaney @ 2003-09-08 12:54 ` Mário Amado Alves 0 siblings, 0 replies; 28+ messages in thread From: Mário Amado Alves @ 2003-09-08 12:54 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Bases 1.57 2003-09-02 18:59 Bases for the Design of a Standard Container Library for Ada Mário Amado Alves 2003-09-03 20:30 ` Warren W. Gay VE3WWG 2003-09-04 2:19 ` Randy Brukardt @ 2003-09-08 17:02 ` Martin Krischik 2003-09-08 17:07 ` Bases 1.58 Martin Krischik 2003-09-09 16:37 ` Bases 1.52 Martin Krischik 4 siblings, 0 replies; 28+ messages in thread From: Martin Krischik @ 2003-09-08 17:02 UTC (permalink / raw) To: Mário Amado Alves 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Bases 1.58 2003-09-02 18:59 Bases for the Design of a Standard Container Library for Ada Mário Amado Alves ` (2 preceding siblings ...) 2003-09-08 17:02 ` Bases 1.57 Martin Krischik @ 2003-09-08 17:07 ` Martin Krischik 2003-09-09 16:37 ` Bases 1.52 Martin Krischik 4 siblings, 0 replies; 28+ messages in thread From: Martin Krischik @ 2003-09-08 17:07 UTC (permalink / raw) To: Mário Amado Alves <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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Bases 1.52 2003-09-02 18:59 Bases for the Design of a Standard Container Library for Ada Mário Amado Alves ` (3 preceding siblings ...) 2003-09-08 17:07 ` Bases 1.58 Martin Krischik @ 2003-09-09 16:37 ` Martin Krischik 2003-09-10 7:49 ` Mário Amado Alves 2003-09-14 6:45 ` Matthew Heaney 4 siblings, 2 replies; 28+ messages in thread From: Martin Krischik @ 2003-09-09 16:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Bases 1.52 2003-09-09 16:37 ` Bases 1.52 Martin Krischik @ 2003-09-10 7:49 ` Mário Amado Alves 2003-09-11 15:03 ` Martin Krischik 2003-09-14 6:45 ` Matthew Heaney 1 sibling, 1 reply; 28+ messages in thread From: Mário Amado Alves @ 2003-09-10 7:49 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Bases 1.52 2003-09-10 7:49 ` Mário Amado Alves @ 2003-09-11 15:03 ` Martin Krischik 2003-09-12 10:58 ` Mário Amado Alves 2003-09-14 6:51 ` Matthew Heaney 0 siblings, 2 replies; 28+ messages in thread From: Martin Krischik @ 2003-09-11 15:03 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Bases 1.52 2003-09-11 15:03 ` Martin Krischik @ 2003-09-12 10:58 ` Mário Amado Alves 2003-09-12 13:05 ` Martin Dowie 2003-09-12 15:36 ` Bases 1.52 Martin Krischik 2003-09-14 6:51 ` Matthew Heaney 1 sibling, 2 replies; 28+ messages in thread From: Mário Amado Alves @ 2003-09-12 10:58 UTC (permalink / raw) (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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Bases 1.52 2003-09-12 10:58 ` Mário Amado Alves @ 2003-09-12 13:05 ` Martin Dowie 2003-09-12 17:49 ` maximum number of lines per spec (was: Bases 1.52) Mário Amado Alves 2003-09-12 15:36 ` Bases 1.52 Martin Krischik 1 sibling, 1 reply; 28+ messages in thread From: Martin Dowie @ 2003-09-12 13:05 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* maximum number of lines per spec (was: Bases 1.52) 2003-09-12 13:05 ` Martin Dowie @ 2003-09-12 17:49 ` Mário Amado Alves 2003-09-13 12:18 ` Marin David Condic 0 siblings, 1 reply; 28+ messages in thread From: Mário Amado Alves @ 2003-09-12 17:49 UTC (permalink / raw) > > ... 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). ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: maximum number of lines per spec (was: Bases 1.52) 2003-09-12 17:49 ` maximum number of lines per spec (was: Bases 1.52) Mário Amado Alves @ 2003-09-13 12:18 ` Marin David Condic 0 siblings, 0 replies; 28+ messages in thread From: Marin David Condic @ 2003-09-13 12:18 UTC (permalink / raw) 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 ====================================================================== ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Bases 1.52 2003-09-12 10:58 ` Mário Amado Alves 2003-09-12 13:05 ` Martin Dowie @ 2003-09-12 15:36 ` Martin Krischik 1 sibling, 0 replies; 28+ messages in thread From: Martin Krischik @ 2003-09-12 15:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Bases 1.52 2003-09-11 15:03 ` Martin Krischik 2003-09-12 10:58 ` Mário Amado Alves @ 2003-09-14 6:51 ` Matthew Heaney 2003-09-14 14:32 ` Martin Krischik 2003-09-14 18:22 ` Robert I. Eachus 1 sibling, 2 replies; 28+ messages in thread From: Matthew Heaney @ 2003-09-14 6:51 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Bases 1.52 2003-09-14 6:51 ` Matthew Heaney @ 2003-09-14 14:32 ` Martin Krischik 2003-09-14 18:22 ` Robert I. Eachus 1 sibling, 0 replies; 28+ messages in thread From: Martin Krischik @ 2003-09-14 14:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Bases 1.52 2003-09-14 6:51 ` Matthew Heaney 2003-09-14 14:32 ` Martin Krischik @ 2003-09-14 18:22 ` Robert I. Eachus 2003-09-14 22:56 ` Nick Roberts 1 sibling, 1 reply; 28+ messages in thread From: Robert I. Eachus @ 2003-09-14 18:22 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Bases 1.52 2003-09-14 18:22 ` Robert I. Eachus @ 2003-09-14 22:56 ` Nick Roberts 2003-09-15 0:17 ` Robert I. Eachus 0 siblings, 1 reply; 28+ messages in thread From: Nick Roberts @ 2003-09-14 22:56 UTC (permalink / raw) "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] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Bases 1.52 2003-09-14 22:56 ` Nick Roberts @ 2003-09-15 0:17 ` Robert I. Eachus 0 siblings, 0 replies; 28+ messages in thread From: Robert I. Eachus @ 2003-09-15 0:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Bases 1.52 2003-09-09 16:37 ` Bases 1.52 Martin Krischik 2003-09-10 7:49 ` Mário Amado Alves @ 2003-09-14 6:45 ` Matthew Heaney 1 sibling, 0 replies; 28+ messages in thread From: Matthew Heaney @ 2003-09-14 6:45 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2003-09-15 0:17 UTC | newest] Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-09-02 18:59 Bases for the Design of a Standard Container Library for Ada Mário Amado Alves 2003-09-03 20:30 ` Warren W. Gay VE3WWG 2003-09-03 21:07 ` David C. Hoos 2003-09-04 2:19 ` Randy Brukardt 2003-09-04 11:56 ` Mário Amado Alves 2003-09-05 3:55 ` Randy Brukardt 2003-09-05 5:17 ` Matthew Heaney 2003-09-05 11:45 ` Amado Alves 2003-09-05 19:40 ` Randy Brukardt 2003-09-05 15:10 ` Martin Krischik 2003-09-07 18:03 ` Matthew Heaney 2003-09-08 12:54 ` Mário Amado Alves 2003-09-08 17:02 ` Bases 1.57 Martin Krischik 2003-09-08 17:07 ` Bases 1.58 Martin Krischik 2003-09-09 16:37 ` Bases 1.52 Martin Krischik 2003-09-10 7:49 ` Mário Amado Alves 2003-09-11 15:03 ` Martin Krischik 2003-09-12 10:58 ` Mário Amado Alves 2003-09-12 13:05 ` Martin Dowie 2003-09-12 17:49 ` maximum number of lines per spec (was: Bases 1.52) Mário Amado Alves 2003-09-13 12:18 ` Marin David Condic 2003-09-12 15:36 ` Bases 1.52 Martin Krischik 2003-09-14 6:51 ` Matthew Heaney 2003-09-14 14:32 ` Martin Krischik 2003-09-14 18:22 ` Robert I. Eachus 2003-09-14 22:56 ` Nick Roberts 2003-09-15 0:17 ` Robert I. Eachus 2003-09-14 6:45 ` Matthew Heaney
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox