<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><div><font face="Calibri">I'm really confused but the approach and mentality here.</font></div><div><font face="Calibri">I believe I understand that this is not C or C++ and that there</font></div><div><font face="Calibri">are things to be gained from that.</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">First, let me restate the "less important" questions.</font></div><div><font face="Calibri">The questions I care less about.</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">What is the interface or abstract contractual properties of TypeUID?</font></div><div><font face="Calibri">It is exactly 32 bits in size?</font></div><div><font face="Calibri"> I doubt it, but it could be.</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">At least 32 bits in size?</font></div><div><font face="Calibri"> Well, that is kind of unavoidable, assuming a binary computer,</font></div><div><font face="Calibri"> a computer that actually uses bits.</font></div><div><font face="Calibri"> </font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">No more than 32 bits in size?</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">It can store the subrange -16_7FFFFFF - 1 .. 16_7FFFFFF?</font></div><div><font face="Calibri"> That seems to me to be "part of" the interface, and possibly</font></div><div><font face="Calibri"> the entire interface. Assuming a computing device that uses "bits",</font></div><div><font face="Calibri"> that does imply at least 32 bits. </font></div><div><font face="Calibri"> It actually conceivably does not rule out requiring 33 bits,</font></div><div><font face="Calibri"> as signed-magnitude requires 33 bits to represent -16_7FFFFFF - 1.</font></div><div><font face="Calibri"> I'm willing to believe we are not portable beyond two's complement systems.</font></div><div><font face="Calibri"> </font></div><div><font face="Calibri"> </font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">And where are these properties assumed and violating them would</font></div><div><font face="Calibri">cause problems?</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">parse.c says:</font></div><div><font face="Calibri">/*------------------------------------------------------------- type uids ---*/</font></div><div><font face="Calibri">/* Modula-3 type uids are unsigned 32-bit values. They are passed as signed</font></div><div><font face="Calibri"> decimal integers in the intermediate code, but converted to 6-byte, base 62</font></div><div><font face="Calibri"> strings of characters from here to the debugger. To avoid surprises downstream,</font></div><div><font face="Calibri"> these generated strings are legal C identifiers. */</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">#define UID_SIZE 6</font></div><div><font face="Calibri">#define NO_UID (0xFFFFFFFFUL)</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">(Notice this does NOT agree with TypeUID -- it says they are unsigned.</font></div><div><font face="Calibri">But the subrange includes negative numbers. I should check this and</font></div><div><font face="Calibri">the history...)</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">I'm hoping we delete parse.c within a year, but that's another matter.</font></div><div><font face="Calibri">The C-generating backend is coming along nicely.</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">So there is a dependency that they be representable within 6 base-62</font></div><div><font face="Calibri">digits. Which I believe actually allows for a larger range, at least</font></div><div><font face="Calibri">slightly.</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">Ok, as I said, this isn't critical.</font></div><div><font face="Calibri">I'm willing to believe it must fit in 32 bits.</font></div><div><font face="Calibri">I'm skeptical that it must not include extra padding bits within a struct (which</font></div><div><font face="Calibri">is what the historical definition is).</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">Now, let's move on to my very very simple desire</font></div><div><font face="Calibri">to store these things in records, and pass them on to</font></div><div><font face="Calibri">other M3CG.T implementations.</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">Hypothetical dumb code, that should be simple and work.</font></div><div><font face="Calibri">Yes, I know this is dumb, but it demonstrates the point.</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">TYPE T1 = RECORD text: TEXT; type: TypeUID END;</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">M3CG.T cg1, cg2;</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">PROCEDURE declare_whatevere(text: TEXT; type: TypeUID)</font></div><div><font face="Calibri">VAR t1: T1;</font></div><div><font face="Calibri">BEGIN</font></div><div><font face="Calibri"> t1.text := text;</font></div><div><font face="Calibri"> t1.type := type;</font></div><div><font face="Calibri"> cg1.declare_whatever(t1.text, t1.type);</font></div><div><font face="Calibri"> cg2.declare_whatever(t1.text, t1.type);</font></div><div><font face="Calibri">END declare_whatevere;</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">It should be that easy, right?</font></div><div><font face="Calibri">Surely this is reasonable?</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">TypeUID could be INTEGER, a subrange, an enum, REAL, BOOLEAN</font></div><div><font face="Calibri">REFANY, UNTRACED REF of anything, it could be a RECORD</font></div><div><font face="Calibri">with arbitrary fields. This would work.</font></div><div><font face="Calibri">It doesn't care about packing or padding.</font></div><div><font face="Calibri">It doesn't assume TypeUID is a subrange and declare the similar:</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">TYPE T1 = RECORD text: TEXT; type: FIRST(TypeUID) ... LAST(TypeUID) END;</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">If TypeUID changes to one of several other kinds of things,</font></div><div><font face="Calibri">it continues to work and be correct.</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">Granted, if TypeUID became some sort of "OBJECT", maybe with</font></div><div><font face="Calibri">some sort of "copy" or "clone" METHOD, then maybe this becomes wrong.</font></div><div><font face="Calibri">(This is an area where C++ is very interesting -- user defined types</font></div><div><font face="Calibri">can behave like values and be copied around correctly w/o regard</font></div><div><font face="Calibri">to the concrete implementation/representation; it is up to the type</font></div><div><font face="Calibri">implementer to make it work if he deems it. But I digress.)</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">Now I see a few unavoidable options.</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">1) TypeUID can be any size.</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">TypeUID = [-16_7FFFFFF - 1 .. 16_7FFFFFFF];</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">2) TypeUID must fit in 32 bits, but padding can be inserted</font></div><div><font face="Calibri">before/after it:</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">TypeUID = [-16_7FFFFFF - 1 .. 16_7FFFFFFF];</font></div><div><font face="Calibri"><* ASSERT BITSIZE(TypeUID) >= 32 *></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">That is essentially what I did, but without the assertion.</font></div><div><font face="Calibri">Cstdint.int32_t is just a lazy way of stating the same thing.</font></div><div><font face="Calibri">Granted, with an apparent interest in the size.</font></div><div><font face="Calibri">But, again, that might be an over specification.</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">3) We are super afraid of making any changes and TypeUID</font></div><div><font face="Calibri">really cannot change at all, but it is reasonble</font></div><div><font face="Calibri">to allow new code like I showed.</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">UnpackedTypeUID = [-16_7FFFFFF - 1 .. 16_7FFFFFFF]; (* for new code to use *)</font></div><div><font face="Calibri">TypeUID = BITS 32 FOR TypeUID; (* extreme compatibility *)</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">I really don't think "Int32" is the way.</font></div><div><font face="Calibri">It doesn't belong here. Public in M3CG/Target.</font></div><div><font face="Calibri">It is not what I should store in a record to hold a TypeUID.</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">Again, imagine TypeUID is opaque/abstract to me.</font></div><div><font face="Calibri">I just need to copy it around and pass it on to other M3CG implementations.</font></div><div><font face="Calibri">It could chane to REAL for all I care.</font></div><div><font face="Calibri">I don't want to be referencing some very concrete/transparent "Int32",</font></div><div><font face="Calibri">when I'm not doing anything that depends on that implementation detail.</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">I even question somewhat the subrange.</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">In the future 32 bit hosts and targets will disappear.</font></div><div><font face="Calibri">We will have only 64bit and 128bit.</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">What should TypeUID be in that world?</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">Is the point really that it be an "INTEGER" that "fits"</font></div><div><font face="Calibri">on any host or target?</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">Now, I grant... I might need to convert a TypeUID to a string.</font></div><div><font face="Calibri">Here we are faced with a recurring dilemna.</font></div><div><font face="Calibri">Either TypeUID is a thick/complete abtraction, and we provide</font></div><div><font face="Calibri">common operations:</font></div><div><font face="Calibri">INTERFACE TypeUID;</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">(* declared here for performance; actually abstract;</font></div><div><font face="Calibri"> * use only with functions in this interface *)</font></div><div><font face="Calibri">TYPE T = [-16_7FFFFFF - 1 .. 16_7FFFFFFF]; </font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">PROCEDURE Compare(a,b:T): [-1..1]; (* like for qsort *)</font></div><div><font face="Calibri">PROCEDURE Equal(a,b:T): BOOLEAN;</font></div><div><font face="Calibri">PROCEDURE ToText(a:T): TEXT;</font></div><div><font face="Calibri">PROCEDURE Copy(from:T; VAR to:T);</font></div><div><font face="Calibri">PROCEDURE Init(VAR a:T);</font></div><div><font face="Calibri">PROCEDURE New():T;</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">END TypeUID;</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">MODULE TypeUID;</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">(* for now, just an integer *)</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">PROCEDURE Compare(a,b:T): [-1..1] (* like for qsort *)</font></div><div><font face="Calibri">BEGIN</font></div><div><font face="Calibri"> (* DO NOT USE SUBTRACTION HERE. *)</font></div><div><font face="Calibri"> IF a < b THEN RETURN -1; END;</font></div><div><font face="Calibri"> ELSIF a > b THEN RETURN 1; END;</font></div><div><font face="Calibri"> ELSE RETURN 0; END;</font></div><div><font face="Calibri">END Compare;</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">PROCEDURE Equal(a,b:T): BOOLEAN =</font></div><div><font face="Calibri">BEGIN</font></div><div><font face="Calibri"> RETURN a = b;</font></div><div><font face="Calibri">END Equal;</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">PROCEDURE ToText(a:T): TEXT</font></div><div><font face="Calibri">BEGIN</font></div><div><font face="Calibri"> return Fmt.Int(a);</font></div><div><font face="Calibri">END ToText;</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">PROCEDURE Copy(from:T; VAR to:T) =</font></div><div><font face="Calibri">BEGIN</font></div><div><font face="Calibri"> to := from;</font></div><div><font face="Calibri">END Copy;</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">PROCEDURE Init(VAR a:T);</font></div><div><font face="Calibri">BEGIN</font></div><div><font face="Calibri"> a := 0;</font></div><div><font face="Calibri">END Init;</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">PROCEDURE New():T;</font></div><div><font face="Calibri">BEGIN</font></div><div><font face="Calibri"> RETURN 0;</font></div><div><font face="Calibri">END New;</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">END TypeUID;</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">OR TypeUID is very transparent, everyone knows it is an integer</font></div><div><font face="Calibri">and everyone just does integer "operations" on it.</font></div><div><font face="Calibri">And it probably can never change.</font></div><div><font face="Calibri">But hopefully they never get added.</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">Note of course that the abstract variation isn't very good</font></div><div><font face="Calibri">at protecting the abstration.</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">It is probably desirable to be able to say:</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">INTERFACE</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">TYPE T; (* fully opaque *)</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">MODULE</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">REVEAL T = INTEGER;</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">I understand this is hard to do efficiently.</font></div><div><font face="Calibri">You either need a really good "cross-module compiler",</font></div><div><font face="Calibri">or you need to heap allocate them all.</font></div><div><font face="Calibri">A simple compiler that produces efficient code motivates</font></div><div><font face="Calibri">revealing the type in public.</font></div><div><font face="Calibri">That is unfortunate.</font></div><div><font face="Calibri">For example, adding TypeUIDs is probably nonsense</font></div><div><font face="Calibri">and worth prohibiting. But by publically revealing</font></div><div><font face="Calibri">it is an INTEGER (essentially), extra unintended operations</font></div><div><font face="Calibri">are allowed on it.</font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri">(C++ solves... since you can have a class that is small,</font></div><div><font face="Calibri">and the clients know the size, and allocate room for it,</font></div><div><font face="Calibri">yet all the data members could be private. The language</font></div><div><font face="Calibri">is complicated, but the goal of allowing powerful efficient user</font></div><div><span style="font-family: Calibri; ">defined types is a good one, and achieved very well</span><span style="font-family: Calibri; ">)</span></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"><br></font></div><div><font face="Calibri"> - Jay</font></div><div style="font-family: Calibri; font-size: 12pt; "><br></div><br><br><br><br><div style="font-family: Calibri; font-size: 12pt; "><div id="SkyDrivePlaceholder"></div><hr id="stopSpelling">Subject: Re: [M3devel] M3CG<br>From: hosking@cs.purdue.edu<br>Date: Wed, 5 Sep 2012 22:07:24 -0400<br>CC: m3devel@elegosoft.com<br>To: jay.krell@cornell.edu<br><br><div><span class="ecxApple-style-span" style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;orphans:2;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;widows:2;word-spacing:0px;font-size:medium"><span class="ecxApple-style-span" style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;orphans:2;text-indent:0px;text-transform:none;white-space:normal;widows:2;word-spacing:0px"><div style="word-wrap:break-word"><span class="ecxApple-style-span" style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;orphans:2;white-space:normal;widows:2;word-spacing:0px"><div style="word-wrap:break-word"><span class="ecxApple-style-span" style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;orphans:2;white-space:normal;widows:2;word-spacing:0px"><span class="ecxApple-style-span" style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;orphans:2;white-space:normal;widows:2;word-spacing:0px"><span class="ecxApple-style-span" style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;orphans:2;white-space:normal;widows:2;word-spacing:0px"><span class="ecxApple-style-span" style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;orphans:2;white-space:normal;widows:2;word-spacing:0px"><span class="ecxApple-style-span" style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;orphans:2;white-space:normal;widows:2;word-spacing:0px"><span class="ecxApple-style-span" style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;orphans:2;white-space:normal;widows:2;word-spacing:0px"><span class="ecxApple-style-span" style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;orphans:2;white-space:normal;widows:2;word-spacing:0px"><span class="ecxApple-style-span" style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;orphans:2;white-space:normal;widows:2;word-spacing:0px"><div>On Sep 5, 2012, at 10:06 PM, Antony Hosking <<a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a>> wrote:</div></span></span></span></span></span></span></span></span></div></span></div></span></span></div><div><br class="ecxApple-interchange-newline"><blockquote><div style="word-wrap:break-word">Jay, I just checked in the following to M3CG.i3:<div><br></div><div><div>TYPE</div><div> Int32 = [-16_7fffffff-1 .. 16_7fffffff];</div><div> TypeUID = BITS 32 FOR Int32;</div></div><div><br></div><div>Feel free to use M3CG.Int32.</div><div>At least this way, if anything changes TypeUID it will be clear that someone might be relying on TypeUID.</div></div></blockquote><div><br></div><div>I meant Int32.</div><br><blockquote><div style="word-wrap:break-word"><div><br></div><div><br><div>
<span class="ecxApple-style-span" style="border-collapse:separate;border-spacing:0px"><span class="ecxApple-style-span" style="border-collapse:separate;font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;orphans:2;text-indent:0px;text-transform:none;white-space:normal;widows:2;word-spacing:0px;border-spacing:0px"><div style="word-wrap:break-word"><span class="ecxApple-style-span" style="border-collapse:separate;border-spacing:0px;font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;orphans:2;white-space:normal;widows:2;word-spacing:0px"><div style="word-wrap:break-word"><span class="ecxApple-style-span" style="border-collapse:separate;border-spacing:0px;font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;orphans:2;white-space:normal;widows:2;word-spacing:0px"><span class="ecxApple-style-span" style="border-collapse:separate;border-spacing:0px;font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;orphans:2;white-space:normal;widows:2;word-spacing:0px"><span class="ecxApple-style-span" style="border-collapse:separate;border-spacing:0px;font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;orphans:2;white-space:normal;widows:2;word-spacing:0px"><span class="ecxApple-style-span" style="border-collapse:separate;border-spacing:0px;font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;orphans:2;white-space:normal;widows:2;word-spacing:0px"><span class="ecxApple-style-span" style="border-collapse:separate;border-spacing:0px;font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;orphans:2;white-space:normal;widows:2;word-spacing:0px"><span class="ecxApple-style-span" style="border-collapse:separate;border-spacing:0px;font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;orphans:2;white-space:normal;widows:2;word-spacing:0px"><span class="ecxApple-style-span" style="border-collapse:separate;border-spacing:0px;font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;orphans:2;white-space:normal;widows:2;word-spacing:0px"><span class="ecxApple-style-span" style="border-collapse:separate;border-spacing:0px;font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;orphans:2;white-space:normal;widows:2;word-spacing:0px"><div><font class="ecxApple-style-span" color="#0000FF"><font class="ecxApple-style-span" face="Gill Sans"><span class="ecxApple-style-span" style="color:rgb(0, 0, 255);font-family:'Gill Sans'"><span class="ecxApple-style-span" style="color:rgb(0, 0, 255);font-family:'Gill Sans'">Antony Hosking</span></span></font></font><font class="ecxApple-style-span" face="Gill Sans"><span class="ecxApple-style-span" style="font-family:'Gill Sans'"><span class="ecxApple-style-span" style="font-family:'Gill Sans'"><span class="ecxApple-converted-space"> </span>|<span class="ecxApple-converted-space"> </span></span></span><span class="ecxApple-style-span" style="font-family:'Gill Sans'"><span class="ecxApple-style-span" style="font-family:'Gill Sans'">Associate Professor</span></span><span class="ecxApple-style-span" style="font-family:'Gill Sans'"><span class="ecxApple-style-span" style="font-family:'Gill Sans'"> | Computer Science | Purdue University</span></span></font></div><div><font class="ecxApple-style-span" face="GillSans-Light"><span class="ecxApple-style-span" style="font-family:GillSans-Light">305 N. University Street | West Lafayette | IN 47907 | USA</span></font></div><div><font class="ecxApple-style-span" color="#0000FF" face="Gill Sans"><span class="ecxApple-style-span" style="color:rgb(0, 0, 255);font-family:'Gill Sans'"><span class="ecxApple-style-span" style="color:rgb(0, 0, 255);font-family:'Gill Sans'">Mobile</span></span></font><font class="ecxApple-style-span" face="GillSans-Light"><span class="ecxApple-style-span" style="font-family:GillSans-Light"><span class="ecxApple-style-span" style="font-family:GillSans-Light"><span class="ecxApple-converted-space"> </span>+1 765 427 5484</span></span></font></div><div><font class="ecxApple-style-span" face="GillSans-Light"><br class="ecxkhtml-block-placeholder"></font></div></span></span></span></span></span></span></span><br class="ecxApple-interchange-newline"></span></div></span></div></span><br class="ecxApple-interchange-newline"></span><br class="ecxApple-interchange-newline">
</div>
<br><div><div>On Sep 5, 2012, at 8:56 PM, Jay <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:</div><br class="ecxApple-interchange-newline"><blockquote><div><div>And if TypeUID changes?</div><div><br></div><div>I want to store a TypeUID. I want to treat it opaquely/abstractly. It can change & I'd still store it correctly & efficiently. I should not go looking at it & cloning it. That seems like sound engineering. ?<br><br> - Jay (briefly/pocket-sized-computer-aka-phone)</div><div><br>On Sep 5, 2012, at 1:41 PM, Antony Hosking <<a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a>> wrote:<br><br></div><div><span></span></div><blockquote>Jay, why don't you just us a local subrange for your fields in the records and then simply assign to/from TypeUID values?<div><br></div><div>RECORD typeid: [-16_7fffffff-1 .. 16_7fffffff] END;</div><div><br></div><div>You won't pay any penalty for range checks since the subranges are exactly the same.</div><div>
<br><div><div>On Sep 5, 2012, at 2:34 PM, Jay K <<a href="mailto:jay.krell@cornell.edu"></a><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:</div><br class="ecxApple-interchange-newline"><blockquote><div class="ecxhmmessage" style="font-size:12pt;font-family:Calibri;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;orphans:2;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;widows:2;word-spacing:0px"><div dir="ltr">I should really insert padding manually?<br>I don't know if I like that or not.<br> <br><br>My code is/was something like:<br><br> TYPE T1 = RECORD <span class="ecxApple-converted-space"> </span><br> text: TEXT; <span class="ecxApple-converted-space"> </span><br> typeid: TypeUID; <span class="ecxApple-converted-space"> </span><br> END;<br> <br><br>and that errors on some platforms.<br> <br><br>I'm not using "Multipass" right now, but it does still hold possible value.<br>We can remove multipass from m3makefile for nowif that helps.<br> <br> <br>Given a similar problem in C, I would do something like:<br> <br>/* TypeUID must fit in 32 bits, for some reason. */<br>C_ASSERT(sizeof(TypeUID) <= sizeof(UINT32));<br>Where C_ASSERT is in windows.h and looks like:<br>/* compile time assert */<span class="ecxApple-converted-space"> </span><br> #define C_ASSERT(expression) typedef char __cassert__[(expression) ? 1 : -1];<br> or somesuch. The error message isn't great when it fails.<span class="ecxApple-converted-space"> </span><br> <br>People also name this "static_assert". It is popular.<br> <br> It doesn't prohibit it from having padding around it, but it does assert it fits in 32 bits.<br><br> I recall we can do similar in Modula-3.<span class="ecxApple-converted-space"> </span><br><br> TYPE assertTypeUIDFitsIn32Bits = ARRAY [0..ORD(BITSIZE(TypeUID) <= 32)] OF INTEGER;<span class="ecxApple-converted-space"> </span><br> or to be more certain:<span class="ecxApple-converted-space"> </span><br> TYPE assertTypeUIDFitsIn32Bits = ARRAY [0..-ORD(BITSIZE(TypeUID) <= 32)] OF INTEGER;<span class="ecxApple-converted-space"> </span><br><br>I'm not sure 0..0 is illegal, but I think 0 .. 1 is.<br><br>(I sure do miss macros...this is too much syntax for a compile time assert...)<br><br>Can we just put <* ASSERT BITSIZE(TypeUID) <= 32 *> in the .i3 file? Or elsewhere?<br> <br><br> - Jay<br> <br><div><div id="ecxSkyDrivePlaceholder"></div>> From:<span class="ecxApple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu"></a><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> Date: Wed, 5 Sep 2012 11:36:03 -0400<br>> To:<span class="ecxApple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu"></a><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> CC:<span class="ecxApple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com"></a><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>> Subject: Re: [M3devel] M3CG<br>><span class="ecxApple-converted-space"> </span><br>> As I recall you were having trouble with alignment, right?<br>><span class="ecxApple-converted-space"> </span><br>> In which case, why not pad your record type out to a reasonably aligned value? As in:<br>><span class="ecxApple-converted-space"> </span><br>> CONST PadRange = Word.LeftShift(1, BITSIZE(ADDRESS) - BITSIZE(TypeUID)) - 1;<br>> RECORD<br>> t: TypeUID;<br>> pad: BITS BITSIZE(ADDRESS) - 32 FOR [0..PadRange];<br>> END;<br>><span class="ecxApple-converted-space"> </span><br>><span class="ecxApple-converted-space"> </span><br>><span class="ecxApple-converted-space"> </span><br>> On Sep 5, 2012, at 11:18 AM, Antony Hosking <<a href="mailto:hosking@cs.purdue.edu"></a><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a>> wrote:<br>><span class="ecxApple-converted-space"> </span><br>> > Remind me again why you can't use TypeUID as is?<br>> > There is nothing in the language spec that prohibits packed types in records.<br>> ><span class="ecxApple-converted-space"> </span><br>> > On Sep 5, 2012, at 10:50 AM, Jay K <<a href="mailto:jay.krell@cornell.edu"></a><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:<br>> ><span class="ecxApple-converted-space"> </span><br>> >> This seems quite wrong from a simple engineering/design/factoring/abstraction point of view.<br>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >> Imagine I have a few of these things. They are subranges or enums. That fit in a smaller size.<br>> >> Wouldn't it be nice, to just use the type directly and get the space savings? Opportunistically?<br>> >> What if the type is a REAL or a LONGINT?<br>> >> I want the type to be opaque/abstract where that is easy and cheap and this certainly seems like an easy/cheap place to have slightly valuable opacity.<br>> >> Isn't it really good, more than "just nice" to let the type change and have a lot of code work just as well?<br>> >> Because they didn't copy around knowledge of what the type is?<br>> >> What if the type changes?<br>> >> Anyone just copying it around by exact restated typename is unaffected.<br>> >> Anyone who looked at and decided to restate the definition might type might be broken.<br>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >> And again, really -- you want to sacrifice both performance and abstraction when both are easily kept better?<br>> >> That is, I'm all for range checks to keep things "safe", safety is important, but in this case you can easily preserve safety w/o adding range checks.<br>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >> We do have enums at this layer.<br>> >> Would you suggest I take the ORD of all of those and store them in INTEGERs too?<br>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >> I am really surprised.<br>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >> - Jay<br>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >> From: <a href="mailto:hosking@cs.purdue.edu"></a><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> >> Date: Wed, 5 Sep 2012 10:33:58 -0400<br>> >> To: <a href="mailto:dragisha@m3w.org"></a><a href="mailto:dragisha@m3w.org">dragisha@m3w.org</a><br>> >> CC: <a href="mailto:m3devel@elegosoft.com"></a><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a>; <a href="mailto:jay.krell@cornell.edu"></a><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> >> Subject: Re: [M3devel] M3CG<br>> >><span class="ecxApple-converted-space"> </span><br>> >> Precisely.<br>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >> On Sep 5, 2012, at 3:40 AM, Dragiša Durić <<a href="mailto:dragisha@m3w.org"></a><a href="mailto:dragisha@m3w.org">dragisha@m3w.org</a>> wrote:<br>> >><span class="ecxApple-converted-space"> </span><br>> >> Why holding/passing of this value in INTEGER would be a problem? As long as range checks are passed on "assignment boundaries", it is all well.<br>> >><span class="ecxApple-converted-space"> </span><br>> >> It is how Modula-3 does things.<span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >> --<br>> >> Divided by a common language<br>> >><span class="ecxApple-converted-space"> </span><br>> >> Dragiša Durić<br>> >> <a href="mailto:dragisha@m3w.org"></a><a href="mailto:dragisha@m3w.org">dragisha@m3w.org</a><br>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >> On Sep 4, 2012, at 10:47 PM, Jay K wrote:<br>> >><span class="ecxApple-converted-space"> </span><br>> >> RECORD HoldsTypeUID:<br>> >> typeuid: [FIRST(TypeUID)..LAST(TypeUID)];<br>> >> END?<br>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >> But what if I'm really just a holder/passer of this thing,<br>> >> and I never interpret it. Now TypeUID can't be changed<br>> >> to LONGREAL or somesuch. Ideally some code wouldn't care<br>> >> and still be correct.<br>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >> The idea is to hold the thing, pass it on, without knowing<br>> >> what it is. I want a field with the same type.<br>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >> Why does it matter if TypeUID is representable in 32 bits?<br>> >> Isn't the range the interface?<br>> >> If it wasn't for readability of all the F's, I think<br>> >> TypeUID = [-16_7FFFFFFF - 1 .. 16_7FFFFFFF]; is best.<br>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >> Do we really care about few or many bits that occupies?<br>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >> Cstdint.int32_t I agree is a bit lazy.<br>> >> Maybe something like Word.Shift(1, 31) .. Word.Not(Word.Shift(1, 31)) ?<br>> >> A bit wordy but ok.<br>> >> Maybe not correct. Not clear the start is negative.<br>> >> Maybe needs to be more like:<br>> >><span class="ecxApple-converted-space"> </span><br>> >> (-Word.Not(Word.Shift(1, 31))) - 1 .. Word.Not(Word.Shift(1, 31))<span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >> But these bit twiddlings might then confuse people.<br>> >> So maybe having to count F's is better.. :(<br>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >> You know, what about being 32bits in size would be part of an interface?<br>> >> I don't think much/anything, but maybe.<br>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >> Do we do/allow things like bit operations on it? Index into it a certain number<br>> >> of bits? Take the address and assume BYTESIZE == 4?<br>> >> I could see those maybe occuring. Maybe.<br>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >> But I'm pretty sure they values are fairly abstract/opaque and the best anyone can do<br>> >> is format them as strings and compare them for e.g. sorting purposes, but must<br>> >> assume they are fairly sparse.<br>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >> Btw, whenever the matter of "portability to signed-magnitude" or one's complement<br>> >> comes up, I admit I get a bit confused. Two's complement is very ingrained<br>> >> in my world view.<br>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >> I agree TInt.T suffices.<br>> >> Just like CARDINAL isn't needed, INTEGER suffices.<br>> >> Cardinal.T just disallows negative numbers earlier, or at lower level, etc.<br>> >> If we had to use TInt.T and add checks in a few places that it >= 0, ok.<br>> >> It seems a little nice to put the checking in.<br>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >> - Jay<br>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >><span class="ecxApple-converted-space"> </span><br>> >> > Subject: Re: M3CG<br>> >> > From: <a href="mailto:hosking@cs.purdue.edu"></a><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> >> > Date: Tue, 4 Sep 2012 13:05:34 -0400<br>> >> > CC: <a href="mailto:m3devel@elegosoft.com"></a><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>> >> > To: <a href="mailto:jay.krell@cornell.edu"></a><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> >> ><span class="ecxApple-converted-space"> </span><br>> >> > On Sep 4, 2012, at 12:09 PM, Jay <<a href="mailto:jay.krell@cornell.edu"></a><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:<br>> >> ><span class="ecxApple-converted-space"> </span><br>> >> > > "BITS" seems to not provide any useful value. It only makes it so you can't put the type into a portable unpacked record, which is what I was doing. I either have to pack my record somehow (counting target-dependent bits??) or lay out the fields carefully in some way that all targets allow. The problem was that some targets didn't like the layout.<br>> >> ><span class="ecxApple-converted-space"> </span><br>> >> > For M3CG.TypeUID the BITS 32 enforces that it is always representable in 32 bits. This is a fundamental invariant of the compiler and run-time system. Removing it might allow bug creep. You don't need to pack your record. You just need a field sufficiently large to hold the value of a type id. In this instance an INTEGER field would suffice, or you can use the same subrange.<br>> >> ><span class="ecxApple-converted-space"> </span><br>> >> > > Given the stated range, that you'll get enough bits to store it, what is the point in giving the size too? Isn't providing just the range and no particular size, sufficient & more abstract? Granted, I went the other way.<br>> >> ><span class="ecxApple-converted-space"> </span><br>> >> > Only if an implementation chooses to store a subrange in as few bits as necessary. Yes, CM3 does this, but it is not guaranteed by the language spec. Here the size is the critical invariant.<br>> >> ><span class="ecxApple-converted-space"> </span><br>> >> > > I don't remember but guessing:<br>> >> > ><span class="ecxApple-converted-space"> </span><br>> >> > ><span class="ecxApple-converted-space"> </span><br>> >> > > Cardinal.T would be, like CARDINAL vs. INTEGER: only slightly subtley useful: same as TInt.T, but disallows negative numbers.<br>> >> ><span class="ecxApple-converted-space"> </span><br>> >> > But for what purpose. The target does not have CARDINAL. It only has a target integer.<br>> >> ><span class="ecxApple-converted-space"> </span><br>> >> > > Most likely I ran into places where a host integer/cardinal did not necessarily suffice, and so a target type was called for.<br>> >> > ><span class="ecxApple-converted-space"> </span><br>> >> > ><span class="ecxApple-converted-space"> </span><br>> >> > > I know we have places that need to use target types but don't yet. Specifically for the sizes of things like records & arrays. Otherwise we have hacks where 64bit systems declare 32bit limits.<br>> >> ><span class="ecxApple-converted-space"> </span><br>> >> > Again, TInt.T suffices for all of these.<br>> >> ><span class="ecxApple-converted-space"> </span><br>> >> > ><span class="ecxApple-converted-space"> </span><br>> >> > ><span class="ecxApple-converted-space"> </span><br>> >> > > - Jay (briefly/pocket-sized-computer-aka-phone)<br>> >> > ><span class="ecxApple-converted-space"> </span><br>> >> > > On Sep 4, 2012, at 7:11 AM, Antony Hosking <<a href="mailto:hosking@cs.purdue.edu"></a><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a>> wrote:<br>> >> > ><span class="ecxApple-converted-space"> </span><br>> >> > >> Jay,<br>> >> > >><span class="ecxApple-converted-space"> </span><br>> >> > >> I've been looking over some of your changes to M3CG interfaces. You'll notice that I removed your import of Cstdlib.int into M3CG_Ops.i3. It does not belong there. The type as declared:<br>> >> > >><span class="ecxApple-converted-space"> </span><br>> >> > >> TypeUID = BITS 32 FOR [-16_7fffffff-1 .. 16_7fffffff];<br>> >> > >><span class="ecxApple-converted-space"> </span><br>> >> > >> is correct as is. It is a 32 bit value that encodes a particular subrange, REGARDLESS of target machine. It is improper to change that definition to rely on some C type.<br>> >> > >><span class="ecxApple-converted-space"> </span><br>> >> > >> I also have some other questions. Why did you add the type Cardinal.T? This seems entirely unnecessary, since targets don't have a Cardinal type. The only type they have is a target integer. All other Modula-3 ordinal types should be simulated in the compiler using TInt.T. I would advise that it be removed. Also, I don't understand why you changed descriptions of the primitive types to use this Cardinal.T instead of the original CARDINAL to hold information about the bit size, alignment, and byte size. There is no situation in which a host will need to emulate the behavior of CARDINAL for these values (all can be represented using CARDINAL no matter what the host).<br>> >> > >><span class="ecxApple-converted-space"> </span><br>> >> > >> I am concerned that these changes reflect a desire on your part to change the world to fit your specific needs (whether justified or not). The interfaces defined in M3CG were carefully designed and inherit from a long code-chain going back to the 1980's and have not see huge changes since then. I strongly advise against making changes unless you have good reason, because there are a number of tools that rely on M3CG (not just those in the public sources).<br>> >> > >><span class="ecxApple-converted-space"> </span><br>> >> > >> I am going to do a pass to revert some of your changes, since they are causing a number of my systems to fail to build. (cf. Niagara on tinderbox).<br>> >> > >><span class="ecxApple-converted-space"> </span><br>> >> > >> I strongly advise that you try to use a private branch when developing new functionality. We as a community can then go through a revision process to vet substantive changes before merging them into the trunk.<br>> >> > >><span class="ecxApple-converted-space"> </span><br>> >> > >> - Tony<br>> >> > >><span class="ecxApple-converted-space"> </span><br>> >> ><br>> ><span class="ecxApple-converted-space"> </span><br>></div></div></div></blockquote></div><br></div></blockquote></div></blockquote></div><br></div></div></blockquote></div><br></div> </div></body>
</html>