<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<base href="x-msg://1374/">
<style>
<!--
 /* Font Definitions */
 @font-face
        {font-family:Helvetica;
        panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
        {font-family:Courier;
        panose-1:2 7 4 9 2 2 5 2 4 4;}
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
span.apple-style-span
        {mso-style-name:apple-style-span;}
span.apple-converted-space
        {mso-style-name:apple-converted-space;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page Section1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
        {page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body 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>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Tony:<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I’m sorry, I missed the fact that you changed the type to “Integer”
vs. “INTEGER” and defined “Integer” to be “INTEGER”
or “LONGINT”.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I agree that with your changes everything is in order now, even
though I would prefer different names.  <b>Nevertheless, I can be “happy”
with this state of affairs.<o:p></o:p></b></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I am confused though by your last set of statements, namely:<o:p></o:p></span></p>

<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>

<p class=MsoNormal style='margin-left:.5in'>>I don't think we need to do
this, assuming you understand what I have said above.<o:p></o:p></p>

<p class=MsoNormal style='margin-left:.5in'>><o:p> </o:p></p>

<p class=MsoNormal style='margin-left:.5in'>>ORD(x: INTEGER): LONGINT<o:p></o:p></p>

<p class=MsoNormal style='margin-left:.5in'>>ORD(x: LONGINT): INTEGER<o:p></o:p></p>

<p class=MsoNormal style='margin-left:.5in'>>ORD(x: Enumeration): INTEGER<o:p></o:p></p>

<p class=MsoNormal style='margin-left:.5in'>>ORD(x: Subrange):
Base(Subrange)<o:p></o:p></p>

<p class=MsoNormal style='margin-left:.5in'>><o:p> </o:p></p>

<p class=MsoNormal style='margin-left:.5in'>>ORD(n) = VAL(n, T) = n if n is
an integer of type T = INTEGER or T = LONGINT.<o:p></o:p></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Didn’t you mean:<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>                ORD(x:INTEGER):
<b>INTEGER</b><o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>                ORD(x:LONGINT):
<b>LONGINT</b><o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Also, in case anyone is interested, the current HEAD fails to
compile the following packages on Windows Vista:<o:p></o:p></span></p>

<p class=MsoNormal style='text-indent:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>"m3-libs\m3core"<o:p></o:p></span></p>

<p class=MsoNormal style='text-indent:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>"m3-libs\libm3"<o:p></o:p></span></p>

<p class=MsoNormal style='text-indent:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>"m3-tools\m3tk"<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>So some recent changes have caused a problem.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Regards,<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Randy<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>

<p class=MsoNormal style='margin-left:.5in'><b><span style='font-size:10.0pt;
font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> Tony Hosking [mailto:hosking@cs.purdue.edu]
<br>
<b>Sent:</b> Monday, January 11, 2010 10:40 PM<br>
<b>To:</b> Randy Coleburn<br>
<b>Cc:</b> m3devel<br>
<b>Subject:</b> Re: [M3devel] the LONGINT proposal<o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>

<div>

<div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span class=apple-style-span><span
style='font-size:13.5pt;font-family:"Helvetica","sans-serif";color:black'>On 11
Jan 2010, at 22:11, Randy Coleburn wrote:</span></span><span style='font-size:
9.0pt;font-family:"Helvetica","sans-serif";color:black'><o:p></o:p></span></p>

</div>

</div>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>

<div>

<div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>Tony et al:</span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>Yes, I think I am supporting
the “status quo”, which seems to be Rodney’s proposal, minus
mixed arithmetic and checked assignability; plus my discomfort with ORD/VAL as
you state.  (See discussion below to the end for more on this
“discomfort” and the problem I see with converting from LONGINT to
INTEGER.)</span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>When I said we don’t
know the range of LONGINT, I meant that in the context of documenting the
language we weren’t specifying this range; rather it is
implementation-defined.  Indeed, yes you must be able to do FIRST(LONGINT)
and LAST(LONGINT) at runtime to determine the actual range.</span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>Tony you stated in your
response that the 2<sup>nd</sup><span class=apple-converted-space> </span>parameter
(the type) of VAL is optional.  I was not aware that this parameter can be
defaulted.  Where is this stated in the language spec?</span><o:p></o:p></p>

</div>

</div>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'>Sorry, my error.  I realised
after writing that I had mis-spoken.<o:p></o:p></p>

</div>

<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>

<div>

<div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> I’ve only scanned
your HTML reference briefly, but it seems to me that even there it still says
that ORD/VAL convert between <b><u>enumerations</u></b> and INTEGERs,
not LONGINTs.</span><o:p></o:p></p>

</div>

</div>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'>That wording is exactly the same as
it has always been.  Here is the diff from the original specification
(before LONGINT):<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>

</div>

<div>

<div>

<p class=MsoNormal style='margin-left:.5in'>55,56c55,56<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><        
      <span class=apple-style-span><span style='font-size:9.0pt;
font-family:Courier'>ORD  (element: Ordinal): INTEGER</span></span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><        
      <span class=apple-style-span><span style='font-size:9.0pt;
font-family:Courier'>VAL  (i: INTEGER; T: OrdinalType): T</span></span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'>---<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'>>        
      <span class=apple-style-span><span style='font-size:9.0pt;
font-family:Courier'>ORD  (element: Ordinal): Integer</span></span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'>>        
      <span class=apple-style-span><span style='font-size:9.0pt;
font-family:Courier'>VAL  (i: Integer; T: OrdinalType): T</span></span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'>74c74<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'>< If <span
class=apple-style-span><span style='font-size:9.0pt;font-family:Courier'>n</span></span> is
an integer, <span class=apple-style-span><span style='font-size:9.0pt;
font-family:Courier'>ORD(n) = VAL(n, INTEGER) = n</span></span>.<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'>---<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'>> If <span
class=apple-style-span><span style='font-size:9.0pt;font-family:Courier'>n</span></span> is
an integer of type <span class=apple-style-span><span style='font-size:9.0pt;
font-family:Courier'>T</span></span>, <span class=apple-style-span><span
style='font-size:9.0pt;font-family:Courier'>ORD(n) = VAL(n, T) = n</span></span>.<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>

</div>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'>Notice that all that I have changed
is to allow ORD to return INTEGER or LONGINT, depending on the type of the
element.  And VAL simply takes an INTEGER or LONGINT and converts to an
Ordinal type T.<o:p></o:p></p>

</div>

<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>

<div>

<div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> Are we going to allow
LONGINT to be an enumeration?  If so, then why not go full bore and just
make INTEGER a subrange of LONGINT?  (I don’t favor this.)</span><o:p></o:p></p>

</div>

</div>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'>No, enumerations map only onto
INTEGER.<o:p></o:p></p>

</div>

<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>

<div>

<div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span class=apple-style-span><span
style='font-size:11.5pt;font-family:"Calibri","sans-serif";color:#1F497D'>Alternately,
if you want to use ORD/VAL for the LONGINT conversions, could we at least
change 2.2.1 to say that ORD/VAL convert between <b><u>ordinal types</u></b>,
since enumerations are defined as an ordinal type and LONGINT falls into the
category of an ordinal type, but not an enumeration type?  Indeed, the
syntax definition of ORD/VAL seem to bear out this fact even though the text
references “enumerations” (see 4<sup>th</sup> major paragraph
in 2.2.1, “The operators ORD and VAL convert between …”).</span></span><o:p></o:p></p>

</div>

</div>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'>I don't want to make wholesale
changes to the reference that were not there in the first place.  ORD
applied to and INTEGER has always been the identity operation.<o:p></o:p></p>

</div>

<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>

<div>

<div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> The syntax of ORD/VAL
is:</span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in;text-indent:.5in'><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>ORD 
(element:<span class=apple-converted-space> </span><b>Ordinal</b>): Integer</span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in;text-indent:.5in'><span
style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>VAL 
(i: Integer; T:<span class=apple-converted-space> </span><b>OrdinalType</b>):
T</span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>and, if n is a integer of
type T, ORD(n) = VAL(n, T) = n.</span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><b><span style='font-family:"Calibri","sans-serif";
color:#1F497D'>BTW:  I think the above identity should say that n is a<span
class=apple-converted-space> </span><u>non-negative</u><span
class=apple-converted-space> </span>integer!</span></b><o:p></o:p></p>

</div>

</div>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'>Huh?  No, that is not the
case.  It is only non-negative for enumerations which count from 0.<o:p></o:p></p>

</div>

<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>

<div>

<div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> So, using these, you
propose one would write</span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>               
longInt := VAL(int, LONGINT);</span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>               
int := ORD(longInt)</span><o:p></o:p></p>

</div>

</div>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'>No,<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'>longint := VAL(integer, LONGINT)<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'>integer := VAL(longint, INTEGER)<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'>int := ORD(int)<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'>longint := ORD(longint)<o:p></o:p></p>

</div>

<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>

<div>

<div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>then, the identity
doesn’t exactly match up unless you allow ORD(longInt) to return a
LONGINT, but then if you do that the signature of ORD must be dependent on its
argument type (either INTEGER or LONGINT; note that enumerations and INTEGER
subranges also yield type INTEGER).  </span><o:p></o:p></p>

</div>

</div>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'>This captures the identities
precisely, which is why I reverted to the original formulation.<o:p></o:p></p>

</div>

<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>

<div>

<div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>Therefore, in the case of
argument LONGINT, the type of the LHS of ORD must be a LONGINT; and the LHS
type must be INTEGER when the argument is INTEGER, unless you allow checked
assignability, in which case why do you need ORD in the first place?</span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>IMO, ORD/VAL make more sense
in the case of enumerations.  For example:</span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>               
Color = (Red, Blue, Green);</span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>               
ORD(Color.Blue) = 1</span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>               
VAL(1, Color) = Color.Blue</span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>(Note that the identity
doesn’t apply here since n isn’t an integer when applied to ORD, or
to the result of VAL.)</span><o:p></o:p></p>

</div>

</div>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'>Yes, of course, ORD/VAL are there
to allow mapping of enumerations to INTEGER.  But, for general consistency
any integer can have ORD applied to it, and any integer can be mapped to its
own type.<o:p></o:p></p>

</div>

<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>

<div>

<div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> I think I saw later in
one of the commit messages or replies to Jay that you propose to drop use of
ORD with LONGINT and just use VAL, as in:</span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>               
longInt := VAL(int, LONGINT);</span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>               
int := VAL(longInt, INTEGER);</span><o:p></o:p></p>

</div>

</div>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'>That is what is now implemented.<o:p></o:p></p>

</div>

<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>

<div>

<div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>but the second form would
violate the signature of VAL, which requires an INTEGER as the first argument.</span><o:p></o:p></p>

</div>

</div>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'>No, notice that VAL takes an
Integer which can be INTEGER or LONGINT typed.<o:p></o:p></p>

</div>

<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>

<div>

<div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> <span
class=apple-style-span>I guess my heartburn with using ORD/VAL for LONGINT
conversions stems from fact that before LONGINT, enumerations, subranges, and
INTEGER all had the same maximum range and NELSON states that ORD/VAL are for
conversions between enumerations (aka ordinals) and integers.  Note that
NELSON uses lowercase “integers” (should really be
“non-negative integers”) so I guess this could mean all
non-negative integers, whether representable as INTEGER or LONGINT, but then
there was no LONGINT when NELSON’s book came out.  </span></span><span
class=apple-style-span><b><span style='font-family:"Calibri","sans-serif";
color:#1F497D'>Also, before LONGINT, ORD could not cause a checked runtime
error.</span></b></span><o:p></o:p></p>

</div>

</div>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'>ORD now can never cause a checked
runtime error, just as with Nelson.<o:p></o:p></p>

</div>

<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>

<div>

<div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> </span><span
class=apple-style-span><span style='font-family:"Calibri","sans-serif";
color:#1F497D'>So, at this point, to summarize, I think you are advocating:</span></span><o:p></o:p></p>

</div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><span
style='font-family:"Calibri","sans-serif";color:#1F497D'>1.</span><span
style='font-size:7.0pt;color:#1F497D'>     <span
class=apple-converted-space> </span></span><span style='font-family:"Calibri","sans-serif";
color:#1F497D'>Distinct types INTEGER and LONGINT.</span><o:p></o:p></p>

</div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><span
style='font-family:"Calibri","sans-serif";color:#1F497D'>2.</span><span
style='font-size:7.0pt;color:#1F497D'>     <span
class=apple-converted-space> </span></span><span style='font-family:"Calibri","sans-serif";
color:#1F497D'>LONGINT is an ordinal type, but cannot be used as the index type
for an array.</span><o:p></o:p></p>

</div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><span
style='font-family:"Calibri","sans-serif";color:#1F497D'>3.</span><span
style='font-size:7.0pt;color:#1F497D'>     <span
class=apple-converted-space> </span></span><span style='font-family:"Calibri","sans-serif";
color:#1F497D'>Enumerations are still constrained to no more than
NUMBER(CARDINAL) total values, i.e., (LAST(INTEGER)+1).</span><o:p></o:p></p>

</div>

</div>

</div>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'>

<div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><span
style='font-family:"Calibri","sans-serif";color:#1F497D'>4.</span><span
style='font-size:7.0pt;color:#1F497D'>     <span
class=apple-converted-space> </span></span><span style='font-family:"Calibri","sans-serif";
color:#1F497D'>No mixed arithmetic between INTEGER and LONGINT; require
explicit conversions.</span><o:p></o:p></p>

</div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><span
style='font-family:"Calibri","sans-serif";color:#1F497D'>5.</span><span
style='font-size:7.0pt;color:#1F497D'>     <span
class=apple-converted-space> </span></span><span style='font-family:"Calibri","sans-serif";
color:#1F497D'>No mixed comparisons between INTEGER and LONGINT; require
explicit conversions.</span><o:p></o:p></p>

</div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><span
style='font-family:"Calibri","sans-serif";color:#1F497D'>6.</span><span
style='font-size:7.0pt;color:#1F497D'>     <span
class=apple-converted-space> </span></span><span style='font-family:"Calibri","sans-serif";
color:#1F497D'>Allow VAL to convert INTEGER to LONGINT.</span><o:p></o:p></p>

</div>

</div>

</div>

</blockquote>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'>

<div>

<div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Calibri","sans-serif";
color:#1F497D'> </span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Calibri","sans-serif";
color:#1F497D'>Am I correct so far?</span><o:p></o:p></p>

</div>

</div>

</div>

</blockquote>

<div>

<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'>Yes, correct.  This is what is
now implemented in the CVS head.<o:p></o:p></p>

</div>

<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>

<div>

<div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-family:"Calibri","sans-serif";
color:#1F497D'> Now, what to do about converting from LONGINT to INTEGER?</span><o:p></o:p></p>

</div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><span
style='font-family:"Calibri","sans-serif";color:#1F497D'>a.</span><span
style='font-size:7.0pt;color:#1F497D'>     <span
class=apple-converted-space> </span></span><span style='font-family:"Calibri","sans-serif";
color:#1F497D'>Originally, ORD was proposed along with use of a checked runtime
error if the value of the LONGINT didn’t fit into an INTEGER.  But,
then the result type signature of ORD (i.e., INTEGER) doesn’t preserve
the identity ORD(n) = VAL(n, T) = n when T is LONGINT.  To allow this, you
would have to make the result type of ORD dependent on the parameter type
passed to ORD.</span><o:p></o:p></p>

</div>

</div>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'>See above.<o:p></o:p></p>

</div>

<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>

<div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><span
style='font-family:"Calibri","sans-serif";color:#1F497D'>b.</span><span
style='font-size:7.0pt;color:#1F497D'>     <span
class=apple-converted-space> </span></span><span style='font-family:"Calibri","sans-serif";
color:#1F497D'>Provide an overloaded form of VAL with a different signature
that allows for int := VAL(longInt, INTEGER).  I think this is somewhat
confusing in terms of the original definition of VAL as an inverse of ORD.</span><o:p></o:p></p>

</div>

</div>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'>See above.<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>

</div>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'>

<div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><span
style='font-family:"Calibri","sans-serif";color:#1F497D'>c.</span><span
style='font-size:7.0pt;color:#1F497D'>      <span
class=apple-converted-space> </span></span><span style='font-family:"Calibri","sans-serif";
color:#1F497D'>Allow for checked assignability, e.g., int := longInt; but then
this to me starts us on the slippery slope where one eventually argues for
mixed arithmetic.</span><o:p></o:p></p>

</div>

</div>

</div>

</blockquote>

<div>

<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'>No assignability!<o:p></o:p></p>

</div>

<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>

<div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><span
style='font-family:"Calibri","sans-serif";color:#1F497D'>d.</span><span
style='font-size:7.0pt;color:#1F497D'>     <span
class=apple-converted-space> </span></span><span style='font-family:"Calibri","sans-serif";
color:#1F497D'>Come up with differently named operators (different from
ORD/VAL).  These would have the benefit of requiring only one parameter,
whereas VAL requires two, and would prevent any confusion with the defined use
of ORD/VAL as conversion inverses for enumerations and integers. <span
class=apple-converted-space> </span><b>This is my preferred option.</b></span><o:p></o:p></p>

</div>

</div>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'>I don't think we need to do this,
assuming you understand what I have said above.<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'>ORD(x: INTEGER): LONGINT<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'>ORD(x: LONGINT): INTEGER<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'>ORD(x: Enumeration): INTEGER<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'>ORD(x: Subrange): Base(Subrange)<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'>ORD(n) = VAL(n, T) = n if n is an
integer of type T = INTEGER or T = LONGINT.<o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>

</div>

<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'>

<div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in'><span
style='font-family:"Calibri","sans-serif";color:#1F497D'>e.</span><span
style='font-size:7.0pt;color:#1F497D'>     <span
class=apple-converted-space> </span></span><span style='font-family:"Calibri","sans-serif";
color:#1F497D'>Any other ideas?</span><o:p></o:p></p>

</div>

</div>

</div>

</blockquote>

<div>

<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'>I think we are done...<o:p></o:p></p>

</div>

<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>

<div>

<div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>Regards,</span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>Randy</span><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p>

</div>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in;
border-width:initial;border-color:initial'>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><b><span style='font-size:10.0pt;
font-family:"Tahoma","sans-serif"'>From:</span></b><span
class=apple-converted-space><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> </span></span><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>Tony Hosking
[mailto:hosking@cs.purdue.edu]<span class=apple-converted-space> </span><br>
<b>Sent:</b><span class=apple-converted-space> </span>Monday, January 11,
2010 12:32 PM<br>
<b>To:</b><span class=apple-converted-space> </span>Randy Coleburn<br>
<b>Cc:</b><span class=apple-converted-space> </span>m3devel<br>
<b>Subject:</b><span class=apple-converted-space> </span>Re: [M3devel] the
LONGINT proposal</span><o:p></o:p></p>

</div>

</div>

</div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'> <o:p></o:p></p>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'>Quick summary:<o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'> <o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'>I agree, and you seem to be
supporting the status quo (other than your discomfort with ORD/VAL) as defined
at: <a href="http://www.cs.purdue.edu/homes/hosking/m3/reference/">http://www.cs.purdue.edu/homes/hosking/m3/reference/</a><o:p></o:p></p>

</div>

</div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'> <o:p></o:p></p>

</div>

<div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'>On 11 Jan 2010, at 01:11, Randy
Coleburn wrote:<o:p></o:p></p>

</div>

</div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<br>
<o:p></o:p></p>

</div>

<div>

<div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>Tony:</span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><b><i><span style='font-family:
"Calibri","sans-serif";color:#1F497D'>Sorry, I have been too long-winded
here.  To answer your questions succinctly: </span></i></b><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><b><i><span style='font-family:
"Calibri","sans-serif";color:#1F497D'> </span></i></b><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><b><i><span style='font-family:
"Calibri","sans-serif";color:#1F497D'>1.  I can relax on the<span
class=apple-converted-space> </span><u>requirement</u><span
class=apple-converted-space> </span>for overflow checking, but programmers
should never count on it silently wrapping around.</span></i></b><o:p></o:p></p>

</div>

</div>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'> <o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'>Agreed.<o:p></o:p></p>

</div>

</div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<br>
<o:p></o:p></p>

</div>

<div>

<div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><b><i><span style='font-family:
"Calibri","sans-serif";color:#1F497D'> </span></i></b><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><b><i><span style='font-family:
"Calibri","sans-serif";color:#1F497D'>2.  I think checked assignability
gets us onto the slippery slope (see below).  Using differently named
conversion operators would lesson some of the ugliness of ORD/VAL and also
prevent confusion with their intended use as enumeration/INTEGER conversions.</span></i></b><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><b><i><span style='font-family:
"Calibri","sans-serif";color:#1F497D'> </span></i></b><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><b><i><span style='font-family:
"Calibri","sans-serif";color:#1F497D'>Read on for the long-winded version…</span></i></b><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>According to NELSON (SPwM3),
ORD and VAL convert between<span class=apple-converted-space> </span><b><u>enumerations</u></b><span
class=apple-converted-space> </span>and INTEGERs, and INTEGER is all
integers represented by the<span class=apple-converted-space> </span><u>implementation</u>. 
So, the range of INTEGER is likely different for 8-bit, 16-bit, 32-bit, and
64-bit processors. </span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>Today we see 32-bit and
64-bit processors as predominant, but I remember the day when 8-bit and 16-bit
were the norm.  Someday we may see 128-bit processors as the norm. </span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>(I’ve been cleaning up
my basement office and ran across a box of 8-inch floppy disks.  When I
showed them to my daughter she understood the meaning of “floppy”
as opposed to the rigid 3.5-inch floppies of today.  But, I digress.)</span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>On a 64-bit processor, this
whole idea of LONGINT as 64-bits then becomes mute since INTEGER will be 64 bits
also.  But on a 16-bit machine (assuming we had an implementation for one)
the native word size would be less than the 32-bits we seem to take for granted
now.</span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>One problem is that one
doesn’t really know the range of LONGINT unless we define it as some
number of bits.  Rodney’s proposal simply stated that LONGINT was at
least as big as INTEGER but could be larger.  So, on a 64-bit machine, are
LONGINT and INTEGER really the same in terms of implementation?, whereas on a
32-bit the LONGINT would have an additional 32-bits more than INTEGER? 
What about a 128-bit machine?</span><o:p></o:p></p>

</div>

</div>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'> <o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'>What's wrong with using
FIRST(LONGINT) and LAST(LONGINT) to determine the range?  This is
currently implemented.<o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'>On a 64-bit machine the types
LONGINT and INTEGER are still distinct in the current implementation, so cannot
be assigned, though they do happen to have the same underlying representation.<o:p></o:p></p>

</div>

</div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<br>
<o:p></o:p></p>

</div>

<div>

<div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> I say all this to point
out the obvious, namely that LONGINT and INTEGER are different <b><u>types</u></b>. </span><o:p></o:p></p>

</div>

</div>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'> <o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'>Correct.  The current
implementation treats them as completely separate.<o:p></o:p></p>

</div>

</div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<br>
<o:p></o:p></p>

</div>

<div>

<div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> Therefore, IMO the
language must make it clear how these different types interact.</span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>I would argue that</span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>   x: LONGINT := 23;</span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>is wrong!  The
programmer should have to write</span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>   x: LONGINT :=
23L;</span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>instead.</span><o:p></o:p></p>

</div>

</div>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'> <o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'>This is what we currently implement.<o:p></o:p></p>

</div>

</div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<br>
<o:p></o:p></p>

</div>

<div>

<div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> A subrange of LONGINT
would be written as [23L..4200L] and would be a different type than the integer
subrange [23..4200] even though the ranges are identical.</span><o:p></o:p></p>

</div>

</div>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'> <o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'>Also what we currently implement.<o:p></o:p></p>

</div>

</div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<br>
<o:p></o:p></p>

</div>

<div>

<div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> Likewise, IMO mixed
arithmetic with the compiler deciding what to do is wrong.  The programmer
should have to explicitly write conversions to a common type for arithmetic.</span><o:p></o:p></p>

</div>

</div>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'> <o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'>I agree, and this is the current
implementation.<o:p></o:p></p>

</div>

</div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<br>
<o:p></o:p></p>

</div>

<div>

<div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> I have no problem with
extending the existing operators to deal with LONGINT; it’s just that the
result should be LONGINT.</span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>Given x: LONGINT := 49L;</span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>   INC(x) yields 50L</span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>   INC(x, 3L)
yields 52L</span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>     
note that INC(x, 3) would be a syntax error since 3 is an INTEGER and x is a
LONGINT</span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>   (x + 20L) yields
69L</span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>     
note that (x + 20) would be a syntax error since 20 is an INTEGER and x is a
LONGINT</span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>   LAST(LONGINT)
yields a LONGINT</span><o:p></o:p></p>

</div>

</div>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'> <o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'>This is exactly the current
implementation.<o:p></o:p></p>

</div>

</div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<br>
<o:p></o:p></p>

</div>

<div>

<div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> Now that I think about
it more, I have a problem using ORD/VAL for the conversion since NELSON defines
these as converting between <b><u>enumerations</u></b> and INTEGERs,
and since LONGINT is a different type than INTEGER and quite possibly has a
greater range than INTEGER.  Is the proposal to also allow enumerations to
use the range of LONGINT ?  Enumerations currently are defined as having a
range no greater than INTEGER.  To extend them to LONGINT would lose the
obvious performance benefits of keeping them same range as native INTEGER.</span><o:p></o:p></p>

</div>

</div>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'> <o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'>I'm not sure that the current
implementation conflicts with the definition of ORD/VAL.  What we
currently permit is ORD(LONGINT) to do a *checked* conversion of a LONGINT to
an INTEGER.  The optional type parameter of VAL can be LONGINT, which
permits conversion of INTEGER to LONGINT.  I don't see how these conflict
with the intention of ORD/VAL.  You can see the language spec for what is
currently implemented at:<span class=apple-converted-space> </span><a
href="http://www.cs.purdue.edu/~hosking/m3/reference/">http://www.cs.purdue.edu/~hosking/m3/reference/</a>.<o:p></o:p></p>

</div>

</div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<br>
<o:p></o:p></p>

</div>

<div>

<div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> Maybe we should invent
new names for the conversions between INTEGER and LONGINT.  Perhaps
PROMOTE and DEMOTE or some such.  These are probably bad names, but I use
them below simply to illustrate (feel free to come up with better names):</span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>   Given longInt:
LONGINT;   and   int: INTEGER;</span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>   int :=
DEMOTE(longInt); would perform the conversion from LONGINT to INTEGER and would
give a runtime range check error if longInt is too big/small to fit in an
INTEGER.</span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>   longInt :=
PROMOTE(int) would always succeed in performing the conversion from INTEGER to
LONGINT but would make the conversion explicit</span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>   int +
DEMOTE(longInt) would yield an INTEGER result with all arithmetic being done in
the range of INTEGER</span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>   longInt +
PROMOTE(int) would yield a LONGINT result with all arithmetic being done in the
range of LONGINT</span><o:p></o:p></p>

</div>

</div>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'> <o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'>I think ORD/VAL suffice...<o:p></o:p></p>

</div>

</div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<br>
<o:p></o:p></p>

</div>

<div>

<div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> Now if we were to allow
checked assignability (as Tony is leaning toward), I think we begin to get on
the slippery slope.  How far do we extend this to the point that it is not
clear in the expression of the code what is happening?  If I can write
“int := longInt;” why not “int := 23L;” and why not
“int := longInt + 57;” and is this different than “int :=
longInt + 57L;”? etc. etc.</span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>I agree the ORD/VAL syntax is
ugly, so that is another reason (besides them applying to enumerations only) we
should use different names for the INTEGER/LONGINT conversions.</span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><b><span style='font-size:14.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>Sorry, I have been too
long-winded here.  To answer your questions succinctly: </span></b><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><b><span style='font-size:14.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> </span></b><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><b><span style='font-size:14.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>1.  I can relax on the<span
class=apple-converted-space> </span><u>requirement</u><span
class=apple-converted-space> </span>for overflow checking, but programmers
should never count on it silently wrapping around.</span></b><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><b><span style='font-size:14.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> </span></b><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><b><span style='font-size:14.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>2.  I think checked
assignability gets us onto the slippery slope.  Using differently named
conversion operators would lesson some of the ugliness of ORD/VAL and also
prevent confusion with their intended use as enumeration/INTEGER conversions.</span></b><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>Regards,</span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'>Randy Coleburn</span><o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p>

</div>

</div>

<div>

<div style='border:none;border-top:solid windowtext 3.0pt;padding:3.0pt 0in 0in 0in;
border-width:initial;border-color:initial;border-width:initial;border-color:
initial'>

<div style='margin-left:.5in'>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><b><span style='font-size:10.0pt;
font-family:"Tahoma","sans-serif"'>From:</span></b><span
class=apple-converted-space><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> </span></span><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>Tony Hosking
[mailto:hosking@cs.purdue.edu]<span class=apple-converted-space> </span><br>
<b>Sent:</b><span class=apple-converted-space> </span>Sunday, January 10,
2010 3:43 PM<br>
<b>To:</b><span class=apple-converted-space> </span>Randy Coleburn<br>
<b>Cc:</b><span class=apple-converted-space> </span>m3devel<br>
<b>Subject:</b><span class=apple-converted-space> </span>Re: [M3devel] the
LONGINT proposal</span><o:p></o:p></p>

</div>

</div>

</div>

</div>

<div style='margin-left:.5in'>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'> <o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'>Hi Randy,<o:p></o:p></p>

</div>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'> <o:p></o:p></p>

</div>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'>As someone who has actually written
Modula-3 programs for a living your opinions are always highly valued.  I
agree with you in principle and aims, except for requiring overflow to be a
checked run-time error.  The language definition already has a mechanism
for handling this in the require FloatMode interface.  It is not something
that the compiler should be involved in.  I also just now raised
a question about perhaps having integer literals adapt their type to the
context in which they are used.<o:p></o:p></p>

</div>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'> <o:p></o:p></p>

</div>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'>I should point out that the current
mainline implementation does exactly what you propose (except overflow
checking).  It captures the fundamental spirit of Rodney's proposal but
does not permit mixed arithmetic or assignment.  Can I ask what your issue
is w.r.to checked assignability?  I am still leaning in favor.  It is
not much different from assignment from an INTEGER to a subrange, which
requires no explicit check, though of course there is a run-time range check.
 Having programmers explicitly write:<o:p></o:p></p>

</div>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'> <o:p></o:p></p>

</div>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span class=apple-style-span><span
style='font-size:9.0pt;font-family:Courier'>x: INTEGER := ORD(longint, INTEGER);</span></span><o:p></o:p></p>

</div>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'> <o:p></o:p></p>

</div>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'>seems unnecessary when they could
just write<o:p></o:p></p>

</div>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'> <o:p></o:p></p>

</div>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span class=apple-style-span><span
style='font-size:9.0pt;font-family:Courier'>x: INTEGER := longint;</span></span><o:p></o:p></p>

</div>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'> <o:p></o:p></p>

</div>

</div>

</div>

<div>

<div>

<div>

<div style='margin-left:.5in'>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span class=apple-style-span><span
style='font-size:13.5pt;font-family:"Helvetica","sans-serif";color:black'>This
is similar in spirit to:</span></span><o:p></o:p></p>

</div>

</div>

</div>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'> <o:p></o:p></p>

</div>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><span class=apple-style-span><span
style='font-size:9.0pt;font-family:Courier'>x: [lo..hi] := integer;</span></span><o:p></o:p></p>

</div>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'> <o:p></o:p></p>

</div>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'> <o:p></o:p></p>

</div>

</div>

</div>

<div>

<div>

<div style='margin-left:.5in'>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'>On 10 Jan 2010, at 15:00, Randy
Coleburn wrote:<o:p></o:p></p>

</div>

</div>

</div>

<div style='margin-left:.5in'>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<br>
<br>
<o:p></o:p></p>

</div>

</div>

<div>

<div style='margin-left:.5in'>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'>I've been trying to follow along on
this topic.<br>
<br>
Here are my thoughts:<br>
<br>
1.  LONGINT should be a distinct type different from INTEGER.<br>
<br>
2.  There should be no mixed arithmetic between the types.  The programmer
must code conversions using ORD/VAL to make explicit the intention.  Don't
rely on some ill-remembered built-in conversion rule.<br>
<br>
3.  Overflow should be a checked run-time error, not silently wrapped
around.<br>
<br>
4.  WRT assignability, I think explicit conversions should be used.<br>
<br>
These statements may make me unpopular with some who don't like to type much,
but I've always hated the tradeoff of understandability for brevity in
expression.<br>
<br>
The important thing is not how fast we can type up a program, it is rather how
hard is it to make a mistake.  I think the spirit of Modula-3 is that the
language makes you a better programmer by forcing you to make your intentions
explicit rather than relying on the compiler to infer your intentions.  We
need correct and maintainable software, especially at the systems level.
 Whatever is decided about LONGINT, we need to keep to the original design
tenants of the language.  <br>
<br>
And yes, I do think we need a LONGINT type, not just to deal with large file
sizes.<br>
<br>
But even for long-lived readers/writers, whatever type you choose for the index
will eventually be insufficient, so you have to code for the possibility that
the range of the long lived reader/writer exceeds the range of your index type.
 That is just good programming.<br>
<br>
I think sometimes that the new generation of programmers has been warped by
what I call the "Microsoft Mentality" where you must expect that you
need to reboot/restart every so often to maintain proper performance.
 Programs should be written to run forever or until their job is completed
or they are commanded to stop.  <br>
<br>
As "we" begin to converge on the design changes, I like having
something concrete to look at, ala Rodney's proposal.  Can we take that
and keep tweaking it in these emails until we reach a final version acceptable
to all?  To me this keeps the discussion focused rather than the many
different emails.  Thus, what I am trying to say is put forth a numbered
proposal and each subsequent email must show adjustment to that proposal rather
than just a bunch of emails discussing various aspects.  Perhaps we should
vote on each proposed change, then decide to call a final vote on the whole
thing.  Who should be involved in such votes?  Right now the main
persons on the thread are Tony, Jay, Rodney, Mika, Hendrik, Olaf, John, and me.<br>
<br>
My two cents.<br>
<br>
Regards,<br>
Randy Coleburn<o:p></o:p></p>

</div>

</div>

</div>

</div>

<div style='margin-left:.5in'>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'> <o:p></o:p></p>

</div>

</div>

</div>

</div>

</div>

<div style='margin-left:.5in'>

<p class=MsoNormal style='margin-left:.5in'> <o:p></o:p></p>

</div>

</div>

</div>

</div>

<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>

</div>

</body>

</html>