<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Do you recall why CARDINAL is defined to behave like [0..LAST(INTEGER)] instead of [0..16_FFFFFFFF]?<div><br></div><div><br><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><font class="Apple-style-span" color="#0000FF"><font class="Apple-style-span" face="Gill Sans"><span class="Apple-style-span" style="color: rgb(0, 0, 255); font-family: 'Gill Sans'; "><span class="Apple-style-span" style="color: rgb(0, 0, 255); font-family: 'Gill Sans'; ">Antony Hosking</span></span></font></font><font class="Apple-style-span" face="Gill Sans"><span class="Apple-style-span" style="font-family: 'Gill Sans'; "><span class="Apple-style-span" style="font-family: 'Gill Sans'; "><span class="Apple-converted-space"> </span>|<span class="Apple-converted-space"> </span></span></span><span class="Apple-style-span" style="font-family: 'Gill Sans'; "><span class="Apple-style-span" style="font-family: 'Gill Sans'; ">Associate Professor</span></span><span class="Apple-style-span" style="font-family: 'Gill Sans'; "><span class="Apple-style-span" style="font-family: 'Gill Sans'; "> | Computer Science | Purdue University</span></span></font></div><div><font class="Apple-style-span" face="GillSans-Light"><span class="Apple-style-span" style="font-family: GillSans-Light; ">305 N. University Street | West Lafayette | IN 47907 | USA</span></font></div><div><font class="Apple-style-span" color="#0000FF" face="Gill Sans"><span class="Apple-style-span" style="color: rgb(0, 0, 255); font-family: 'Gill Sans'; "><span class="Apple-style-span" style="color: rgb(0, 0, 255); font-family: 'Gill Sans'; ">Office</span></span></font><font class="Apple-style-span" face="GillSans-Light"><span class="Apple-style-span" style="font-family: GillSans-Light; "><span class="Apple-style-span" style="font-family: GillSans-Light; "> +1 765 494 6001 |<span class="Apple-converted-space"> </span></span></span></font><font class="Apple-style-span" color="#0000FF" face="Gill Sans"><span class="Apple-style-span" style="color: rgb(0, 0, 255); font-family: 'Gill Sans'; "><span class="Apple-style-span" style="color: rgb(0, 0, 255); font-family: 'Gill Sans'; ">Mobile</span></span></font><font class="Apple-style-span" face="GillSans-Light"><span class="Apple-style-span" style="font-family: GillSans-Light; "><span class="Apple-style-span" style="font-family: GillSans-Light; "><span class="Apple-converted-space"> </span>+1 765 427 5484</span></span></font></div><div><font class="Apple-style-span" face="GillSans-Light"><br class="khtml-block-placeholder"></font></div></span></span></span></span></span></span></span><br class="Apple-interchange-newline"></span></div></span></span><br class="Apple-interchange-newline">
</div>
<br><div><div>On 9 Jan 2010, at 17:15, Rodney M. Bates wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><br><br>Tony Hosking wrote: (excerpted)<br><blockquote type="cite">........................................<br></blockquote><blockquote type="cite"><blockquote type="cite">2. FIRST(LONGINT) <= FIRST(INTEGER) and LAST(INTEGER) <= LAST(LONGINT).<br></blockquote></blockquote><blockquote type="cite">Currently, direct comparison between LONGINT and INTEGER is not permitted. If it were then this would be true.<br></blockquote><br><br>I remember there was some vexing problem about what the result type<br>should be for FIRST and LAST, but not the details. It seems to<br>me now that the only thing that makes any sense is to preserve the<br>existing rule that it is the base type of the argument type.<br>This is really necessary to preserve existing semantics of the<br>language and of existing code.<br><br>This original proposal seems to be silent on the matter, which I suppose<br>means I intended it as a NO CHANGE. I guess, if<br>mixed relations are allowed, then I can't think of a problem<br>with this. Even if mixed relations are disallowed, this range<br>constraint could be expressed with explicit conversions, I suppose.<br><br>.......................................................................<br><br><blockquote type="cite"><blockquote type="cite">15. There is a new builtin type named LONGCARD. It "behaves just<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> like" (but is not equal to) [0..LAST(LONGINT)].<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> The current CARDINAL has an interesting history. Originally, it<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> was just a predefined name for the type [0..LAST(INTEGER)]. It<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> was later changed to be "just like" the subrange, i.e., the two<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> are not the same type, but have the same properties in every<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> other respect. The only reason for the change had to do with<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> reading pickles, which are completely defined and implemented as<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> library code. The change did affect the type analysis of the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> language, nevertheless.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> We should preserve this property for LONGCARD too.<br></blockquote></blockquote><blockquote type="cite">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?<br></blockquote><br>LONGCARD is needed for pickles (and for no other reason, that I can<br>think of). The problem is that if a record or object has a field of<br>type [0..LAST(LONGCARD)], the actual value of LAST(LONGCARD) causes<br>the type to be different on different target machines, making a pickle<br>written on, say a 32-bit machine unreadable on a 64-bit machine.<br>LONGCARD can be treated as the same type regardless of word size,<br>allowing the automatic size changes pickles already does for INTEGER,<br>CARDINAL, and LONGINT to extend to this subrange too.<br><br>(Note: If you try to extend this size-changing by pickles to arbitrary<br>subranges that use FIRST/LAST/NUMBER in their bounds expressions, you<br>are jumping head first into a tar pit. I've thought about it just enough<br>to conclude I wanted to step back.)<br><br>.......................................................................<br><br><blockquote type="cite"><blockquote type="cite">20. The statement that the upperbound of a FOR loop should not be<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> LAST(INTEGER) also applies to LAST(LONGINT).<br></blockquote></blockquote><blockquote type="cite">Agreed.<br></blockquote><blockquote type="cite"><blockquote type="cite"> Note that the existing definition of FOR otherwise generalizes<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> to LONGINT without change.<br></blockquote></blockquote><blockquote type="cite">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).<br></blockquote><blockquote type="cite"><br></blockquote><br>I think allowing mixtures here is going too far. Moreover, the existing<br>rule for FOR already requires the same base type for the two bounds, unlike<br>the assignability rule for operators, so unless we change an existing<br>language rule here, this form of mixing is not allowed.<br><br>Note that the step value is "integer-valued" unconditionally, i.e.,<br>even if the bounds have, say, an enumeration type. Taken literally, I<br>would say this would allow its type to be INTEGER, LONGINT, or any subrange<br>thereof. Perhaps on a tiny 8-bit embedded processor, this could have<br>a use.<br><br>......................................................................<br><br><br><blockquote type="cite"><blockquote type="cite">22. There is a new required interface LongWord. It almost exactly<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> parallels Word, except 1) LongWord.T = LONGINT, and 2) it contains<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> new functions ToWord and FromWord, that conversion between the two<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> types, using unsigned interpretations of the values. ToInt may<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> produce a checked runtime error, if the result value is not in the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> range of an unsigned interpretation of INTEGER.<br></blockquote></blockquote><blockquote type="cite">This is the current implementation, but we do not support ToWord and FromWord. Why do we need these?<br></blockquote><br>All the operations in Word apply an unsigned interpretation to the bits<br>of the word, whereas the operators and functions in the language apply<br>signed. Unsigned expansion is different(zero extend) from signed (sign<br>extend). FromWord would do the unsigned, while VAL would do the signed.<br><br>Similarly, for contracting, the value range check is different. Signed<br>means leftmost 33 bits all equal to each other. Unsigned means leftmost<br>32 are all zero.<br><br><blockquote type="cite"><blockquote type="cite"> Word.T = INTEGER, so LongWord.T should = LONGINT, for<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> consistency. This means simple assignability tests and<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> assignments between the types will use signed interpretations.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> So different functions are needed to do size changes with<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> unsigned interpretation.<br></blockquote></blockquote><blockquote type="cite">This is the current implementation.<br></blockquote><blockquote type="cite"><br></blockquote></div></blockquote></div><br></div></body></html>