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,229ea0001655d6a2 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Newsgroups: comp.lang.ada Subject: Re: Generic Package 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> <1qalyduzy3n5z$.131428s0c8mlz.dlg@40tude.net> From: Markus E Leypold Organization: N/A Date: Wed, 02 May 2007 09:52:08 +0200 Message-ID: User-Agent: Some cool user agent (SCUG) Cancel-Lock: sha1:QrZw60WvuGd6IkgaVVqrynylXSs= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 88.72.252.103 X-Trace: news.arcor-ip.de 1178091837 88.72.252.103 (2 May 2007 09:43:57 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news1.google.com!news3.google.com!proxad.net!213.200.89.82.MISMATCH!tiscali!newsfeed1.ip.tiscali.net!news.tiscali.de!newsfeed.freenet.de!news.unit0.net!newsfeed.arcor-ip.de!news.arcor-ip.de!not-for-mail Xref: g2news1.google.com comp.lang.ada:15451 Date: 2007-05-02T09:52:08+02:00 List-Id: "Dmitry A. Kazakov" writes: > 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. But if we abstain for the moment from so many words and free wheeling associations and come back to your original statement: You asserted that one "cannot iterate over relational tables". I still do not get it. PostgresQL provides an interface to do exactly that: http://www.postgresql.org/docs/7.2/static/libpq-exec.html. In my book that interface provides means to "iterate over relational tables". Questioning wether this is really iteration or wether PostgresQL really provides "relational tables" is both, in my opinion, not a feasible option. So you have to admit that it is possible to iterate over realtional tables. Q.E.D. Thanks -- Markus