🚀 go-pugleaf

pim3>	This must be a subrange type of the integers [...],
pim3>	or a (subrange of an) enumeration type ...

Martin>	CHAR simply doesn't qualify.

Alan>	Note that in the phrase "of the integers" the word "integers"
Alan>	is NOT capitalized.  Hence it is not clear that Wirth means to
Alan>	authorize only values of type INTEGER.

I always understood "integers" in the generic meaning too.  It is
quite clear that this generic sense is intended here and at other
places as well.  However, I always thought that only (LONG)INTEGER and
CARDINAL would count as integers, i.e. things you can add and multiply
etc.  And that CHAR would not.  This was induced by the following:

[PIM3, 6.1 Basic types:]
pim3>
pim3>	The following basic types are predeclared and denoted by
pim3>	standard identifiers:
pim3>	
pim3>	1. INTEGER comprises the integers between MIN(INTEGER) and
pim3>	   MAX(INTEGER).
pim3>	2. CARDINAL comprises the integers between 0 and
pim3>	   MAX(CARDINAL).  [...]
pim3>	4. CHAR denotes the character set provided by the used
pim3>	   computer system.  [...]
pim3>	6. LONGINT comprises the integers between MIN(LONGINT) and
pim3>	   MAX(LONGINT).

This makes me think that characters are not integers.
A closer look at the "definition" of the term "integers"
reveils little more:

[PIM3, 3. Vocabulary and representation:]
pim3>
pim3>	2. `Numbers' are (unsigned) integers or real numbers.
pim3>	Integers are sequences of digits.  If the number is followed
pim3>	by the letter B, it is taken as an octal number; if it is
pim3>	followed by the letter H, it is taken as a hexadecimal number;
pim3>	if it is followed by the letter C, it denotes the character
pim3>	with the given (octal) ordinal number (and is of type CHAR,
pim3>	see 6.1).

As I understand this, there exist objects (characters) that can be
denoted via their ordinal number.  While this number is an integer,
the denoted object must not necessarily be, at least in my opinion.
(Else, if there weren't a difference between a character and its number,
what should be the reason to take the ORD of a character at all?)


Alan>	As evidence that Wirth did not mean that [integer only refers
Alan>	to INTEGER, Martin] , try using one of his compilers to compile
Alan>	the following:

Alan>	VAR
Alan>	  aCardinal: CARDINAL;
Alan>	BEGIN
Alan>	  aCardinal := 0;
Alan>	  IF aCardinal IN {0} THEN
Alan>	    WriteString("Either mixed CARD-INT expressions are legal,");
Alan>	    WriteString(("or else SETs are not restricted to containing INTs");
Alan>	  END;
Alan>	END

1.: I already said that what I consider to be "integer".  We both
    agree in that it includes CARDINALs.  No problem here.

2.: The type of an ambigous literal like "0" may be either CARDINAL or
    INTEGER, as suitable for the actual context.  This is why "X+3"
    works for X declared as INTERGER and as CARDINAL.  [PIM3, Ch.3, 2.]

3.: Wirth's own compilers can fail to match his intentions as well as
    they can fail to match his report.  (In both cases deliberately or
    unwillingly.)

Alan>	As further proof, consider the formal definition of set types
Alan>	given in the next paragraph:
Alan>
Alan>	$ SetType = SET OF SimpleType.
Alan>	[...]

This is not the "formal definition of set types".  This is only the
formal definition of their syntax.  You may not simply forget the
additional semantic constraints (given in informal language).

Alan>	Notice that all of Wirth's compilers blithely accept "SET OF
Alan>	BOOLEAN" in spite of the fact that the Report does not grant
Alan>	BOOLEAN the right to be called an enumeration type.

Nice of him.  (Even no sarcasm here.)

Alan>	PIM simply contains errors, omissions and contradictions.  The
Alan>	good doctor wants us to DoWhatHeMeansNotWhatHeSays.

I would happily take the "corrective" approach in my implementation if
Wirth had replaced the last paragraph in the "Introduction" of the
report with a modest "DoWhatIMean".  (I know that one shouldn't expect
even a "95% bug free definition" if it shall still be readable at the
same time.)

As a compiler implementor one also has sometimes obligations to his
customers/users.  In my case, the CS fresh(wo)men expect the compiler
to behave according to the book they bought (preferably only ONE
book...:-).  They certainly cannot be expected to guess what Wirth may
have meant and how a "sensible" implementation should differ from
his books.  For a mere personal use of the compiler, I wouldn't hesitate
to digress from the book.  But that's not the case here.

							Martin