From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,f2690a5e963b61b6 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!z14g2000cwz.googlegroups.com!not-for-mail From: "MMM" Newsgroups: comp.lang.ada Subject: Re: GCC 4.0 Ada.Containers Cursor danger. Date: 11 Jul 2005 19:11:31 -0700 Organization: http://groups.google.com Message-ID: <1121134291.379399.79460@z14g2000cwz.googlegroups.com> References: <1120474891.635131.216700@g44g2000cwa.googlegroups.com> <1120575076.876798.108220@g44g2000cwa.googlegroups.com> <1120583470.429264.325450@g43g2000cwa.googlegroups.com> <42cb8d21$0$22761$9b4e6d93@newsread2.arcor-online.net> <42cd064c$0$10817$9b4e6d93@newsread4.arcor-online.net> <42cda8c4$0$22780$9b4e6d93@newsread2.arcor-online.net> <1u3hh2597i4ne$.1ryetugksbmus.dlg@40tude.net> <1120834341.499757.133770@g43g2000cwa.googlegroups.com> <1121093867.964444.232420@g14g2000cwa.googlegroups.com> <42d2bc2d$0$20148$9b4e6d93@newsread2.arcor-online.net> NNTP-Posting-Host: 24.107.234.224 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1121134297 27205 127.0.0.1 (12 Jul 2005 02:11:37 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 12 Jul 2005 02:11:37 +0000 (UTC) User-Agent: G2/0.2 Complaints-To: groups-abuse@google.com Injection-Info: z14g2000cwz.googlegroups.com; posting-host=24.107.234.224; posting-account=0PrGnQwAAAAhG4fw_pPdaColajHpyOJW Xref: g2news1.google.com comp.lang.ada:12005 Date: 2005-07-11T19:11:31-07:00 List-Id: Georg Bauhaus wrote: > MMM wrote: > >> The reason is that, if one >> remember some mathematics, having an order is a fundamental property >> that distinguish vectors and lists on the one side and sets and hashes >> on the other. > > > I think it is not too helpful to consider Ada.Containers to be > derived from some collection of mathematical notions and from > nothing else. > You are right that for the person not familiar with mathematics that will be of no help. But I suspect that people designing computer programs in general and designing programs in Ada in particular have some knowledge of at least simple math. Note also that mathematics is the lingua franca not only for the science but also for programming and computers in general. Note also that it is not "some collection of mathematical notions", it is a well known theory, while current proposal of container types *is* some collection of mixed notations and it looks like it is derived from "nothing else" only. > First, Ada.Containers is not trying to approximate some notions > from linear algebra ("orthogonal normal basis"), metaphorically Note that this notion is not limited to linear algebra and I'm not agitating for implementation of this notion in Ada.Containers in any way! ;):);):) What I've ment is that library should implement all commonly used and accepted abstractions and then, if it is practical, implement all needed specialisations, mixtures, etc. > or not. ;-) You'll have justify the implication that > we should build computer libraries around some specific > choice of notions loosly derived from mathematics. Doing this > is not a matter of course, as reactive systems are not all > about mathematics. I'm not sure what you mean by "reactive systems", but anyway. My justification is very simple. Such a generic library as Ada.Containers, which should serve as a basis for a wide variety of programs, should be based on a well known abstraction commonly accepted and understood by every programmer, not only by couple of authors. The foundations of this library should be derived from the common experience, not from the experience of one man. For example of what other programmers think about containers see the following links (as well as how this abstraction is implemented in other languages such as Java, Python etc.) http://en.wikipedia.org/wiki/Set_%28computer_science%29 http://en.wikipedia.org/wiki/Hash_table http://en.wikipedia.org/wiki/List_%28computer_science%29 http://en.wikipedia.org/wiki/Array Actually current proposal have to justify the use of such a wonderful abstractions as Ordered_Sets, Hashed_Sets, Hashed_Maps and Ordered_Maps as a basic set of abstractions. > > Second, the way Ada.Containers invites you to think about the order > of elements ("containers are nothing, elements are everything"). > There might be some physical/logical correspondence between the > order of elements in some container on the one hand, and their > order as implied by the user's ordering functions passed during > instantiation. Or there might not. It is more important what a Can't argue with that ;) > user wishes to to using the elements that happen to be elements > of some collection. I.e. while it remains advisable to choose the > proper container, Cursors are among the means to choose different > containers when the need arises, ideally without disturbing the rest of > the program. I can't say I understand you here, but anyway, how cursors could help to change container type without disturbing the rest of the program? > > There are a number of "orders" of elements in this discussion. I think you overestimate a little here. Order either is present or is not. > There are those on which you seem to build your correspondence, IIUC. > Elements ordered relative to one another in the list and vector > abstractions, > because that is what a mathematician might assign to the notions. Yes, YUIC. But it is not because "a mathematician" created this notion. This is how all mathematicians *and* programmers understand it. > But some elements are ordered relative to one another in ordered sets or > maps > that are ordered by key. This order need not entail the use of a list, > and indeed requiring List/Vector <-> order will defeat several uses > of the library which is rather more flexible. If I want a set for > (a) memebership test, and (b) an ordered collection, then why should I > store > the elements in some List oder Vector just because I want element > insertion to preserve order as well? This exaple doesn't count. Membership test is common to any collection. If you only need ordering then you can use array/vector or list depending on what kind of access you need. Why would you choose a set or hash? And if you chose to have such a specialized type as Ordered_Map then you > Indeed, a close correspondence of order and choice of container > will defeat some generic algorithms. Care to provide an example of such a generic algorithm? If your algorithm is so generic that order and access details are not important, then express you algorithm in terms of Abstract_Collection. Then averyone could choose any collection type that fits the task in question most. > > I think it is of no primary concern here that some branches of > mathematics can > do without ordered sets, and that there is a natural ordering by position > in a list. The library is for programmers, not for mathematical > housekeepers. ;-) There is a treasure trove of mathematical theory of > computation that starts from computation in computers, and not the other > way round :-) > I really hope that the smiles you put here really mean something ;) Otherwise your disregard of mathematics and computer science could led you to reinvent a lot of weels. ;( One need to have a knowledge to distinguish a therasure from trash :) The sad thing is that this proposal forces the whole Ada comunity to learn the hard way and to reinvent collections from scratch. Take a look at others languages collections implementations. > > >> Another silliness is overgeneralization of the >> 'iterrator' concept and renaming it to 'cursor'. > > > Given the operations of Cursors, I can see clearly how I can > use Cursor operations in iteration. OTOH, iteration Of course you can! One can use his computer to watch TV or even to move his lawn, but that is not a justification for renaming this computer to TV-set or mover. Authors of this proposal stated that they model their library on STL. So why to name the same thing differently? > means doing something again, but an STL iterator (a pointer, > really, or cursor if you wish) doesn't require that I do something > again... So what? > > >> The problem here is that this terminology doesn't reflect the >> fundamental differences between these types and mixes underlying >> mathematical conncepts in some unregular way. > > > If the library confuses a mathematician because he/she is used > to some meanings of words, then maybe emphasising the Ada definitions, > which relate to computers, will help? > Ok, it looks like you really hate mathematicians :) Why? To soothe you I can tell that I'm not a mathematician. I'm a physisist by education and a programmer for the last 20 years. This library confuses me as a programmer. I've always loved Ada 83 and 95. I really believe that its standard library stands out by its clarity, completeness and correctness. Current proposal for Ada.Containers doesn't meet these high standards yet. It is too raw. It looks like the authors of this proposal didn't have a goal of creating clear and solid foundation for future library development. It looks like they provided just a bunch of special case algorithms and abstractions using far from perfect terminology. To understand this one need no degree in mathematics, just look around - STL,Java,Python, etc.,etc. > > -- Georg Mikhail