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,db88d0444fafe8eb X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news.glorb.com!news.germany.com!newsfeed.arcor.de!news.arcor.de!not-for-mail Date: Mon, 05 Sep 2005 20:20:19 +0200 From: Georg Bauhaus Organization: future apps GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050718 Debian/1.7.8-1sarge1 X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Surprise in array concatenation References: <1125544603.561847.32140@g47g2000cwa.googlegroups.com> <14muavojz308w.1ouv7xin79rqu$.dlg@40tude.net> <4318486f$0$24154$9b4e6d93@newsread4.arcor-online.net> <43187a50$0$24162$9b4e6d93@newsread4.arcor-online.net> <11p5i525v2q5d$.17ayuwvqhazo1.dlg@40tude.net> <431a00cb$0$2113$9b4e6d93@newsread2.arcor-online.net> <9s72daxfzb4f.1k7noh1qr5qpg.dlg@40tude.net> <431c465d$0$24150$9b4e6d93@newsread4.arcor-online.net> <79fcfodixv3k$.1m7d28joczncs$.dlg@40tude.net> In-Reply-To: <79fcfodixv3k$.1m7d28joczncs$.dlg@40tude.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <431c8c35$0$2101$9b4e6d93@newsread2.arcor-online.net> NNTP-Posting-Date: 05 Sep 2005 20:19:33 MEST NNTP-Posting-Host: 92be252f.newsread2.arcor-online.net X-Trace: DXC=jn@l[Mj8d1Cl=9hLK`A7fMQ5U85hF6f;DjW\KbG]kaMHQ>n?D9BSA]L:OM5D6ZF0WAljUVjRQ60?BVmnOeiOY3@Ng[50F7T5IOB X-Complaints-To: abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:4447 Date: 2005-09-05T20:19:33+02:00 List-Id: Dmitry A. Kazakov wrote: >>Likewise, a computer might surprise us in suggesting that our >>fine mathematically thought-out program doesn't quite behave exactly >>as we thought, because of the naughty computer thingy and its >>quirks. > > > You are mixing inadequate and inconsistent models. The world (our problem domain) *is* inconsistent, otherwise, if it were consistent, how could we possibly know what inconsistency is? We can agree on someting. (As I said, HALT is the limit, I think we cannot even formally decide, mathematically, whether consistency is consistent.) A computer, being a real world item, has a good chance of being whatever it is, there is no complete knowledge of a computer's consistency. Mathematically consistent programs can be helpful when the set of preferred consistency rules is both specified and relates to the program. >>We have >> lo, hi: arrays -> I, >> item: arrays x I -> values > What about hi >= lo? No problem, as hi, lo: arrays -> I are just functions. (These are "minimal" assumptions, really.) > What about handling Some_Array (Some_Array'First) > failure? Same as handling any indexing failure. But different from, and possibly unrelated to, elaborating the range that is established by a pair of index values. > Note that it fails not because there is no A'First, but because > the index is wrong? How so? It exists, but wrong! A'First for an empty array isn't wrong at all, it is just a value from the set of index values. An array is associated with two particular values from the set of index values. Then there is a function, item: arrays x I -> values, defined for some (array, index) pairs, undefined for others. > Then what would you do > with modular and enumeration types? Use subtypes. Computers are finite, so are types. So I say what I want in Ada, another value to mark off the end. Not nice but practical. (Real types exist inside computers, computed in finite time. Mathematical types can exist as "infinite" type look-alikes as in Haskell.) >>>Better ADT is what Ada needs. >> >>Is Ada a Must for you? > > > Sure. C++ shortens my life! Then don't use C++. But there are practical alternatives to C++ if you can give up some pieces of Ada. > Like C++? (:-)) Like many. > What I want is freedom. Then choose not use empty arrays, or test for 'length = 0, or build your own array abstraction, use use Ada.Containers.Vectors, .... or do not use Ada. > I don't want the compiler to decide for me whether > there must be "off" values or not. The compiler does not force you to use "off" index values, it forces you to use Ada. When this limit is not o.K., ... > The concept of array must be consistent > with index types having no "off" values, like ring buffers. I see that you like this view, and I see that many programmers and language designers use indexing with off-bounds index values. Some languages can do without index manipulation, and with empty sets. Consider this SETL/2 example: program automatic_indexes; Couples := { ["Frank", "Lisa"], ["Joe", "Nancy"], ["Jack", "John"], ["Jack", "Lisa"] }; selpuoC := {[x, y]: [y, x] in Couples}; print("Just the Two of Us: ", {[x, y]: y = Couples(x) | #Couples{x} = 1 and #selpuoC{y} = 1}); for person in { x: x in domain Couples | #Couples{x} = 1} + { y: y in range Couples | #selpuoC{y} = 1} loop print(person, " says, 'One is enough for me!'"); end loop; end automatic_indexes; [Eiffel solution] > This is incompatible with modular and enumeration types. It also has a > distributed overhead. You either will have no by-copy types or will need to > store NONE where one bit would otherwise be enough. Then making a hash > function you'll need to explicitly test for NONE etc. Are you sure you know these things about Eiffel, as opposed to something that you think must must be the case with Eiffel? > Sure. And in mathematics there is no problem to write: > > forall x in X Like in many programming languages. > I in A'First..A'Last that A'Range is 1) ordered, 2) has the lower and upper > bounds, 3) these bounds belong to the array. These assumptions are not > always required. Moreover, for some arrays they are wrong. A range with A'Last > A'First is not wrong, I see that you don't like it. It seems you want to restrict Ada by disallowing programmers to freely use this widespread idiom for expressing empty arrays, because it violates your preferences for some consistency of ordered indexing, right?