On Wed, Nov 10, 2010 at 12:26 AM, john skaller <skal...@users.sourceforge.net> wrote: > I am considering now some changes to the compilation model.. [Erick .. you > with me?]
I'm with you :) > 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. Great! > 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. Or just hash the data structure? If they're pure they'll always be consistent. That's one of the neat things that comes out of hash consing the symbol table, along with cheap comparisons. > 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. I wouldn't be that sad if we lost macros. I think a lot of the use cases can be replaced with type classes and flx_pkgconfig requirements. ------------------------------------------------------------------------------ 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
