<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 14 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@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:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
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;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
pre
{mso-style-priority:99;
mso-style-link:"HTML con formato previo Car";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
tt
{mso-style-priority:99;
font-family:"Courier New";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Texto de globo Car";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.HTMLconformatoprevioCar
{mso-style-name:"HTML con formato previo Car";
mso-style-priority:99;
mso-style-link:"HTML con formato previo";
font-family:"Consolas","serif";}
span.EstiloCorreo21
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.TextodegloboCar
{mso-style-name:"Texto de globo Car";
mso-style-priority:99;
mso-style-link:"Texto de globo";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></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">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hi all:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">BTW, tis brings back the issue of LONGADDRESS, since such a type would allow implementation of LONGINT subranges ordinal types.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">The VAX9000 which had a very orthogonal ISA, had the extended address bus and addressing of34 bits, in a 32-bit CPU.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">So technically, it wouldn’t be orthogonal to not implement all ordinal types INTEGER subranges. Modula-3 type systems is orthogonal by definition (at least).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">It also brings back a proposal I sketched some time ago about of width subtyping LONGINT and WIDECHAR of INTEGER and CHAR types correspondingly .<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thanks in advance<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 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="ES" style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">De:</span></b><span lang="ES" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Tony Hosking [mailto:hosking@cs.purdue.edu]
<br>
<b>Enviado el:</b> Monday, 30 de September de 2013 10:46 a.m.<br>
<b>Para:</b> Coleburn, Randy<br>
<b>CC:</b> m3devel; Jay K<br>
<b>Asunto:</b> Re: [M3devel] question on File.Status.size<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Indeed, I wonder if it should be Long.T instead of LONGCARD, because I am uneasy with the assumption that the representation might not change.<o:p></o:p></p>
<div>
<p class="MsoNormal">(I can imagine a world where there is no LONGINT, and in which Long.T has some different representation than LONGINT.)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Now, on the other hand, POSIX specifies file sizes to be off_t, which is signed, whereas Long.T is meant to be thought of as unsigned.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">So, should M3 adopt the POSIX spec that a file size is a signed value? In which case I suppose LONGCARD makes sense.<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Sep 30, 2013, at 9:49 AM, "Coleburn, Randy" <<a href="mailto:rcolebur@SCIRES.COM">rcolebur@SCIRES.COM</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">I haven't looked at the various underlying implementations of File.T but have they all been adjusted to deal with FS.Status.size now being a LONGCARD while the internal buffers are limited to arrays whose length can be no more than INTEGER?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If so, then I guess I need to adjust my code to deal with bigger files (even though my code won't actually use bigger files). <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I'm not complaining. I just want to make sure this interface change has been well thought out and implemented and is going to persist before I embark on changes to code that has been in production for years. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Randy Coleburn<br>
<br>
Sent from my iPhone<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
On Sep 30, 2013, at 12:48 AM, "Jay K" <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> > NUMBER(array) to yield a LONGCARD<br>
<br>
This can't be.<br>
Arrays are in-memory data structures. <br>
INTEGER/CARDINAL are an appropriate type<br>
to hold the size of something fits in memory/address-space.<br>
INTEGER is like C's ptrdiff_t. <br>
CARDINAL is kind of like C's size_t, except it is half range. <br>
Word.T is kind of like C's size_t, except it has no convenient in-fix operators.
<br>
<br>
<br>
Files commonly do not fit in memory/address-space. <br>
So they arguably should have their size stored <br>
in a larger type.<br>
<br>
<br>
I think there is no easy answer here.<br>
<br>
<br>
I would be ok with:<br>
- put it back to INTEGER/CARDINAL <br>
- expose another way new way to get a LONGCARD <br>
<br>
<br>
- Jay<br>
<br>
<br>
<br>
<o:p></o:p></p>
<div>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="100%" align="center" id="stopSpelling">
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">From: <a href="mailto:rcolebur@SCIRES.COM">
rcolebur@SCIRES.COM</a><br>
To: <a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>
Date: Sun, 29 Sep 2013 22:59:35 +0000<br>
Subject: [M3devel] question on File.Status.size<o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">I've been trying to rebuild all my developed software using my newly rebuilt cm3 from the HEAD branch.<br>
<br>
I've run into some new build errors and have a question.<br>
<br>
It seems the type of File.Status.size has been changed to LONGCARD.<br>
<br>
I have some code that now fails to build because of this change.<br>
<br>
I suppose this interface change is an attempt to better deal with files whose size in bytes is larger than MAX(CARDINAL).<br>
<br>
So, for example:<br>
fs := FS.Status(file);<br>
INC(numBytes, fs.size);<br>
no longer works if numBytes is defined as a CARDINAL. Of course, I can change its type to be LONGCARD, but there will be a ripple effect throughout the code.<br>
<br>
<b>Has the language definition also been updated to allow NUMBER(array) to yield a LONGCARD ?</b><br>
(Interface File uses open arrays)<br>
<br>
In my old language definition, it says that:<o:p></o:p></span></p>
<p class="MsoNormal"><a name="idx.43"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">An</span></a><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> open array type declaration has the form:
<o:p></o:p></span></p>
<pre> TYPE T = ARRAY OF Element<o:p></o:p></pre>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">where
</span><tt><span style="font-size:10.0pt">Element</span></tt><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> is any type. The values of
</span><tt><span style="font-size:10.0pt">T</span></tt><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> are arrays whose element type is
</span><tt><span style="font-size:10.0pt">Element</span></tt><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> and whose length is arbitrary. The index type of an open array is the
</span><tt><b><span style="font-size:10.0pt">INTEGER</span></b></tt><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> subrange
</span></b><tt><span style="font-size:10.0pt">[0..n-1]</span></tt><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">, where
</span><tt><span style="font-size:10.0pt">n</span></tt><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> is the length of the array.
<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">In the past NUMBER(x) always yielded a CARDINAL, not a LONGCARD. So, if this has changed, I'll need to do some more updates across my code base.<br>
<br>
<b>How does one know in advance if NUMBER(x) is going to yield a CARDINAL or a LONGCARD value, esp. for open arrays?<br>
</b><br>
Thanks,<br>
Randy Coleburn<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>