<div class="gmail_quote">On Wed, Jul 8, 2009 at 1:30 PM, Wesley W. Terpstra <span dir="ltr"><<a href="mailto:wesley@terpstra.ca">wesley@terpstra.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="gmail_quote"><div>I am considering whether it might make sense for IntInf to be a datatype:<br> datatype t = FixedInt of FixedInt.t | PrimIntInf of PrimIntInf.t<br>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?<br>
<br>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.</div>
</div></blockquote><div><br>I had an even better approach:<br> type int = FixedInt.int option * int<br>Whenever a calculation is performed, the FixedInt is ignored and set NONE in the result. <br><br>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.<br>
<br>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?<br><br></div></div>