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,db88d0444fafe8eb X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!proxad.net!gatel-ffm!gatel-ffm!194.25.134.126.MISMATCH!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!news.arcor.de!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Surprise in array concatenation Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.14.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: <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> <431c8c35$0$2101$9b4e6d93@newsread2.arcor-online.net> Date: Tue, 6 Sep 2005 10:20:54 +0200 Message-ID: <3ufj318nkubi.a5j4dbvaofhc.dlg@40tude.net> NNTP-Posting-Date: 06 Sep 2005 10:19:50 MEST NNTP-Posting-Host: 540edacc.newsread2.arcor-online.net X-Trace: DXC=4;maD^R6cV\MYeRE0Pb_HUQ5U85hF6f;TjW\KbG]kaMXA@_25la3nbRah?M6`??JYZWRXZ37ga[7Zn919Q4_`VjYB8=X\UUgbkT X-Complaints-To: abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:4466 Date: 2005-09-06T10:19:50+02:00 List-Id: On Mon, 05 Sep 2005 20:20:19 +0200, Georg Bauhaus wrote: > 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? Inconsistency means that you can derive P and ~P. So far, there were no evidences that the world doesn't obey logic. > We can agree on someting. > (As I said, HALT is the limit, I think we cannot even formally > decide, mathematically, whether consistency is consistent.) You cannot express the sentence above in a formal language. Which does not imply its undecidability. Only proper propositions can be decidable or not. > 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. You better show a case where [mathematically] inconsistent program could be usable. [Windows does not count! (:-))] >>>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.) If hi and lo are just arbitrary values then take 3.456 and 1. They are easier to calculate. hi and lo are bounds, as such they have definite contracts. They cannot be "just" values. Once you formulate the contract, it will be pretty easy to show whether it is consistent = no any properly constructed array object violates the contract. It is not rocket science, really... >> Then what would you do >> with modular and enumeration types? > > Use subtypes. Computers are finite, so are types. I don't know what a finite type is. You might mean the domain set of a type. Then you are wrong, the sets of values of Ada's universal types aren't finite. You can have a type which values comprise an uncountable set of any cardinality [I cannot tell for unreachable cardinals, though (:-))] It is not the same as to be able enumerate all these values in one program! There is no any limitation on how bit patterns are mapped to the type values. I can have 0000->Pi, 0001->e, 0010->. >> 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. Ah, that's your definition of freedom... (:-)) >> 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., ... It sounds as if the whole language design would collapse if empty arrays were constructed otherwise [properly.] Do you really believe in that? >> 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? Did I say that? The idiom you trying to push for has a clear application area. This area is *narrower* than one of the array idiom. Then with "off"-values or without them, A'Last shall *not* be less than A'First. Presently the case A'Last < A'First is used to indicate that there is no bounds. It is a quite silly way to handle errors. Instead of an immediate response you return nonsensical values in hope that inconsistency will be handled [or not] later. It is like to make Positive / 0 = -1, if you will use it, you'll get Constraint_Error, if you won't, then, let's call it a useful idiom of dividing to zero as opposed to impractical mathematical definition... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de