Good news so far... :)

[Stephen Weeks]

> I don't know where this came from, but I had a version 3.12 in my
> previous
> EGCS compiler. I replaced it and everything compiles perfectly now...

Great.  Just to be clear, you are compiling on a Windows machine, right?

> Earlier I also succeeded in compiling the MLKit with SDL
> and compiling Win32 apps with MLKit by Linux->Win32 crosscompilation
> and using SDL for a game project that I'm doing... but alas,
> yesterday I gave up on MLKit, since it gives memory leaks
> (unless things are programmed in a _very_ special way -
> too special to be usable in practice in my opinion...)...

Interesting to hear this.  I had suspected the same thing having
looked at their stuff, but had never really tried very much.

> So, um, I looked at the MLTon code, and it doesn't look much harder
> to port than MLKit :)

Cool.  Definitely keep us up to date on this and feel free to ask any
question, no matter how simple it seems.  It's always easier for the
guy that wrote the code!

Does it look like the main work is in porting the gc, the library,
or ...?

> So now I just have a small problem compiling cmcat (so that I can
> check if the garbage collection in MLTon will be a problem for a
> realtime game...)
> 
> I get this:
> cmcat.sml:110.49-110.58 Error: unbound structure: CM in path CM.names'
> cmcat.sml:153.27-157.38 Error: operator and operand don't agree [tycon
> mismatch]
>   operator domain: string * string
>   operand:         {path:'Z, relativeTo:string}
>   in expression:
>     mkAbsolute {path=file,relativeTo=getDir ()}
> 
> !* CM error: compile: elaboration failed
> 
> Do you know how to fix these 2 errors? I'm sure it must be simple :)
> 
> This is when compiling with SML/NJ 110.0.3 - But I've got an
> SML/NJ 110.9.1 around if that's better...

The first problem is due to running sml instead of sml-cm.  At some
point, the NJ people changed their setup so that just plain sml has
the CM structure available.  I guess it was after 110.0.3.  The second
problem is also due to a change in SML/NJ somewhere along the way.  At
some point, they changed the type of OS.Path.mkAbsolute to accept a
record type instead of a pair of strings.  Again, I guess it was
sometime after 110.0.3 that they made this change.

Thus, I think that both of your problems will be fixed by switching to 
110.9.1 (that's the version I use).

As to the garbage collector, since MLton uses a straightforward
stop-and-copy algorithm, I can imagine it causing problems if you have
much data alive.  In measurements we made, the gc copies live data
about the rate of 10M/sec on a 400MhZ machine.  So far, this hasn't
been a problem for any of the code I've written, but I haven't written
any real time games.  One workaround (short of writing a better GC),
would be to do a bit of manual memory allocation for long-lived large
arrays by using C malloc and free and keeping the pointer hidden from
MLton's gc.  Sure, it's gross and not safe, but it might be simple
enough to be feasible.