[M3devel] reference to globals in globals?

[Tony Hosking]

Jay,

Any time you want to pass a reference to a local/global as a parameter you can use VAR/READONLY parameter mode.

I don’t know enough about your use-case to understand what you are trying to do.


On Aug 15, 2012, at 10:51 AM, "Rodney M. Bates" <rodney_bates at lcwb.coop> wrote:

> 
> 
> On 08/14/2012 10:04 PM, Jay K wrote:
>> Isn't it safe to take the address of a global?
>> 
> 
> Do you mean can't you use the ADR function in safe code
> if you apply it only to a global variable?  The answer
> to that is no.  The ADR function is illegal altogether in
> safe code.
> 
> As to why, I can only speculate, but see below.  I suspect
> even in this case, it is not as simple as it seems.
> 
>> 
>> I have something like this:
>> 
>> 
>> CONST UID_INTEGER = 1234;
>> CONST UID_FLOAT = 4567;
>>   ... several more ...
>> 
>> 
>> TYPE CType = OBJECT .. END;
>> 
>> 
>> VAR t_int: CType := ...;
>> VAR t_float: CType := ...;
>>   ... several more ...
>> 
>> 
>> MapTypeIdToType(UID_INTEGER, t_int);
>> MapTypeIdToType(UID_FLOAT, FLOAT);
>>   ... several more ...
>> 
>> 
>> but what I really want is more like:
>> 
>> 
>> TYPE RECORD = BuiltinUid_t =
>>   typeid: INTEGER;
>>   ctype: REF CType;
> 
>            ^UNTRACED REF?  If it were just REF, that would imply that
> your global variable (the pointer it contains) is a heap object, that
> it has heap allocator/GC overhead data attached to it, and that the GC
> should trace it, none of which is true.
> 
> 
>> END;
>> 
>> 
>> CONST BuiltinUids = ARRAY OF BuiltinUids {
>>   BuiltinUids{UID_INTEGER, &t_int},
>>   BuiltinUids{UID_FLOAT, &t_float},
> 
> ADR instead of &?  If so, you are still not there, because ADR
> returns a value of type ADDRESS, i.e., an untraced reference to
> we-don't-know-what.  Somewhere, you would also have to use a
> LOOPHOLE to get it to UNTRACED REF CType.
> 
>>   ... several more ...
>> };
>> 
>> 
>> FOR i := FIRST(BuiltinUids) TO LAST(BuiltinUids) DO
>>   MapTypeIdToType(BuiltinUids[i].typeid, BuiltinUids[i].ctype);
>> END;
>> 
> 
> I don't know what the signature of MapTypeIdToType is, but above,
> you are passing a variable of object type to its 2nd parameter,
> (which contains a traced reference to the actual heap object).
> But here, you pass the _address_ of the above.  Inconsistent
> number of levels of indirection.  A static safe language is
> much more likely to help with things like this.
> 
> Maybe you just want to say
> 
> TYPE RECORD = BuiltinUid_t =
>   typeid: INTEGER;
>   ctype: CType;
> 
> and
> 
> BuiltinUids{UID_INTEGER, t_int}?
> 
> This would be equivalent to your first way, and doesn't require any
> unsafe coding at all.
> 
> Or, you could do away with global variable t_int altogether and
> just initialize directly into BuiltinUids[..].ctype with whatever
> expression you used to initialize t_int.  It looks like your array
> makes the t_int and cousins redundant.
> 
>> 
>> Heck, even if these weren't global, is it that unreasonble,
>> from the programmer's point of view, for the language/compiler
>> to do some pointer escape analysis and let me take the address
>> of a local, as long as I don't store it somewhere that outlives
>> the local?
>> 
> 
> This is ultimately an undecidable problem and even conservative
> approximations of reasonable sophistication are far too involved
> for a language to require of every compiler.
> 
>> 
>> You can see this particular pattern currently in
>> m3-sys/m3cc/gcc/gcc/m3cg/parse.c
>> 
>> 
>> and I'm pretty busy now working on m3-sys/m3back/src/M3C.m3
>> where I encounter this.
>> 
>> 
>> Working in safe languages can be frustrating...
>> 
> 
> It's just an instant/deferred gratification thing.  Safe languages often
> make you stop and fix it before you run it.  Unsafe languages let you naively
> forge ahead to the next step, where the bug is likely to be *much* harder to
> diagnose, assuming you even have enough test cases to notice it at all during
> development.  Your code here is a good example.
> 
> Of course, safe languages occasionally make you unnecessarily write a bit more
> code to do it the safe way.  E.g., the famous fake pointer to the root of a
> linked list example.  In my personal experience, these times are at least
> one order of magnitude less frequent than the times safe languages reduce
> great pain to minor pain, albeit sooner.  If fact, if you are accustomed to
> thinking in type-safe terms, it is seldom any harder to code it safely in the
> first place.
> 
> You're making it too difficult.
> 
>> 
>> Thank you,
>>  - Jay
>