<html><head><base href="x-msg://838/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>I've already made changes to cm3/doc/reference that match the current implementation (no implicit assignability). I'm happy to adjust that to match what we eventually implement.</div><div><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; -webkit-text-decorations-in-effect: none; text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div><span class="Apple-style-span" style="font-size: medium;"><font class="Apple-style-span" color="#0000FF" face="'Gill Sans'"><br></font></span></div></span></span></span></span></span></span></span></span></div></span></span></div><div><div>On 8 Jan 2010, at 13:20, Randy Coleburn wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div lang="EN-US" link="blue" vlink="purple" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div class="Section1"><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Whenever all this is nailed down, someone needs to put together a set of diffs to NELSON SPwM3, and update the reference section in “cm3/doc” and the language posters in “cm3/doc/src_reports”.<o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p> </o:p></span></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; "><b><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Randy Coleburn</span></b><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><br><br><o:p></o:p></span></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0in; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p> </o:p></span></div><div><div style="border-right-style: none; border-bottom-style: none; border-left-style: none; border-width: initial; border-color: initial; border-top-style: solid; border-top-color: rgb(181, 196, 223); border-top-width: 1pt; padding-top: 3pt; padding-right: 0in; padding-bottom: 0in; padding-left: 0in; "><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; ">From:</span></b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; "><span class="Apple-converted-space"> </span>Tony Hosking [mailto:hosking@cs.purdue.edu]<span class="Apple-converted-space"> </span><br><b>Sent:</b><span class="Apple-converted-space"> </span>Friday, January 08, 2010 1:01 PM<br><b>To:</b><span class="Apple-converted-space"> </span>Rodney M. Bates<br><b>Cc:</b><span class="Apple-converted-space"> </span>m3devel<br><b>Subject:</b><span class="Apple-converted-space"> </span>Re: [M3devel] LONGINT, my original proposal<o:p></o:p></span></div></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div><div><div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><span class="apple-style-span"><span gill="" sans'","serif";color:blue'="" style="font-size: 13.5pt; ">We already have much of this, but not all. Notes below...</span></span><span style="font-size: 9pt; font-family: Helvetica, sans-serif; color: black; "><o:p></o:p></span></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 9pt; font-family: Helvetica, sans-serif; color: black; "><o:p> </o:p></span></div></div></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">I am now convinced (Jay will be relieved) that Rodney's proposal is mostly what we want.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">I am looking into making the changes to the current implementation that will bring this into being.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">On 8 Jan 2010, at 11:53, Rodney M. Bates wrote:<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">Here is my orginal LONGINT proposal, from my own disk file. There were one or two<br>aspects of this I quickly changed, either because I changed my mind on something,<br>or realized something was a specification bug. I am working on rediscovering what<br>they were.<br>A proposal for Modula-3 language changes to support an integer type<br>larger than the native size of the target processor.<br><br>This proposal satisfies (I believe) the following principles:<br><br>The static correctness and type analysis of existing code written to<br>the current language definition will not change with the new<br>definition. This also implies that the new language definition will<br>not introduce new type mismatches that would make existing pickles<br>unreadable.<br><br>The runtime semantics and time and space efficiency of existing code<br>written to the current language definition will also not change with<br>the new definition, if the native word size of the implementation does<br>not change. Of course, porting existing code to an implementation<br>with different native word size can change the runtime semantics by<br>changing the supported value range, with or without language change.<br><br>The static type analysis of programs written to the modified language<br>definition will be independent of the implementation, particularly, of<br>the native word size. This prevents inadvertently writing code that<br>is highly nonportable among different native word sizes.<br><br>The new, not-necessarily-native integer type does not extend to<br>certain existing uses of INTEGER and CARDINAL that are of unlikely<br>utility and would add complexity.<br><br>Actual statements about the language are numbered. Comments are<br>indented more deeply, following a numbered item they apply to. Some<br>numbered items are labeled "NO CHANGE", and merely call attention to<br>the lack of a change, where it is relevant or calls for comment.<br><br>Changes to the language proper:<span class="Apple-converted-space"> </span><br><br>1. There is a new builtin type named LONGINT.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">We have this.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">2. FIRST(LONGINT) <= FIRST(INTEGER) and LAST(INTEGER) <= LAST(LONGINT).<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">Currently, direct comparison between LONGINT and INTEGER is not permitted. If it were then this would be true.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "> The intent is that INTEGER will remain as the native integer<br> size on the implemented processor. LONGINT might be bigger, but<br> not necessarily. Typically, on a 32-bit processor, LONGINT<br> would be 64 bits. On a 64-bit processor, it could be 64 or 128.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">This is what we currently have.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">3. There are new literals of type LONGINT, denoted by following a<br> nonempty sequence of digits by either 'l' or 'L'.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">We have this right now.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "> Having distinctly spelled literals preserves Modula-3's clean<br> system of referentially transparent typing, i.e, the type of<br> every expression is determined by the expression alone, without<br> regard to how it is used. The 3 floating point types already<br> follow this principle. Literals of ambiguous type, combined<br> with a system of implicit conversions taken from the context<span class="Apple-converted-space"> </span><br> would create a semantic mess. (e.g. Ada).<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">I wholeheartedly agree!<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "> I believe intuitively that Id, LOCK, and LOOP are not members of<br> FOLLOW(Number), but need to check this mechanically. It would<br> mean that the new literals can not undermine any existing,<br> compilable code.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">The current implementation illustrates that this is not a problem.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">4. LONGINT # INTEGER.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">We have this right now.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "> This is true regardless of whether their ranges are equal. This<br> keeps the typing independent of the implementation. Doing<br> otherwise could be a portability nightmare.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">Agreed.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">5. LONGINT is an ordinal type.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">We have this right now.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "> This means the existing rules of assignability will allow<br> assignment between LONGINT and its subtypes and INTEGER and its<br> subtypes, with the usual runtime value check, when required.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">I will go ahead and implement assignability with the appropriate value checks. This will eliminate the need for explicit ORD/VAL conversions.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">6. Neither LONGINT nor INTEGER is a subtype of the other. <o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">We have this right now.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "> This is true regardless of whether their ranges are equal, in<br> part for the same reason the types are unequal.<br><br> Note that, for ordinal types, assignability doesn't actually use<br> the subtype relation. In fact, the one place I can find in the<br> present language where subtypes matter for ordinal types is in<br> the definition of signatures of operators, etc. In 2.6.1,<br> paragraph 5, operands must have a subtype of the type specified.<br> Keeping LONGINT and INTEGER subtype-unrelated keeps this<br> statement unambiguous and allows easy specification of the<br> operators.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">Agreed.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">7. Prefix operators +, -, and ABS can take an operand having a<br> subtype of LONGINT, in which case, their result has type LONGINT.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">We have this.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">8. Infix operators +, -, DIV, MOD, MIN, and MAX, can accept a pair of<br> operands that are subtypes of a mixture of INTEGER and LONGINT.<br> If either is a subtype of LONGINT, the result has type LONGINT,<br> otherwise INTEGER. The result is correct (i.e., no overflow<br> occurs) if the result value is a member of the result type.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">I am uneasy about mixing parameter types in this way.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">I note that current implementation of these operations permit overflow because the overflow result is still a member of the result type.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "> With assignment between different subranges, Modula-3 takes the<br> view that this is not an implied type conversion at all.<br> Instead, the rules have the effect that if the value is a member<br> of the LHS type, then it's OK. I think this is a brilliant<br> piece of language design. Compare to the many pages of<br> description that C++ and Java require to define implied type<br> conversions in assignments, and they only have a few<br> integer-like types, whereas current Modula-3 has, typically,<br> ~2^31 subrange types involved. It's also less<br> implementation-oriented, because it doesn't appeal to bit<br> representations, etc.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">Agreed.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "> I resisted allowing mixed sizes of operands, until I realized we<br> can do the same thing with operators as with assignment, i.e.,<br> just require result values to be in range, without calling<br> anything an implied type conversion.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">This is part of my uneasiness. I guess I am willing to accept that the type of the operation is the maximal type of its operands.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "> A compiler can implement this by just doing the arithmetic in<br> the same size as the result type. This means if both operands<br> are subtypes of INTEGER, (which will always be the case with<br> existing code,) then the native arithmetic will be used, without<br> loss of efficiency.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">OK. I think I see how to implement this...<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">9. Relational operators =, #, <, >, <=, and >=, can accept a pair of<br> operands that are subtypes of a mixture of INTEGER and LONGINT.<br><br> Again, a compiler can figure out how to generate code for this,<br> with no loss of efficiency when both are subtypes of INTEGER.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">Same as above. I think it can be implemented.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">10. The first parameter to FLOAT can have a subtype of either INTEGER<br> or LONGINT.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">We already support this.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">11. FLOOR, CEILING, ROUND, and TRUNC have an optional second<br> parameter, which can be either LONGINT or INTEGER, and which<br> specifies the result type of the operation. If omitted, it<br> defaults to INTEGER. The result has this type.<br><br> The default preserves existing code.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">Already supported.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">12. The result type of ORD is LONGINT if the parameter is a subtype of<br> LONGINT, otherwise it remains INTEGER.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">The current implementation uses ORD as the mechanism for checked conversion from LONGINT to INTEGER.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">If we change assignability as you suggest then we no longer need explicit conversion so we can support the semantics you describe.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "> There is really not much programmer value in applying ORD to a<br> subtype of either INTEGER or LONGINT, since this is just an<br> identity on the value. It would provide an explicit, widening<br> type conversion, and NARROW won't accomplish this, because it is<br> only defined on reference types. However, this rule provides<br> consistency, and maybe would simplify some machine-generated<br> source code scheme.<br><br> This fails to support an implementation's effort to expand the<br> number of values of an enumeration type beyond the current<br> implied limitation of the positive native word values. How<br> tough.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">I see no problem with the maximum enumeration type values being restricted to natural integers.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">13. The first parameter to VAL can be a subtype of either INTEGER or<br> LONGINT.<br><br> Beside generalizing the existing uses of VAL, this also allows<br> explicit conversions between LONGINT and INTEGER, if there is<br> any need for them.<span class="apple-tab-span"></span><o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">The current implementation uses VAL as the mechanism for conversion from INTEGER to LONGINT.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">Just like ORD, if we change assignability as you suggest then we can support your semantics as an explicit conversion.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">14. (NO CHANGE) The safe definitions of INC and DEC do not change.<br><br> As a consequence of the changes to +, -, ORD, and VAL, the<br> existing equivalent WITH-statement definition will generalize to<br> mixes of any ordinal type for the first parameter and a subtype<br> of either INTEGER or LONGINT for the second.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">[Note that I just fixed a bug in the implementation of INC/DEC to make it properly equivalent to the WITH-statement definition.]<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">The current implementation does not allow mixing INTEGER/LONGINT operand and increments.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><blockquote style="margin-top: 5pt; margin-bottom: 5pt; "><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">15. There is a new builtin type named LONGCARD. It "behaves just<br> like" (but is not equal to) [0..LAST(LONGINT)].<br><br> The current CARDINAL has an interesting history. Originally, it<br> was just a predefined name for the type [0..LAST(INTEGER)]. It<br> was later changed to be "just like" the subrange, i.e., the two<br> are not the same type, but have the same properties in every<br> other respect. The only reason for the change had to do with<br> reading pickles, which are completely defined and implemented as<br> library code. The change did affect the type analysis of the<br> language, nevertheless.<br><br> We should preserve this property for LONGCARD too.<o:p></o:p></div></div></blockquote><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">Currently there is no implementation of LONGCARD. I argue that we don't need LONGCARD (since, as discussed below, NUMBER should stay typed as CARDINAL), unless LONGCARD is needed for pickles... Rodney?<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">16. Neither LONGINT, nor any subtype thereof, can be used as the index<br> type of an array type.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">This is the current implementation.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "> One could think about allowing this, but it would require a lot<br> of other things to be generalized, and is unlikely to be of much<br> use. <o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">Agreed.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "> After the world's having had to learn twice the hard way, what a<br> mess that comes from addresses that are larger than the native<br> arithmetic size, we are unlikely to see it again. So, the only<br> ways a longer LONGINT index type could be of any use are: 1)<br> arrays of elements no bigger than a byte, that occupy more than<br> half the entire addressable memory, and you want to avoid<br> negative index values, or 2) arrays of packed elements less than<br> byte size that occupy at least one eighth of the memory (or some<br> mixture thereof). All these cases also can occur only when<br> using close to the maximum addressable virtual memory. Not very<br> likely.<br><br> If you really need 64-bit array subscripts, you will have to use<br> an implementation whose native size is 64 bits.<br><br> This also avoids generalizing SUBARRAY, several procedures in<br> required interface TEXT, more extensive generalization of<br> NUMBER, etc.<br><br>17. Neither LONGINT, nor any subtype thereof, can be used as the base<br> type of a set type.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">This is the current implementation.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "> This is similar to the array index limitation. Sets on base<br> types of long range are very unlikely, as they would be too bit.<br> The assignability rules should make subranges of INTEGER<br> relatively easy to use as set base types instead of short<br> subranges of LONGINT. This also obviates generalizing IN.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">Agreed.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">18. The result type of NUMBER is LONGCARD if its parameter is a<br> subtype of LONGINT, otherwise INTEGER, as currently.<br><br> NUMBER has always had the messy problem that its correct value<br> can lie beyond the upper limit of its result type CARDINAL.<br> Fortunately, it is rare to use it in cases where this happens.<br> The expanded definition still has the equivalent problem, but it<br> seems even less likely to actually happen.<br><br> One could consider making NUMBER always return a LONGCARD, which<br> would fix the problem for parameters that are INTEGER, but that<br> would not preserve existing semantics or efficiency.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">The current implementation leaves the result of NUMBER as CARDINAL. The reasoning for this is that NUMBER is only really useful for dealing in the sizes of arrays, etc. (which as noted above retain bounds that can be expressed in natural INTEGERs).<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">19. (NO CHANGE) BITSIZE, BYTESIZE, ADRSIZE, and TYPECODE are unchanged.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">This is the current implementation. <o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div></div><blockquote style="margin-top: 5pt; margin-bottom: 5pt; "><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br> If you really need 64-bit sizes or typecodes, you will have to<br> use an implementation whose native size is 64 bits.<o:p></o:p></div></div></blockquote><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">Agreed.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">20. The statement that the upperbound of a FOR loop should not be<br> LAST(INTEGER) also applies to LAST(LONGINT).<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">Agreed.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "> Note that the existing definition of FOR otherwise generalizes<br> to LONGINT without change.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">The current implementation does not permit the range values to be different types (both must be INTEGER or LONGINT), and the step value must also match. Will we permit any mixing of values? If so, I assume that we use the maximal type of the expressions (LONGINT if any one is LONGINT, INTEGER otherwise).<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">Changes to required (AKA standard) interfaces:<br><br>21. (NO CHANGE). The INTEGER parameters to Word.Shift and<br> Word.Rotate, and the CARDINAL parameters of Word.Extract and<br> Word.Insert are unchanged.<br><br> These are bit numbers. There is no need for a longer range.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">This is the current implementation.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">22. There is a new required interface LongWord. It almost exactly<br> parallels Word, except 1) LongWord.T = LONGINT, and 2) it contains<br> new functions ToWord and FromWord, that conversion between the two<br> types, using unsigned interpretations of the values. ToInt may<br> produce a checked runtime error, if the result value is not in the<br> range of an unsigned interpretation of INTEGER.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">This is the current implementation, but we do not support ToWord and FromWord. Why do we need these?<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "> Word.T = INTEGER, so LongWord.T should = LONGINT, for<br> consistency. This means simple assignability tests and<br> assignments between the types will use signed interpretations.<br> So different functions are needed to do size changes with<br> unsigned interpretation.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">This is the current implementation.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">23. (NO CHANGE) The Base and Precision values in required interfaces<br> Real, LongReal, and Extended, keep the type INTEGER.<br><br> There is no need for increased value range here.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">This is the current implementation.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">24. (NO CHANGE) Float.Scalb, which has a parameter of type INTEGER,<br> and Float.ILogb, whose result type is INTEGER, do not have LONGINT<br> counterparts.<br><br> It is difficult to imagine these values needing greater range.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">This is the current implementation.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">25. Fmt has a new function LongInt, parallel to Int, but replacing<br> INTEGER by LONGINT.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">We have this.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">26. Lex has a new function LongInt, parallel to Int, but replacing<br> INTEGER by LONGINT.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">We have this.<br><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">27. There is a new required interface named LongAddress. It is UNSAFE<br> and contains procedures that are equivalents for the 5 unsafe<br> ADDRESS arithmetic operations, with LONGINT substituted in place<br> of INTEGER in their signatures. These are given in 2.7 and<br> include a +, two overloaded meanings of -, an INC, and a DEC.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">We currently do not support this.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "> It is remotely conceivable that there could be a target whose<br> native address size is longer than its native integer size<br> (unlike the reverse.) In such a case, these operations might be<br> needed.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">Until we see the need I hesitate to implement it.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "> Four of them could be accommodated by just generalizing the<br> INTEGER parameter to allow either INTEGER or LONGINT. The<br> remaining operator subtracts two ADDRESS operands and returns an<br> INTEGER. This can't be generalized using Modula-3's existing<br> pattern of overload resolution of builtin operations.<br> Redefining it to always do LONGINT arithmetic would violate the<br> existing efficiency criterion. Two separate operations are<br> needed.<br><br> This solution avoids complexity in the language proper, while<br> still accommodating a rare requirement. It could probably be<span class="Apple-converted-space"> </span><br> left unimplemented unless/until such a target actually happens.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">Agreed.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">Changes to useful interfaces:<span class="Apple-converted-space"> </span><br><br>28. IO has new procedures PutLongInt and GetLongInt, parallel to<br> PutInt and GetInt.<o:p></o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; ">I just added these.<o:p></o:p></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "> I have not looked systematically at all the useful interfaces<br> for other places that use CARDINAL and INTEGER and might need to<br> be generalized. (Can anyone point to a tool that will grep<br> files in .ps or .pdf format, or something equivalent?)<br><br> Note that changes in nonrequired interfaces should be<br> implementable just by writing new/modified library code, without<br> additional help from the compiler.<o:p></o:p></div></div></div><div style="margin-top: 0in; margin-right: 0in; margin-bottom: 0.0001pt; margin-left: 0.5in; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div></div></span></blockquote></div><br></body></html>