OS.FileSys on Win32...

[Anoq of the Sun]

Stephen Weeks wrote:
> 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.

OK - if bind basis is about what is exported, then I definately
don't want another, since I want as few incompatibilities as
possible :)

> 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.

OK...

> 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.

Sounds really good! :)
Then it's just a question about whether I can write a pixel
to the framebuffer fast enough with it :)
I saw on the latest SML/NJ announcement that they
now have some funky "no-longer-foreign interface" stuff
(not quite sure what it is, but it sounds nice...) and
they also have some memory operation primitives.
If something like that would be possible to do with
MLton, then I guess it would be possible to do
realtime 3D with it :)

> 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.

I'm not sure if / when I have the time - but I would love
to talk it over with you. There's a possibility that I'm
going to write a small commercial realtime 3D game soon -
and it would be nice to use MLton for this...

> Also, you should definitely do it in the context of the
> upcoming release.

The approach I have in mind is to write it in ML first - with
some nice function-abstractions for the dirty memory/pointer-work.
Then it should be quite easy to get to work in ML and then
transscribe it almost directly to C afterwards with some similar
macros for the pointer-work. Then I guess it could be done
for both the old and the new MLton... and if this
realtime game project becomes a reality, it might be with
a short deadline and I would definately want to be able to
fall back on the MLton version that I trust...

I guess I should also buy the big garbage collection book...


Cheers
-- 
http://www.HardcoreProcessing.com