[MLton] MLton import headers

[Wesley W. Terpstra]

On Sun, Oct 5, 2008 at 12:02 AM, Matthew Fluet <fluet at tti-c.org> wrote:

> That seems like a reasonable rationale.  If I understand things correctly,
> though, one advantage of the
>  #include "xyz.h"
>  #include "xyz-private.h"
> approach is that is textually separates the public (in the sense of the
> documented portions of the library API available for use in other projects)
> functions from the private (in the sense of the undocumented portions of the
> library API) functions.  That is, clients of "xyz.h" can't even see the
> prototypes of the private functions.

Correct. On the flip-side, having only one file is convenient.

While I agree that header files can serve a documentation purpose, I
don't think that's true for us. An automatically generated header is
full of extra-trash and lacks comments. The header doesn't declare the
symbols to C and output library doesn't expose them to the linker. If
you want to document your API, do a better job than an automatic
header file.

>> What I do think we need is a new annotation, 'defaultImport
>> public/external'. This way your 'prim.sml' that does all the
>> _import/_address/_symbol'ing can be easily switched between
>> static/dynamic import.
>
> This shifts the point of change from the 'prim.sml' file to the 'xyz.mlb'
> file.

That's exactly what I wanted: one place to change. Some of my projects
have prim.sml files that run over 1000 lines. These aren't
auto-generated, so there's no possiible autogenerated ML import header
to have in this case. An annotation could solve this neatly, without
trying to 'sed' the file, which I think is a pretty crude and fragile
approach.