<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi all:<br>we
need to calculate first Module instantiation in Modula-3 in SPIN
MODULE_UNIT, that is trying to establish first Module instantiation,
initialization, and then you can extract CONST "address" in the actual
case is similar to that, a pointer to an address of the actual value,
if pointer is NIL valued then it needed initialization in compile time
else is a RT error to use its value, as we have proposed in other cases.<br>Jay, please see this BitC language, has constructors for all those RT structures of your new back-end (hope you enjoy it, see p. 14, s. 3.6.2, Tag Representation):<br>http://bitc-lang.org/docs/bitc/spec.pdf<br>).<br>This leads in some special architectures to a double pointer-sized machine word type, which is why I talked about LONGADDRESS proposal.<br>Thanks in advance<br><br>--- El <b>mié, 15/8/12, Jay
 <i><jay.krell@cornell.edu></i></b> escribió:<br><br>De: Jay <jay.krell@cornell.edu><br>Asunto: Re: [M3devel] reference to globals in globals?<br>Para: "Tony Hosking" <hosking@cs.purdue.edu><br>CC: "m3devel@elegosoft.com developers" <m3devel@elegosoft.com>, "Jay K" <jay.krell@cornell.edu><br>Fecha: miércoles, 15 de agosto, 2012 11:56<br><br>I
