[MLton-user] option ref optimized to a null pointer?

[Vesa Karvonen]

On Nov 24, 2007 5:15 PM, Wesley W. Terpstra
<terpstra at dvs1.informatik.tu-darmstadt.de> wrote:
> It seems MLton represented the type '(int * int ref) option array' as
> I would have done it in C. [...]
>
> What surprised me is that it seems MLton can turn the NONE case of
> option + pointer into a "null pointer". [...]

That is what I would expect.  IOW, I believe that it is a very basic
optimization.  Not all bit patterns correspond to valid pointers, so a
compiler is free to use invalid patterns to represent other values.
In particular, when pointers are guaranteed to be aligned by some
power of two (2^2 or 2^3 in MLton), there are some bits in pointer
values that can be used to store tag values (and the rest of the bits
can be used to store other information).

> What rules must I obey to make sure MLton can continue to apply these
> optimizations? For the flattened tuple, I gather I shouldn't try
> ripping the 'int ref' out of the tuple and passing it through a
> function barrier. But  when does this 'option ref' -> 'null pointer'
> optimization happen? Always?

Note that your type was actually "(int * int ref) option array".

Some time ago, while grepping through MLton's commit logs for
information on some thing, I noticed the following log message, that
relates to your question:

  http://mlton.org/cgi-bin/viewsvn.cgi?rev=3005&view=rev

It would seem to me that MLton has an expressive framework for
representation optimizations. So, I think that it would probably be
more productive to approach the problem from the other direction.  If
you run into cases where MLton is unable to optimize the
representation as you'd expect, you should report it and maybe MLton
can be improved to handle the case better.  I think that learning to
write code in such a way that some compiler will be able to generate
good code from it is ultimately not very productive (google for the
story about Levine the Genius Tailor).

-Vesa Karvonen