🚀 go-pugleaf

Last Saturday, my colleague Randy Bush wrote to this newsgroup thus:
*In article <35093@apple.Apple.COM> lins@Apple.COM (Chuck Lins) writes:
*> DEFINITION MODULE Items;
*> TYPE Item;
*> END Items.
*> ...
*> PROCEDURE CharCompare (left:Item; right:Item): Relation;
*> VAR leftChar : CHAR;
*> BEGIN
*
*But, the type transfer CHAR(left) requires that left occupy the same number of
*bits as a CHAR, and this would not seem to be the case here, where left would
*seem to be a pointer.
*Also, the importing module would seem to be trying to peek through the opaque
*if it tried something like CHAR(left).
*>This all compiles fine under JPI's TopSpeed Modula-2.
*This may not be to their credit.

I guess strictly speaking PIM does not say that 'left' needs to occupy the
same number of bits as CHAR.   However, this has been the case with some
implementations, whereas others allow more flexibility.   This is the case
with JPI TopSpeed Modula-2, where the size of the expression may be
less-than/equal-to/greater-than the size of the result-type of the type
transfer.   With TopSpeed Modula-2 a pointer occupies 4 bytes and so the
type transfer (aka a cast) "CHAR(left)" would deliver one of the bytes of
these four.

My guess is that TopSpeed Modula-2 would not allow "CHAR(left)" to appear
in an importing module, but I have not checked this.
==
Barry Cornelius
==
Computer Science Group, School of Engineering and Applied Science,
University of Durham, Durham, DH1 3LE, England
              JANET:       Barry.Cornelius@uk.ac.durham
              Internet:    Barry.Cornelius%durham.ac.uk@cunyvm.cuny.edu
              UUCP:        ...ukc!cs.nott.ac.uk!bjc
              BITNET/EARN: Barry.Cornelius%DURHAM@AC.UK
Tel: Durham (091 or +44 91) 374 2638, Secretary: 374 2630, Fax: 374 3741