[MLton-devel] cvs commit: support for multiple integer, real, and word sizes

[Stephen Weeks]

> Should we then be able to drop the String_toWord8Vector and
> Word8Vector_toString primitives?

They need to stay around for the front end to do type checking.  But
you'll notice that with the checkin that those two primitives are now
implemented as the identity function immediately after type checking,
so the rest of the compiler doesn't need to worry about them.  I'm
pretty sure I removed all the old uses in the codegens.

> I'm also adding an
>   Int_toInt of IntSize.t * IntSize.t (* codegen *)
> primitive, since it doesn't seem appropriate to bounce through IntInf.int
> to convert sizes.

Sounds good.  Someday we should do the optimization mentioned in the
basis library spec:

	IntM.fromLarge o IntN.toLarge converts an integer from type
	IntN.int to IntM.int. Good SML compilers should recognize this
	idiom and do a direct conversion.

This would require a new SSA optimization pass that builds expression
trees instead of just looking at single primapps.  It would useful for
other cases too, like rewriting associative ops to move constants
together.

> So, policy question: should I check in something that will leave the
> checked-in code in a slightly inconsistent state (in the sense of
> known bugs)?

Generally no.  But if it's announced first and agreed upon, I don't
see why we can't make an exception.  Also, since (I assume) the known
bugs are just in new basis library modules, it's not a big deal to
checkin.  The idea behind the policy is that you don't want to
introduce a bug in code someone is currently working on, which doesn't
apply with new modules.

> I tracked down one source of problems: IntX.equals doesn't consult
> the size of the constant, which means that globalization can take
> two different size integer constants and collapse them into one.
> This yields a type error on some uses of the global.  Word constants
> don't suffer from this problem, because WordX.equals compares both
> the value and the size.  I note that RealX doesn't compare the size
> of the constants, only the string value.

Both the IntX and RealX behavior seem like bugs to me.  Sorry about
that.  I'll leave it to your checkin to fix them.

> I'll be out of my office until after noon.  There (should be) is a
> patch of my changes against the currently checked-in sources at
> http://www.cs.cornell.edu/People/fluet/mlton.tgz

Go ahead and checkin whenever you get back.



-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel