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