restructured the code but it still bothers me. Getting the levels of
indirection correct is checked for you in C/C++ as '&' returns a
stronger type than 'ADR'.<br>I didn't want the array only because then I could only access the data more verbosely/slowly via the array.  More later, maybe.<br><br> - Jay (briefly/pocket-sized-computer-aka-phone)<br><br>On Aug 15, 2012, at 12:11 PM, Tony Hosking <<a rel="nofollow">hosking@cs.purdue.edu</a>> wrote:<br><br>> Jay,<br>> <br>> Any time you want to pass a reference to a local/global as a parameter you can use VAR/READONLY parameter mode.<br>> <br>> I don’t know enough about your use-case to understand what you are trying to do.<br>> <br>> <br>> On Aug 15, 2012, at 10:51 AM, "Rodney M. Bates" <<a rel="nofollow">rodney_bates@lcwb.coop</a>> wrote:<br>> <br>>> <br>>> <br>>> On 08/14/2012 10:04 PM, Jay K wrote:<br>>>> Isn't it safe to take the address of a global?<br>>>> <br>>> <br>>> Do you mean can't you use the ADR function in safe code<br>>> if
 you apply it only to a global variable?  The answer<br>>> to that is no.  The ADR function is illegal altogether in<br>>> safe code.<br>>>
 <br>>> As to why, I can only speculate, but see below.  I suspect<br>>> even in this case, it is not as simple as it seems.<br>>> <br>>>> <br>>>> I have something like this:<br>>>> <br>>>> <br>>>> CONST UID_INTEGER = 1234;<br>>>> CONST UID_FLOAT = 4567;<br>>>>  ... several more ...<br>>>> <br>>>> <br>>>> TYPE CType = OBJECT .. END;<br>>>> <br>>>> <br>>>> VAR t_int: CType := ...;<br>>>> VAR t_float: CType := ...;<br>>>>  ... several more ...<br>>>> <br>>>> <br>>>> MapTypeIdToType(UID_INTEGER, t_int);<br>>>> MapTypeIdToType(UID_FLOAT, FLOAT);<br>>>>  ... several more ...<br>>>> <br>>>> <br>>>> but what I really want is more like:<br>>>> <br>>>> <br>>>> TYPE RECORD = BuiltinUid_t
 =<br>>>>  typeid: INTEGER;<br>>>>  ctype: REF CType;<br>>> <br>>>           ^UNTRACED REF?  If it were just REF, that would imply that<br>>> your global variable (the pointer it contains) is a heap object, that<br>>> it has heap allocator/GC overhead data attached to it, and that the GC<br>>> should trace it, none of which is true.<br>>> <br>>> <br>>>> END;<br>>>> <br>>>> <br>>>> CONST BuiltinUids = ARRAY OF BuiltinUids {<br>>>>  BuiltinUids{UID_INTEGER, &t_int},<br>>>>  BuiltinUids{UID_FLOAT, &t_float},<br>>> <br>>> ADR instead of &?  If so, you are still not there, because ADR<br>>> returns a value of type ADDRESS, i.e., an untraced reference to<br>>> we-don't-know-what.  Somewhere, you would also have to use a<br>>> LOOPHOLE to
 get it to UNTRACED REF CType.<br>>> <br>>>>  ... several more ...<br>>>> };<br>>>> <br>>>> <br>>>> FOR i := FIRST(BuiltinUids) TO LAST(BuiltinUids) DO<br>>>>  MapTypeIdToType(BuiltinUids[i].typeid, BuiltinUids[i].ctype);<br>>>> END;<br>>>> <br>>> <br>>> I don't know what the signature of MapTypeIdToType is, but above,<br>>> you are passing a variable of object type to its 2nd parameter,<br>>> (which contains a traced reference to the actual heap object).<br>>> But here, you pass the _address_ of the above.  Inconsistent<br>>> number of levels of indirection.  A static safe language is<br>>> much more likely to help with things like this.<br>>> <br>>> Maybe you just want to say<br>>> <br>>> TYPE RECORD = BuiltinUid_t =<br>>>  typeid: INTEGER;<br>>>  ctype:
 CType;<br>>> <br>>> and<br>>> <br>>> BuiltinUids{UID_INTEGER, t_int}?<br>>> <br>>> This would be equivalent to your first way, and doesn't require any<br>>> unsafe coding at all.<br>>> <br>>> Or, you could do away with global variable t_int altogether and<br>>> just initialize directly into BuiltinUids[..].ctype with whatever<br>>> expression you used to initialize t_int.  It looks like your array<br>>> makes the t_int and cousins redundant.<br>>> <br>>>> <br>>>> Heck, even if these weren't global, is it that unreasonble,<br>>>> from the programmer's point of view, for the language/compiler<br>>>> to do some pointer escape analysis and let me take the address<br>>>> of a local, as long as I don't store it somewhere that outlives<br>>>> the local?<br>>>> <br>>> <br>>> This is ultimately an
 undecidable problem and even conservative<br>>> approximations of reasonable sophistication are far too involved<br>>> for a language to require of every compiler.<br>>> <br>>>> <br>>>> You can see this particular pattern currently in<br>>>> m3-sys/m3cc/gcc/gcc/m3cg/parse.c<br>>>> <br>>>> <br>>>> and I'm pretty busy now working on m3-sys/m3back/src/M3C.m3<br>>>> where I encounter this.<br>>>> <br>>>> <br>>>> Working in safe languages can be frustrating...<br>>>> <br>>> <br>>> It's just an instant/deferred gratification thing.  Safe languages often<br>>> make you stop and fix it before you run it.  Unsafe languages let you naively<br>>> forge ahead to the next step, where the bug is likely to be *much* harder to<br>>> diagnose, assuming you even have enough test cases to notice it at all
 during<br>>> development.  Your code here is a good example.<br>>> <br>>> Of course, safe languages occasionally make you unnecessarily write a bit more<br>>> code to do it the safe way.  E.g., the famous fake pointer to the root of a<br>>> linked list example.  In my personal experience, these times are at least<br>>> one order of magnitude less frequent than the times safe languages reduce<br>>> great pain to minor pain, albeit sooner.  If fact, if you are accustomed to<br>>> thinking in type-safe terms, it is seldom any harder to code it safely in the<br>>> first place.<br>>> <br>>> You're making it too difficult.<br>>> <br>>>> <br>>>> Thank you,<br>>>> - Jay<br>>> <br>> <br><br></td></tr></table>