[MLton] symbol visibility

[Wesley W. Terpstra]

On Mon, Sep 1, 2008 at 5:10 AM, Matthew Fluet <fluet at tti-c.org> wrote:

> Commit r6680 adds and commit r6785 modifies the CFunction.SymbolScope.t
> datatype.  When emitting a c-prototype, the symbol scope is translated thus:
>      val symbolScope =
>         case symbolScope of
>            SymbolScope.External => "IMPORTED "
>          | SymbolScope.Private => "INTERNAL "
>          | SymbolScope.Public => "EXPORTED "
> which is then expanded by cpp via the "export.h" header.
>
> Is there a good reason to have a different names (i.e., External for
> SymbolScope.t, but "IMPORTED" for the macro)?


The IMPORTED/EXPORTED/INTERNAL macros I stole from someone else who used
those names. They nicely describe what is done operationally, IMO. When
thinking about how I wanted my ML code to look, I wanted a higher-level
point-of-view: what the compiler needs to know is where a symbol is coming
from. The SymbolScope datatype matches the ML-source-level names.

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?

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton/attachments/20080905/a45397a7/attachment.htm