On Fri, Feb 20, 2015 at 5:59 AM, Keean Schupke <[email protected]> wrote:
>
>> You can put the module interface in a separate source file. You still
>> want to compile it to metadata, unlike C/C++, so that you don't
>> recompile it for each importing module. Also note that compiled code
>> and metadata for a module don't need to be in the same file either.
>
>
> I don't mind the compiler caching stuff, but its when you want to distribute
> a binary library I would rather have a human readable header file with the
> module interface and some comments, separate from the implementation(s).
Heheh. You can also decompile the metadata back into a header. And
that's not just in principle. The javap tool does essentially that,
for JVM modules (.class files). On .net this is supported right in
Visual Studio, which is really handy.
>> But arities inferred from definitions should be exported. Anyway we
>> shouldn't get into too much detail about linking in BitC. I don't
>> _know_ the details, and anyway it seems like another topic.
>
>
> The way I see it, the arities need to be explicit in the module interface
> definition. Hence requiring the concrete expression of arity in the type
> signature like:
>
> data module A = {
> f :: fn 'a 'a -> 'a -- arity is explicit in export
> }
That is not technically necessary. If you're arguing that the arities
_should_ be written somewhere for human reasons, you'll have to talk
to Shap.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
