[MLton] Debian: sparc works

[Wesley W. Terpstra]

On Wed, Dec 22, 2004 at 02:21:49PM -0800, Stephen Weeks wrote:
> I've eliminated all but the C99 implementation, as well as cleaned it
> up to remove the conversion between C99 names for classes and MLton
> names for classes.

Yeah, I read this...
What you did is fine for fpclassify since FP_NAN, ZERO, etc are all defined.
However, you killed all my #ifdefs around fegetround and fesetround...

Not every system supports all the rounding modes.
When FE_DOWNWARD, FE_TONEAREST, FE_TOWARDZERO, or FE_UPWARD is defined that
means the platform supports that mode. If it is not defined, then this mode
does not exist... Your use of _constant will lead to constants.c failing to
compile on less able platforms.

> We actually have a lot of work to do here, since there are a number of
> hardwired type definitions in the basis library sources (in particular in
> misc/primitive.sml and posix/primitive.sml).

Yes, that's why I haven't done it yet...
gc.c also terrifies me. ;)

> The one idea I've had along these lines is to automatically generate
> for each target an SML prelude for the basis library implementation
> that defines all the types.

How nasty would it be to make every C type needed by the runtime a primitive
type in MLton? I don't mean user visible, just in the primitive.sml stuff...

If C's pid_t, uid_t, int, long, short, char, etc were all available to the
basis library, that would be ideal. As long as the C FFI supported it, we
could copy the C prototype straight into SML. The type conversions would be
much safer to do outside of C where casts are forbidden. ;) The SML types
int, real, char would be decoupled completely from C types of similar name.

How to pick SML's int and real is something I am less sure about.
SML int != C int; linux+C made int=32bit even on 64bit machines because of
legacy code. SML doesn't have this problem so we should get it right: 64bit.

Another problem with my suggestion is conversions. It is conceivable that
some types may be larger than whatever we pick for SML's int. Hopefully we
never need to do a conversion, but you never know with C APIs. =)

-- 
Wesley W. Terpstra