Xref: utzoo comp.lang.modula2:667 comp.lang.misc:1118
Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!necntc!linus!philabs!pwa-b!mmintl!franka
From: franka@mmintl.UUCP (Frank Adams)
Newsgroups: comp.lang.modula2,comp.lang.misc
Subject: Re: From Modula to Oberon
Message-ID: <2740@mmintl.UUCP>
Date: 1 Mar 88 00:50:59 GMT
References: <7161@sol.ARPA>
Reply-To: franka@mmintl.UUCP (Frank Adams)
Organization: Multimate International, E. Hartford, CT.
Lines: 22

In article <7161@sol.ARPA> crowl@cs.rochester.edu (Lawrence Crowl) writes:
>[Text by Niklaus Wirth]
>With the proliferation of basic types, a relaxation of compatibility rules
>between them becomes almost mandatory.  To this end, the notion  of type
>inclusion is introduced: a type T includes a type T', if the values  of T'
>are also values of type T. Oberon postulates the following hierarchy:
>	LONGREAL > REAL > LONGINT > INTEGER > SHORTINT

This appears to be a mistake.  I am assuming that these are intended to be
64 and 32 bit reals, and 32, (16 or 32), and 16 bit integers, respectively.

The basic problem is that the values of a 32 bit real do not include the
values of a 32 bit integer.  If one is going to be meticulous enough about
assignments to define type inclusion, one should only make types be included
when they really are.

(If INTEGER is intended to be 32 bits, and LONGINT 64, the problems are even
more serious.  If REAL is intended to be a 64 bit float, the absence of a 32
float is a problem.)
-- 

Frank Adams                           ihnp4!philabs!pwa-b!mmintl!franka
Ashton-Tate          52 Oakland Ave North         E. Hartford, CT 06108