[CC to Dypgen, skip if not interested!] I have refactored the Felix parser to take advantage of new Dypgen features.
The syntax and autoimport files are now parsed once. The resulting parsing device and local data is saved to disk. Thereafter, this data is loaded once per run of the Felix compiler. The scheme helper functions are compiler once per run as well. However the function free parsing device is held as a string, and is converted by Marshal to a parsing device once for every file parsed. Also, the scheme action codes are compiled each time as well. Neither of these per parse actions should be necessary, however it is done because I can't save the parsing device to a variable because I don't know its type. In addition the type is parametrised by global data type, and the (Marshal encoded) string is stored in the global data, which may cause a circularity if stored directly (not sure!). This may be changed by using Obj.magic (its just as safe as Marshal .. i.e. it isn't safe at all). Still the result is a bit faster than before! binding library std done in 17.033832 seconds The whole test suite now runs in a few minutes (used to be around an hour!). CAVEATS AND BUGS. 1. The current commit has debugging info in it. 2. The gmp test, which has a bit of user defined syntax in it, is failing for unknown reason. Ditto for the Monad test. 3. I'm not sure if include files are correctly handled: the code in "desugar" module that handles this is not modified. 4. There is no verification of up-to-date-ness. The file "automaton.syntax" in the current directory holds the data: if you build a new version of Felix compiler or change the grammar you have to blow this file away manually (will be fixed later). It may be useful if Dypgen emitted the type start_symbol_obj_t start_symbol_token_t and if possible start_symbol_parsing_device_t although that can be defined relatively easily once the obj and token types are known. The type 'obj is a variant with a collection of %Constructors, it must be known somehow to Dypgen, it cannot be known reliably by the client (because the constructors are given in bits to Dypgen, it is Dypgen's job to unify them into a type, not the clients). Similar for token, if the %token is used to define the token, it isn't reasonable to expect the client to repeat all that stuff to define the token type (and Dypgen might add something .. :) -- john skaller skal...@users.sourceforge.net ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
