[m-dev.] questions about null vs 0 in argument packing

[Zoltan Somogyi]

I have questions about the behavior of argument packing
with respect to NULL pointers. It seems to me that the MLDS
code generator is transforming mlconst_nulls into mlconst_int(0)s
almost randomly, and wondering why this is not a problem
on the C# and Java backends. (I don't expect this to be a problem
for C, since in C, NULL is just a 0 with a cast.)

The problematic chain of calls is this.

- pack_args (in arg_pack.m) is given a list of rvals, which may
  include mlconst_nulls.

- If all the rvals are full words, then the arguments, including any
  mlconst_nulls, are left alone.

- If some are *not* full words, then pack_args calls do_pack_args,
  which invokes ShiftCombine on every rval, even when that rval
  is not being packed.

- The caller of arg_pack in ml_unify_gen.m will specify
  ml_shift_combine_rval or ml_shift_combine_rval_type
  as ShiftCombine. Both of those predicates apply ml_lshift
  to every rval, even the ones not being packed together
  with anything else.

- ml_lshift replaces mlconst_nulls with mlconst_int(0)s,
  presumably because this is the right thing to do for values being
  packed, but I don't know whether a value being packed
  (which at the moment is always an enum) can ever be mlconst_null.

All of this means that whether a full word mlconst_null in a cell
being constructed is replaced with mlconst_int(0) depends on the
"random" answer to the question: is there another word in the cell
that contains two or more packed arguments?

My questions are:

1 Was this semi-random conversion behavior designed or did it
  just happen? If it was designed, what is the reason for it?

2 Has this semi-random conversion led to any problems
  in programs using the C# or Java backends?

3 If not, why not? My understanding is that in C# and Java,
  a null is NOT the same as 0.

4 Would anyone object if I changed things so that mlconst_nulls
  that are not being packed were left alone? This *would* generate
  different C# and Java code than before, whose validity I cannot check.

5 Would anyone object if I changed things so that mlconst_nulls
  that *are* being packed aborted the compiler, so we could check
  whether such things actually occur? I would commit this only
  if it passed bootcheck in hlc.gc, obviously, but I can't bootcheck it
  in C# or Java.

Zoltan.