[MLton] symbol visibility

[Matthew Fluet]

On Fri, 5 Sep 2008, Wesley W. Terpstra wrote:
> That said, it would be better to use macros of the same name as in the ML
> source. I prefer the "private/public/external" labelling as it's more
> declarative in nature. Also '_import "foo" imported' or '_export "foo"
> exported' seems silly.
>
> Which do you prefer?

I do think the 'private/public/external' seem a little nicer.

> Regarding the MLLIB_{PRIVATE/PUBLIC/whatever} macros, somehow what I'd
> really like to do is define them based on if the header is used by C-code
> within the library or C-code outside the library, eg:
>
> #ifdef PART_OF_LIBRARY_<NAME-OF-LIBRARY>
> #define MLLIB_PRIVATE(x) PRIVATE x
> #define MLLIB_PUBLIC(x) PUBLIC x
> #else
> #define MLLIB_PRIVATE(x)
> #define MLLIB_PUBLIC(x) EXTERNAL x
> #endif
>
> MLLIB_PRIVATE(int foo();)
> MLLIB_PUBLIC(int bar();)
>
> #undef MLLIB_PRIVATE
> #undef MLLIB_PUBLIC
>
> This would then need inclusion (or inline-copy) of exports.h.
>
> A user using FFI as pary of his library would then do this:
> #define PART_OF_LIBRARY_FOO
> #include "foo.h"
>
> Meanwhile, anyone using libfoo would just do:
> #include "foo.h"
>
> Thoughts?

Seems reasonable.  The '#define PART_OF_LIBRARY_FOO' idiom would only be 
needed if the library required a C proxy that itself required access to 
the _export-ed functions of the SML library ---  a sufficiently complex 
and rare situtation that the extra syntax seems fine.