[MLton] Re: PackWord to/from nonsense

[Wesley W. Terpstra]

On Wed, Jul 8, 2009 at 1:30 PM, Wesley W. Terpstra <wesley at terpstra.ca>wrote:

> I am considering whether it might make sense for IntInf to be a datatype:
>   datatype t = FixedInt of FixedInt.t | PrimIntInf of PrimIntInf.t
> Converting toLarge just wraps a FixedInt conversion. Any LargeInt
> arithmetic completes the conversion to PrimIntInf. By deferring the packing
> of the final tagged int32 / GMP type, the optimizer would be able to see a
> conversion to/from FixedInt, allowing the usual 'free' casting. I'm not sure
> how good MLton would be at recognizing that operations on IntInf are always
> of the PrimIntInf type. I think the only place it might not be able to
> optimize this away is on recursive calls?
>
> I'm going to try hacking this as an experiment and see if it negatively
> impacts the benchmark directory. If it doesn't work out, then the
> fixed-int.patch would at least tide MLton-specific applications over.
>

I had an even better approach:
  type int = FixedInt.int option * int
Whenever a calculation is performed, the FixedInt is ignored and set NONE in
the result.

I'm quite confident that MLton would have been able to optimize the unused
parts away in nearly all cases. If you take an IntInf.int and operate on it,
you ignore the FixedInt part so it is dropped as an argument. Similarly, if
you are just using IntInf for a conversion, the int part is not needed and
dropped.

Unfortunately, this doesn't quite work because IntInf.int has to be an
eqtype. Is there any way to instruct MLton to ignore the FixedInt part of
the tuple when comparing these types?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton/attachments/20090708/a515ad8e/attachment.htm