🚀 go-pugleaf

In article <1303@infbs.UUCP< neitzel@infbs.UUCP (Martin Neitzel) writes:
<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.  

There is no formal definition given by Wirth of the generic "integer" concept.
Hence there is no basis for claiming that the operations "+", "-", "*", "MOD"
and "DIV" must be defined on any type which qualifies as an "integer" type.

There is, however a formal definition of a generic concept called "ordinal
types."  One possible paraphrase of this concept is "a type whose values
or magnitudes are integral--that is, occur in discrete units."  There is no
reason that Wirth could not have meant "integer" to be synonymous with
"ordinal type."

Characters are logically integral values.  And physically, they are unsigned
(or on some systems, signed) integers.  The purpose of the CHAR abstraction
is to hide both the number of bits in a character and the mapping between 
integer values and character semantics.  If the purpose had included hiding
that fact that characters are integers, then the ORD() and CHR() functions
would neither exist nor be guaranteed to be definable.

<[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?)

PIM3 clearly states that "33C" is a number of type CHARACTER.  And that
a number is either an integer (note the lower case) or a real number.
This quote is unambiguos support form my position.

<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.

When creating products, implementors must choose who their target market will
be and must attempt to satisfy the needs and expectations of the customers
in that market.  The same dilemma faces those who would design and/or decide
on a standard for a programming language.

Customers in the commercial Modula-2 compiler market need and expect to see
SET OF CHAR.

And I would think that educators would want to teach a language that prepared
their students for the realities of the commercial world.


Alan Lovejoy; alan@pdn; 813-530-2211; AT&T Paradyne: 8550 Ulmerton, Largo, FL.
Disclaimer: I do not speak for AT&T Paradyne.  They do not speak for me. 
______________________________Down with Li Peng!________________________________
Motto: If nanomachines will be able to reconstruct you, YOU AREN'T DEAD YET.