skaller wrote: > In summary .. its a mess. I want clean decoupling, > explicit interfaces, etc, even for #macro stuff. > > Maybe #macro packages should be entirely distinct > kinds of files.
Here's all the possible fixes I can think of: 1. go to c-style guards and just export everything This is a nasty situation, especially since I'd like to minimize and localize macros. One way we could do that is actually support a #local section that wouldn't expose any macros. So: file1.flx ////////////////////////////// #ifndef __FILE1__ #define __FILE1__ #local macro val x = 1; #endlocal #endif ////////////////////////////// file2.flx ////////////////////////////// #include "file1.flx" print x; <- error, not defined ////////////////////////////// 2. export only which files the source depends on Not sure if this would actually work. The basic idea is to have the "file1.flx" to export only what's defined in the file, and nothing from the files it imports/includes. To support cascading, file1.flx will output which files it depends on, and then "file2.flx" will insert those imports/includes into itself after eliminating repeats. 3. go the ocaml / camlp4 route with a AST preprocessor Not sure how to deal with macros, but this would fix syntax extensions, albeit in a little bit of a heavyweight fashion. This might not be so bad though, as it will make it obvious if any syntax changes are present. 4. explicitly export the interface this solves the difference between import and include. Mark everything that's part of the file's public interface (or conversely, all the private stuff), and only expose that stuff. I can't think of a really good reason why in some cases you would want to "#import 'file1.flx'" and in others "#include 'file1.flx'". 5. explicitly import what we want Just the inverse of the previous example. Say we swaped requires for import/include, we could specify adjectives to the requiring. So, we could have "requires 'file1.flx'", "requires public 'file1.flx'", "requires macro 'file1.flx'", and "requires syntax 'file1.flx'" and etc. 6. make standard library implicitly imported A lot of the complication seems to be coming from the necessity to #import flx.flxh, because we want all of that (for the most part) to be exposed to the importer. On the flip side, we may not want macros to exported by default. So, we could switch to importing flx.flxh by default, and allowing the standard syntax extensions to be inlined by default, as opposed to the user ones which require something special to turn on. 7. split up everything We copy ocaml. We have the camlp4 syntax enhancement file, interface and implementation files and only allow macros in implementation and syntax enhancement files. Importing is done through explicit or implicit interface files which don't have macros of syntax changes, so we never run into this issue. One change from ocaml though is we do away with the implicit "requires", like skaller mentioned on the ocaml list. This makes dependencies obvious. Also, we have some fashion to distinguish between system libraries, and local ones, allowing for a cleaner file namespace. Are there any other options that don't require dropping features? -e ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Felix-language mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/felix-language
