I am considering now some changes to the compilation model.. [Erick .. you with me?]
First, I would like to somehow hack the parsing to use a stack of lexbufs so the grammar can be split up into files.The "right way" to do this is to patch Dypgen. The second change is more fundamental: instead of (or as well as) saving "*.par" files containing the parse tree for each file, I proposed to save the symbol table. This means desugaring and macro processing will only have to be done for changed files. The output will be the usual Ocaml Marshall dump. To make this work, I have to change the representation of integers from Big_int things to just strings (since Ocaml can't dump abstract types). This happens in the parser so the constant folding routines in the macro processor will have to translate these strings to big_ints, do calcs, and convert back to strings. The actual output will be the values in the symbol table hashtable, that is, the indexes will NOT be dumped. This means that the "linker" for the tables can just concatenate them and generate indices as it goes. There's one problem with this: some early processing does lambda lifting, and the *index* of the table entry for the lambda is used to locate the function, rather than a name: this bypasses name lookup and means the sythesised names are just useful for display purposes. Bypassing name lookup guarantees that the right symbol is found: we can't have an error here because the poor old client would be very confused with a lookup error referring to something that isn't named in the program :) With a "possibly" small layout change, the index can be put in the lambda's record so we know what it is. Then when linking we may have to track the magic numbers used up, possibly "relocating" the code by mapping them to distinct unused values. That's a pain. Another option is to just make sure they're unique .. say by using the current date and time (in nanoseconds?) as the index. Ok, so the *problem* with this idea is that macros will not be "inherited". Desugaring and macro processing will have to be either file local, or using a common macro file which is "imported" in front of every file. I must say I'm not terribly fussed by the loss of macros :) But we do use the occasional POSIX or such like macro for conditional compilation: most of these uses do not need macros, plain vals would do, but the resolution might have to be deferred until after the symbol tables were built.. and would have to be done before binding. However this really only applies to macros that choose between non-top level statements: choosing between type correct functions, for example, could also be done by the resource manager. -- john skaller skal...@users.sourceforge.net ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
