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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,229ea0001655d6a2 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!storethat.news.telefonica.de!telefonica.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Generic Package Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <1177539306.952515.222940@s33g2000prh.googlegroups.com> <1177601484.444701.171560@r35g2000prh.googlegroups.com> <9eejm6rqip.fsf@hod.lan.m-e-leypold.de> <19qllkvm6ut42$.1iqo74vjgmsrv$.dlg@40tude.net> <1177801611.10171.32.camel@localhost.localdomain> <1woad6hn9idy2$.6otnwphc1o0h$.dlg@40tude.net> <1177929029.6111.34.camel@localhost> <1177944533.13970.17.camel@localhost> <2aq08qbvw0ym$.1rquampzo7o53.dlg@40tude.net> <1ieq3io2d6nnq$.13818v3y35gnr.dlg@40tude.net> <1178010142.6695.29.camel@localhost.localdomain> <1178026941.16837.88.camel@localhost.localdomain> <1ozvzzh59ebq8$.yeh9do8s3hig$.dlg@40tude.net> Date: Tue, 1 May 2007 22:14:33 +0200 Message-ID: <1qalyduzy3n5z$.131428s0c8mlz.dlg@40tude.net> NNTP-Posting-Date: 01 May 2007 22:14:08 CEST NNTP-Posting-Host: 99862ca3.newsspool3.arcor-online.net X-Trace: DXC=]DZ``MRTNE8]E=H1Q9`787McF=Q^Z^V384Fo<]lROoR1Fl8W>\BH3Y2WCQV8EMQho2DNcfSJ;bb[5IRnRBaCdGjoTQI9dK8?8PK>Ri?eOY9 X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:15442 Date: 2007-05-01T22:14:08+02:00 List-Id: On Tue, 1 May 2007 14:14:46 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:1ozvzzh59ebq8$.yeh9do8s3hig$.dlg@40tude.net... >> On Tue, 01 May 2007 15:42:21 +0200, Georg Bauhaus wrote: > ... >>> Yes, in the sense that the specifics of memory layout and such are >>> unknown and irrelevant to the client; in particular, no order needs >>> to be specified. >> >> Apart from obvious uselessness of contracts referencing to the memory >> layout, the above is self-contradictory. Memory layout defines an order. It >> also is a part of the contract. Hence the interface is ordered. > > And now all is clear. > > It is impossible to implement a set with having some form of order. So, for > us practitioners, an "unordered set" is simply a set with no defined order. > I can see that you are arguing about a idealized set unordered set that > cannot actually exist - an abstraction that is irrelevant in practice. No > wonder people are confused. > > There is a reason that Ada.Containers has ordered and hashed sets, but not a > mathematically unordered one. That because the latter is impossible to > implement without a suboptimal mapping into one of the other forms. The net > effect is that even if you could use such a form, you would take a massive > performance hit to do so (all operations being O(N)). As such, there is no > reason to consider such forms or worry about their properties. I definitely agree with this. And this is the answer to the OP question about "generic collections," they would be close to useless. Yet I think that this abstraction is not that irrelevant. One example is distributed systems, like DB engines. There is a reason why relational containers are defined unordered. It is not because no order could be invented. It is because this abstraction forces the programmer either to use snapshots (ordered mappings of an unordered set) or stored procedures (foreach-magic) to get at an order. Making the interface ordered would probably prevent efficient implementations of the DB engines. This boils down to the question of the underlying hardware. DB engine is a hardware from the application point view. It is a very strange hardware for which the logic of being able to enumerate everything at once, here and now, does not apply. It is likely so for any system with distributed containers and distributed programs dealing with them. In such hardware foreach-magic could be in order of magnitude more efficient than ordering in situ. Or let's take Get_Pixel / Set_Pixel on the image containers of the graphic accelerator. Further, if we looked into the future, on quantum computing stuff, then there is a possibility that such hardware could become rather normal. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de