Optimizer too smart....

[Stephen Weeks]

> val getId         : 'a -> word
> val insertTbl     : (word * word) -> unit
> fun polyInsertTbl (x:'a,y:'a) = insertTbl(getId x,getId y)
> 
> Before polyInsertTbl was atomic and I didn't worry about mlton doing the
> "wrong" thing... but with the getId approach if mlton goofs it might rewrite
> polyInsterTbl in a wrong way like..
> 
> fun polyInsertTbl (x:'a,y:'a) = insertTbl(0w0,getId y)

This particular problem shouldn't happen unless there is a bug in
MLton, since MLton can't do anything with Cprims ...

> and I'd get a nasty segfault.... keeping the primitve "primitve" just gives
> me a stronger guarantee of safety... if I know the mlton code type checks, I
> just know certain things aren't going to go wrong..... but I'm already
> loosing some safety guarantees in other ways so it's not a real problem.

... however, I agree completely with the principal of having
primitives such that type safety implied run time safety.  Thus, I
think it would be best if you could stick with your original approach, 
or put a runtime test in insertTbl (at least for debugging).