🚀 go-pugleaf

In article <INFO-M2%88061707562183@UCF1VM> Info-Modula2 Distribution List <INFO-M2%UCF1VM.bitnet@jade.berkeley.edu> writes:
>
> Programmers frequently use expressions like INTEGER(c)
> in order to convert a value of type CARDINAL into one of type
> INTEGER.  However, this practice ought to be avoided
> since it only works if the types CARDINAL and INTEGER
> have the same representation for the possible values of c.
> Although this is likely to be the case, programmers ought to use
> VAL(INTEGER,c) which is guaranteed to work for appropriate values of c.

Sorry for having to contradict here: There is nothing in the  report (as I read
it)  that  supports the claim  that VAL(INTEGER,c) or VAL(CARDINAL,i) will work
"as intended" although it  _does_ work on  all compilers I  know (at  least all
those that implement VAL  more or less  according  to  the  report). In  fact a
strict interpretation of the report implies the opposite.

Quoting from PIM2, ed3, p 162:
	"ORD(x)		ordinal number (of type CARDINAL) of x in the set of
			values defined by type T of x. T is an enumeration type,
			CHAR, INTEGER, or CARDINAL.

	"VAL(T,x)	the value with ordinal number x and with type T. T is
			any enumeration type, or CHAR, INTEGER, or CARDINAL.
			VAL(T,ORD(x)) = x, if x is of type T."

In  other words,  VAL  with a CARDINAL  argument  is  the inverse  of  ORD. The
question is,  what  is ORD(i)  (i being  INTEGER)? It cannot  be the   CARDINAL
representation of the number whose INTEGER representation  is i, since  not all
numbers that have an INTEGER  representation have a CARDINAL representation too
(namely the negative INTEGERs). So, unless one assumes  that ORD is not defined
for all INTEGERs (and there is no  indication in the  report that would support
such an assumption) and  unless one is prepared  to treat INTEGER as  a special
case (different from  enumerationes, CHAR and  CARDINAL, and again there is  no
indication to support that in the report) one has to assume that ORD(MinInt)=0,
ORD(MinInt+1) = 1, ORD(MaxInt)=MaxCard  etc. Consequently,  VAL(INTEGER,c) does
not at all work as intended! (For all other types VAL(T,x) is indeed the "safe"
conversion.)

I agree, that's nonsensical, however that's  what the report says. Fortunately,
no compiler (that I know of) does  it  that way, but assuming VAL(INTEGER,c) to
be the "safe" conversion from CARDINAL  to INTEGER is  relying on all compilers
violating the language report.

Note that Wirth in his later compilers solves the problem in his characteristic
way:  he gives VAL(T,x)  the semantics  that T(x) used  to have  and completely
eliminates "save" type transfers.

> ==
> Barry Cornelius

-- 
Gernot Heiser <heiser@iis.UUCP> Phone:       +41 1/256 23 48
Integrated Systems Laboratory   CSNET/ARPA:  heiser%ifi.ethz.ch@relay.cs.net
ETH Zuerich                     EARN/BITNET: GRIDFILE@CZHETH5A
CH-8092 Zuerich, Switzerland    EUNET/UUCP:  {uunet,mcvax,...}!iis!heiser