<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:m="http://schemas.microsoft.com/office/2004/12/omml" 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)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 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;}
@font-face
{font-family:"\0027Gill Sans\0027";
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* 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-tab-span
{mso-style-name:apple-tab-span;}
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'>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></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div>
<p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Randy Coleburn</span></b><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif";color:#1F497D'><br>
<br>
<o:p></o:p></span></p>
</div>
<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> Friday, January 08, 2010 1:01 PM<br>
<b>To:</b> Rodney M. Bates<br>
<b>Cc:</b> m3devel<br>
<b>Subject:</b> Re: [M3devel] LONGINT, my original 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:"'Gill Sans'","serif";color:blue'>We
already have much of this, but not all. Notes below...</span></span><span
style='font-size:9.0pt;font-family:"Helvetica","sans-serif";color:black'><o:p></o:p></span></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><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'>I am now convinced (Jay will be
relieved) that Rodney's proposal is mostly what we want.<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'>I am looking into making the
changes to the current implementation that will bring this into being.<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'>On 8 Jan 2010, at 11:53, Rodney M.
Bates wrote:<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'>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: <br>
<br>
1. There is a new builtin type named LONGINT.<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'>We have this.<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'>2. FIRST(LONGINT) <=
FIRST(INTEGER) and LAST(INTEGER) <= LAST(LONGINT).<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'>Currently, direct comparison
between LONGINT and INTEGER is not permitted. If it were then this would
be true.<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'> 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></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>This is what we currently have.<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'>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></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>We have this right now.<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'> 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 <br>
would create a semantic mess. (e.g. Ada).<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'>I wholeheartedly agree!<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'> 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></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>The current implementation
illustrates that this is not a problem.<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'>4. LONGINT # INTEGER.<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'>We have this right now.<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'> 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></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>Agreed.<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'>5. LONGINT is an ordinal type. <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'>We have this right now.<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'> 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></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>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></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'>6. Neither LONGINT nor INTEGER is a
subtype of the other. <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'>We have this right now.<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'> 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></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>Agreed.<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'>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></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>We have this.<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'>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></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>I am uneasy about mixing parameter
types in this way.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>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></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'> 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></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>Agreed.<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'> 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></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>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></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'> 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></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>OK. I think I see how to
implement this...<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'>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></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>Same as above. I think it can
be implemented.<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'>10. The first parameter to FLOAT
can have a subtype of either INTEGER<br>
or LONGINT.<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'>We already support this.<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'>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></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>Already supported.<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'>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></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>The current implementation uses ORD
as the mechanism for checked conversion from LONGINT to INTEGER.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>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></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'> 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></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>I see no problem with the maximum
enumeration type values being restricted to natural integers.<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'>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></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>The current implementation uses VAL
as the mechanism for conversion from INTEGER to LONGINT.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>Just like ORD, if we change
assignability as you suggest then we can support your semantics as an explicit
conversion.<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'>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></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>[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></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>The current implementation does not
allow mixing INTEGER/LONGINT operand and increments.<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>
<p class=MsoNormal style='margin-left:.5in'>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></p>
</div>
</blockquote>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>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></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'>16. Neither LONGINT, nor any
subtype thereof, can be used as the index<br>
type of an array type.<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'>This is the current implementation.<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'> 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></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>Agreed.<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'> 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></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>This is the current implementation.<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'> 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></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>Agreed.<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'>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></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>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></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'>19. (NO CHANGE) BITSIZE, BYTESIZE,
ADRSIZE, and TYPECODE are unchanged.<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'>This is the current
implementation. <o:p></o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
</div>
<blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'>
<div>
<p class=MsoNormal style='margin-left:.5in'><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></p>
</div>
</blockquote>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>Agreed.<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'>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></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>Agreed.<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'> Note that the
existing definition of FOR otherwise generalizes<br>
to LONGINT without change.<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'>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></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'>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></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>This is the current implementation.<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'>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></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>This is the current implementation,
but we do not support ToWord and FromWord. Why do we need these?<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'> 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></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>This is the current implementation.<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'>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></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>This is the current implementation.<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'>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></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>This is the current implementation.<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'>25. Fmt has a new function LongInt,
parallel to Int, but replacing<br>
INTEGER by LONGINT.<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'>We have this.<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'>26. Lex has a new function LongInt,
parallel to Int, but replacing<br>
INTEGER by LONGINT.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'>We have this.<br>
<br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'>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></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>We currently do not support this.<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'> 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></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal style='margin-left:.5in'>Until we see the need I hesitate to
implement it.<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'> 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 <br>
left unimplemented unless/until such a target
actually happens.<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'>Agreed.<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'>Changes to useful interfaces: <br>
<br>
28. IO has new procedures PutLongInt and GetLongInt, parallel to<br>
PutInt and GetInt.<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'>I just added these.<o:p></o:p></p>
</div>
<p class=MsoNormal style='margin-left:.5in'><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal style='margin-left:.5in'> 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></p>
</div>
</div>
<p class=MsoNormal style='margin-left:.5in'><o:p> </o:p></p>
</div>
</body>
</html>