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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,56250291936154a0 X-Google-Attributes: gid103376,public From: Robert A Duff Subject: Re: OS Bindings (was: Where is the elusive jump command?) Date: 2000/04/12 Message-ID: #1/1 X-Deja-AN: 610346992 Sender: bobduff@world.std.com (Robert A Duff) References: <38D771CA.D41AF9B5@port.ac.uk> <8bq7ku$mc8$1@nnrp1.deja.com><38E0E723.C39C392@quadruscorp.com> <8brfm4$4uc$1@nnrp1.deja.com><8brn4k$p6i$1@slb0.atl.mindspring.net> <8brrpj$i04$1@nnrp1.deja.com><38E312F8.78883ACB@icn.siemens.de> <8c4rvf$d9k$1@nnrp1.deja.com> <2000Apr5.070127.1@eisner> <2000Apr6.081305.1@eisner><8ci6vf$r5a$1@nnrp1.deja.com> <8ck638$krs3@ftp.kvaerner.com><8cp23c$4gp$1@nnrp1.deja.com> <8csjs8$o2p3@ftp.kvaerner.com><8d0su8$bqt$1@nnrp1.deja.com> <8d20bq$o2p4@ftp.kvaerner.com> <8d2dq9$2le$1@nnrp1.deja.com> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 2000-04-12T00:00:00+00:00 List-Id: Robert Dewar writes: > In article , > Robert A Duff wrote: > > If I made the rules, there would be no Max_Int. > > That may be OK, multiple precision integers can be useful, > so long as you do not go berserk and require that I be > able to use them for case indexes, subscripts, entryu > family indexes, loop variables, etc. > > It is this kind of silly requirement that caused many Ada > compilers not to even support 64-bit integers when they > could have done so easily. I agree about subscripts and entry families, but I don't see the problem with case statements. Loops? I dunno. I make the distinction because arrays are limited by address space; there's not much point in an array (2**99..2**99+1). But there could well be a point in calculating numbers like 2**99 or 2**999. And there's nothing wrong with a case statement on such a type. > The Ada 83 attitude was > > "if you implement 64-bit integer arithmetic, you MUST allow > all the above silly things, but it is absolutely FINE to not > implement 64-bit integer arithmetic at all." > > I am not sure whether we fixed this properly in Ada 95. Well, the RM allows some sort of non-standard integer types, which the implementation can arbitrarily restrict. Eg, you could have a 128-bit integer type that allows "+" and "-" but not "*" and "/". You can't pass these weird types, if they exist, as generic parameters. > In the case of GNAT, we allow 64-bit integer arithmetic > everywhere, and it would be very easy to allow larger > arithmetic, provided it is clear we do not have to allow > it in silly contexts. I think that is clear. I'm too lazy to look up the RM reference. I do remember that William Whitaker griped about this allowance rather strongly, which surprised me, because it seemed to me silly to say (to a compiler writer) you don't have to support X, but if you do support X, you have to *fully* support it. That's a bit different than saying, "if you support X, you have to support it in a standard way", which is something I have sometimes argued *for*. I admit that I can't formally define the difference between "incomplete support" and "different support" -- but I know it when I see it ;-). - Bob