[MLton] Windows ports and paths

[Matthew Fluet]

> On Tue, May 03, 2005 at 01:38:06PM -0400, Matthew Fluet wrote:
> > With MLBs, we've given users the option of having a .mlton directory,
> 
> This sounds interesting, where is this documented?
> Or do you just mean .mlton/mlb-path-map?

I just meant that we support  ./mlton/mlb-path-map; that is the logical 
place to put user specific auxilary files.

> A much simpler thing to do is have the mlton-script source a config file
> from the user's home directory that includes a few shell script variable
> definitions.
> 
> By the way... This might also make good sense for all of those -target-*
> opts. We discussed this before. I think -target-cc-opt sparc '...' is silly.

The -target-cc-opt stuff is for cross-compiling.


> If you're going to start adding OS stuff to MLBs, 

That wasn't my intention with my comment.

> please consider 
> my alternate feature requests (all of which are aimed at helping mlb 
> files hide their implementation):
> 
> 1. The ability to predicate off the compiler used
> 2. Some sort of versioning scheme like: mgtk.mlb version >= 93

I agree that some sort of predication/conditional is the next logical step
for MLBs.  What is unclear is the right set of primitives for forming 
conditionals.  You've mentioned two, but there are certainly others; it is 
also a question of how conditions are resolved -- do they execute SML 
code? do they execute system/shell code?

> 3. Support including the name of a library to link against as an MLton
>    extension to the MLB syntax. Suggest other implementations do similarly.
> 
>    - Coupled with #1 above, it becomes possible to conditionally include 
>      a MLton specific .mlb file which pulls in the required libs.
> 
>    - I see no reason a user of mgtk.mlb needs to know what GTK+ libraries
>      mgtk is using; mgtk should be able to specify this itself and hide it.

I agree that some mechanism along these likes is desirable, though that 
has been debated on this list.  Many of the same questions as above arise.  
For example, GTK+ seems to like to use pkg-config to resolve compile/link 
flags.  But, that would require executing a shell call during the 
evaluation of a MLB.  It does appear that one soon ends up importing much 
of shell functionality into MLBs, where it doesn't realy belong.