Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!pdn!oz!alan
From: alan@oz.nm.paradyne.com (Alan Lovejoy)
Newsgroups: comp.lang.modula2
Subject: Re: HELP with LONGINT...
Message-ID: <6189@pdn.paradyne.com>
Date: 14 Jun 89 15:25:02 GMT
References: <12900003@uxh.cso.uiuc.edu> <1249@infbs.UUCP>
Sender: news@pdn.paradyne.com
Reply-To: alan@oz.paradyne.com (Alan Lovejoy)
Organization: AT&T Paradyne, Largo, Florida
Lines: 57

In article <1249@infbs.UUCP> neitzel@infbs.UUCP (Martin Neitzel) writes:
>The compiler is correct.  Only according to THE BOOK, of course :-)
>
>Frans van Otten mentioned a week ago that PIM3 introduces LONGINT and
>LONGREAL as standard types, but ignores them in the rest of the
>report.  There are no operators for them, they are not compatible or
>assignment compatible to anything, and you don't have any denotations
>for LONG...-literals.
>
>[Not in PIM4, either.]

There are only two possible interpretations of these facts:

1) Values of type LONGINT or LONGREAL are essentially like values of type
WORD:  you  can't operate on them.  Unlike WORDs, they of course are not
compatible with actual parameters whose types are not exactly the same.

This interpretation is probably NOT what was intended.

2) Wirth intended that everything PIM2 says about INTEGERs and REALs should
also apply to LONGINTs and LONGREALs.  INTEGER and REAL should be treated
as "subranges" of LONGINT and LONGREAL, respectively.  Hence, INTEGER and
LONGINT, and REAL and LONGREAL, are completely compatible with the exception
of VAR parameters.  An implementation would not be required to use different
storage sizes for the "LONG-" and "short" types.  Storage size could depend 
upon the subrange limits in a way that is transparent to the programmer
(e.g, all parameters could be passed using the maximum storage size, regardless
of subrange limits). 

This second interpretation is supported by the following considerations:

a) The only other interpretation is almost certainly not what was intended.
b) Since no functionality for these LONG types is specified, the most natural
   interpretation is that they should have the same functionality as the 
   "short" types.                                   
c) Conceptually, the "short" types are subranges of the LONG types.  Subranges
   are highly (but not completely) compatible with the base type and with 
   each other.  The only clear incompatibility involves actual and formal
   VAR parameters, which must have EXACTLY the same type.
d) The compatibility/conversion rules between the "short" and LONG types
   were not specified.  Compatibility and conversion rules between subranges
   and base types ARE specified, however.  Using those as a model does not
   require introducing new features into the language.  Interpreting LONGs
   as completely separate types DOES require new features.
e) The language does NOT require that a subrange have the same storage size
   as the base type.  But even if an implemenation used only a byte of
   storage for CARDINAL[0..255] but two bytes for CARDINAL[0..65535],
   it would still be required that the two types be fully compatible in all
   cases except VAR parameters.
f) This interpretation results in the most natural, useful and usable 
   implementation.


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.