<div dir="ltr">On Mon, Sep 1, 2008 at 5:10 AM, Matthew Fluet <span dir="ltr"><<a href="mailto:fluet@tti-c.org">fluet@tti-c.org</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Commit r6680 adds and commit r6785 modifies the CFunction.SymbolScope.t datatype. When emitting a c-prototype, the symbol scope is translated thus:<br>
val symbolScope =<br>
case symbolScope of<br>
SymbolScope.External => "IMPORTED "<br>
| SymbolScope.Private => "INTERNAL "<br>
| SymbolScope.Public => "EXPORTED "<br>
which is then expanded by cpp via the "export.h" header.<br>
<br>
Is there a good reason to have a different names (i.e., External for SymbolScope.t, but "IMPORTED" for the macro)?</blockquote><div><br>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.<br>
<br>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.<br>
<br>Which do you prefer?<br><br>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:<br>
<br>#ifdef PART_OF_LIBRARY_<NAME-OF-LIBRARY><br>#define MLLIB_PRIVATE(x) PRIVATE x<br>#define MLLIB_PUBLIC(x) PUBLIC x<br>#else<br>#define MLLIB_PRIVATE(x)<br>#define MLLIB_PUBLIC(x) EXTERNAL x<br>#endif<br><br>MLLIB_PRIVATE(int foo();)<br>
MLLIB_PUBLIC(int bar();)<br><br>#undef MLLIB_PRIVATE<br>#undef MLLIB_PUBLIC<br><br>This would then need inclusion (or inline-copy) of exports.h.<br><br>A user using FFI as pary of his library would then do this:<br>#define PART_OF_LIBRARY_FOO<br>
#include "foo.h"<br><br>Meanwhile, anyone using libfoo would just do:<br>#include "foo.h"<br><br>Thoughts?</div></div></div>