On Fri, Feb 20, 2015 at 5:24 AM, Keean Schupke <[email protected]> wrote: > >> Oh I see. You're right, I'm pretty sure BitC will be more like your >> second code chunk. Modules will compile to code and metadata, where >> the metadata is used to compile importing modules. This is like CLI, >> and many other separate-compiled languages other than C/C++. > > > I might be in the minority, but I personally don't like comping to metadata, > I prefer the C/C++ approach where you have a static header file. I would put > he module type definitions in a separate file, and the module type > definition should contain all the types you need to use any exported > function from the module.
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. > You only really need the metadata files if you > allow type-inferred functions to be exported like Haskell, but I think BitC > is not going to do that (and it seems a bad idea to me), 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. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
