[M3devel] reference to globals in globals?

[Rodney M. Bates]

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