Declarative meta fields #20
Conversation
… order to allow development of compiled parsers.
|
Excuse my dumb questions (I'm a Python newbie) |
|
@washort could you elaborate on what this patch does? it's totally unclear what problem it comes to solve |
|
Right now, construct works as an interpreter. To parse or build some data, a method is called on the structure object which then invokes various methods/functions on its contents, etc. My idea is to support code generation from constructs -- creating Python (or perhaps even C) code that does the building/parsing. This can't work if the construct object has arbitrary functions inside it. So I wanted to replace those functions with objects that can either be used in the current mode (invoke a function to get a value) or in a code generator (where the code generator asks Equal or Boolean etc. to generate code providing their behaviours). |
|
yeah, i've had this idea for some time now (see http://sebulbasvn.googlecode.com/svn/trunk/ccon/test.py and the generated files in that directory). the problem is, it's not possible in the general case. so you can solve it for structs and stuff like that, but you can't do it for adapters, as they are just functions. so this will not work... you have to define a narrowed down version of construct that's not turing complete (most likely context-free), and then it could work. but that's a different project. |
|
After writing this patch, I started to believe that as well. :) |
No description provided.