Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site fortune.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!ihnp4!fortune!phipps From: phipps@fortune.UUCP (Clay Phipps) Newsgroups: net.lang.mod2 Subject: Re: Cardinal Message-ID: <2696@fortune.UUCP> Date: Tue, 6-Mar-84 22:57:24 EST Article-I.D.: fortune.2696 Posted: Tue Mar 6 22:57:24 1984 Date-Received: Wed, 7-Mar-84 07:06:51 EST References: <5821@decwrl.UUCP> Organization: Fortune Systems, Redwood City, CA Lines: 75 The 'cardinal' type was not in the original Modula paper [*Software -- Practice And Experience*, vol. 7 (1977), p. 3 .. 35; see p. 11], so I suspect that it was added late in the Modula-2 design without considering its implications. The integer vs. cardinal distinction appears to be an abstraction of the low-level distinction between signed and unsigned arithmetic. The Modula-2 book mentions the greater range of unsigned integers and the gain in program reliability from defining away many illegal values for subranges with nonnegative lower bounds, such as types used for counters. It seems like a nice idea, especially because I was substantially burned by a magic constant 65535 in a program that would not work if that number were not represented as a 16-bit unsigned integer. I thought that this would provide a means for clarifying a programmer's intentions via source language constructs, but this isn't the case [sigh!]. My initial enthusiasm for the notion of cardinal types was reinforced by a vague feeling that they would simplify some heuristic representation selection code in a Pascal compiler I worked on a few years back; I can't recall the details at the moment. I think it had to do with fields in packed records used to map data structures to communicate with microcode and hardware. I am really disappointed by the apparent lack of thoroughness in the language design with regard to cardinals. Wirth didn't take it far enough. For my notion of cardinals as an abstraction of unsigned numbers to be effective, it must be possible to express subranges relative to an explicit base type. This means that a subrange would be like an Ada subtype, i.e., a base type with a particular constraint; this seems most consistent with the Modula notion of "compatible". Therefore, instead of just SubrangeType = "[" ConstExpr ".." ConstExpr "]" the language would have a rule like SubrangeType = [BaseType] "[" ConstExpr ".." ConstExpr "]" Only if the programmer declined to specify a BaseType would the current rule about using a negative lower bound be applied to select between cardinal and integer. This seems to be especially important because cardinals and integers cannot be mixed in expressions. This strikes me as a cop-out by Wirth. Selecting a good rule for combining the two types in expressions might be tricky [I haven't given it much thought], but it seems analogous to the integer vs. floating-point combination problem that has been around for years. Is forcing the use of type-transfer functions reasonable in practice ? The definition of the MaxInt and related values is prefaced in the Report, p. 145, with the phrase "For implementations on 16-bit computers". I note that Wirth assumes 2's-complement representation, because MinInt is given as -32768, not -32767. I believe that only the symmetrical range should be standard, with the extra (nonsymmetrical) number allowed as an extension. I would have preferred that these values be obtained by inquiry functions, as in Algol 68. By the way, I know of at least one machine that has *signed* integer addresses and *signed* 'program counter' arithmetic: the ELXSI 6400, which, like the VAX, has a 32-bit address space. It turns out that signed addresses cause no problems to speak of, no more so than east vs. west street addresses do. However, treating ELXSI address bit patterns simplemindedly as cardinals would be a problem. -- Clay Phipps -- {allegra,amd70,cbosgd,dsd,floyd,harpo,hpda,ihnp4, megatest,nsc,oliveb,sri-unix,twg,varian,VisiA,wdl1} !fortune!phipps