OS.FileSys on Win32...

[Stephen Weeks]

> OK - I will see if I can do this... Where is the build-basis file
> mentioned in the Makefiles? I can't seem to find it right now...

The "build-basis", "bind-basis", and "misc/suffix.sml" filenames are hardwired
into the MLton sources.  In the version you have, these are in src/prim-env.fun.

I think the easiest thing to do would be to leave those hardwired, and to have
two different files "build-basis.linux" and "build-basis.win32", and copy the
appropriate one into build-basis before calling "./mlton .. world" to preprocess
the basis.  You might want a different bind-basis as well.

> And by the way - how much is the basis-library processed?

The basis library preprocessing (producing world.mlton) involves just lexing and
parsing.

> For instance - does it do inlining?

The basis is concatenated onto the input program and is treated (almost) the
same, so inlining is done on both, but only once the input program is received.

> I'm thinking if it would be possible to preprocess my
> realtime RenderMan renderer like that with heavy inlining,
> and then include it in an app. without much inlining in the
> app-code - so that I will get good performance where it
> matters without making the program too big or getting
> too big binaries / long compilation times...

Not so easy to do, since inlining happens long after the distinction between
basis and user program has been erased.  BTW, the inliner has improved
significantly since 1999-7-12, and avoids some of the (possibly exponential)
blowup that the old one had.

> Oh, and another thing - do you think it would be
> worthwhile if I wrote a new garbage collector for MLton?
> I'm thinking of a 2-generation garbage collector where
> one can force garbage-collection on the heap with young
> data and where the heap with old data is incrementally
> garbage collected. It is for avoiding the pauses in
> a realtime game and stuff like that...

This would be extremely useful.  We're spending about 40% of compile time in GC
in some cases.  I think a 2-generation collector would help the compiler a lot
as well.  If you seriously want to consider this, we should have some
discussion on this list, since I know Henry has thought about it some, and
Matthew and I were just discussing GC's the other day.  Also, you should
definitely do it in the context of the upcoming release.