Ok, so I have partially decoupled the felix compiler front end functions so they don't use the global "state" object: they still use the fields of that object and update them, but they're passed individually so I can see what fields are updated by what routines.
There is a problem here though: Erick has made the "state" objects for everything abstract. The problem is that, for example, the bind state includes the lookup state but BOTH of them separately need some common fields such as "varmap", and the bind routines can't get that out of the lookup state because it is abstract, Just to refresh my memory: the basic idea here is, given a whole library of symbol table, to bind another symbol table (usually a part of that library) which comes from one file. You can't bind a file out of context, because functions in one file can use functions in another. So if you have files A B C D you roughly have: bind: context=A+B+C+D tobind=C output=Bound_C The idea is to save A,B,C,D and Bound_A, Bound_B, Bound_C, Bound_D on disk and load and merge several of these to form first a whole library, and then a context to bind the user program, with the library code *already bound* so we don't have to repeatedly bind the library. The requirement for binding is that the context is complete (closed). Binding at the moment *updates* several tables, the bound symbol table, a list of axioms and reductions, it binds interfaces and directives and initialisation code. It also updates ticache (type instantce cache), varmap (return types of functions) and some other stuff. This means incremental binding is probably fairly easy, but *modular* binding is not so easy. It requires some way to combine the components, as well as modifying the routines to separate new stuff being added from stuff already there. This would be hard to do in functional style since you'd need to separate the existing context from new stuff being added, but consult BOTH when searching for stuff. The other way to do it is to not do it :) Instead, just view the caching as checkpointing the whole data space every now and then in a serial process. This should be relatively easy but it is not comfortable: it's like pre-compiled headers in C/C++: they save time but they're a total hack. Of course, hashtable are fast and mutable.. Some other observations: at present, library files don't specify their dependencies: the standard library just has a __init__.flx that includes everything, and the child files just assume they can refer to anything else in the library. This make it a bit tricky to find the dependencies.. but it is also what makes it easy to write the library, and in turn makes Felix so easy to use. In part this structure is because Felix doesn't HAVE separate components. Yes, we have modules. But a library file contains a module: it isn't in itself a module, it's just a serial stream of lines. The library looks like a nice package a-la Python or Ocaml but it isn't. probably the right way to do this is with "requires" and flx_pkgconfig. -- john skaller skal...@users.sourceforge.net ------------------------------------------------------------------------------ Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
