[MLton] MLB file tree

[Matthew Fluet]

> A better annotation would be something like
>
>  multipleElaboration {warn|error|ignore}
>
> and it would be used like:
>
>  ann
>     "multipleElaboration ignore"
>  in
>     infixes.sml
>  end

Interestingly, I am aggressively using elaboration of the same source file 
multiple times to refactor the Basis Library implementation to be agnostic 
to the sizes of C types.  Essentially, I have

<--- config/c/x86-linux/c-types.sml --->
structure C_Int = Int32
structure C_Long = Int32
structure C_LongLong = Int64
...
<--- config/c/x86-linux/c-types.sml --->

<--- config/c/amd64-linux/c-types.sml --->
structure C_Int = Int32
structure C_Long = Int64
structure C_LongLong = Int64
...
<--- config/c/x86-linux/c-types.sml --->

And I reference them via config/c/$(TARGET_ARCH)-$(TARGET_OS)/c-types.sml. 
I elaborate them multiple times, once with little more than the primitive 
integer types and primops in Int{32,64} and then once again when 
Int{32,64} have been redefined with more operations.  The first binding 
gives me the types C_Long.int for use in the definitions of primitives and 
_import-ed functions.

In any case, this isn't an argument against the annotation.

> If this sounds like a useful feature (diagnostic on multiple 
> elaboration) to have, I could look into implementing it during the 
> weekend.  (I also have another draft patch (the printing of types with 
> fewer parentheses) waiting, that I haven't had time to complete in the 
> past few months.)

Feel free.  As you've pointed out elsewhere, most annotations do not 
change the meaning of the program, but simply what warnings/errors are 
reported.  So, I think it is alright to experiment a bit with 
different annotation choices.