OS.FileSys on Win32...

Anoq of the Sun anoq@HardcoreProcessing.com
Tue, 19 Jun 2001 15:35:31 +0200



Stephen Weeks wrote:
> Here are the options that I see.
> 
> 1. Have OS specific stuff in C code, transparent to the basis library
>    implementation.  You did this for solution 1.
> 
> 2. Have OS specific stuff in SML code, and use compile time SML constants and
>    "if" statements to do the right thing.
> 
> 3. Have OS specific stuff in SML code, and use different files for different
>    OS'es.
> 
> Solution 3 is what SML/NJ does and I think it is the right one.  They have
> different implementations of OS.FileSys for different OS'es.  They use functors
> to express stuff that can be shared.

3) is also what I use in my apps, and I also think it
sounds like the most attractive solution.

> Here are two different ways to implement this with MLton:
> 
> 1. Have a different preprocessed version of the basis library for each target OS.
>    Specify via a compiler switch which to use.
> 
> 2. Have a different world.mlton for each target OS.
>    Each world is specified by a different src/basis-library/build-basis file.
>    Specify to the script that starts MLton which world to use.
> 
> Option 2 seems easier to manage to me, and could even be implemented without
> changing the compiler proper, by simply switching build-basis and making the
> world twice.

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

And by the way - how much is the basis-library processed?
For instance - does it do inlining?
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...

But this just brings me back to the library support
(.so or .dll... :)

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


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