|
I've been deep in the depths of hacking a new feature into an existing language - adding a reflective/referential data definition language on top of haXe. (It's called XReflect, if curious you can get it off haxelib) Essentially, the problem I keep running into with referential data structures is that haXe, like most popular languages, will only let you set them up in an imperative fashion, one dependency at a time, which tends to both spread out and bloat application code. What I want is to write my dependencies in any order and let the resolution be sorted for me. I'm pretty sure a language with AST access and quoting like Lisp makes it relatively easy to write something along these lines, but in haXe, I had to write about 500 dense lines of code, most of it going to parsing and fighting the limitations of the type system. It still has some major bugs that I'm trying to resolve with a refactor at the moment. The funny thing is, I know I'm not just fighting haXe here, I'm also running into the limitations of the platforms that haXe compiles to. The newest strategy I'm applying to resolve references is to add a "__parent" field to the reference stubs, which refers to the container(an array or record type) of that reference. I use that later, after all references are resolved, to drop the final value into the place of the stub, but as it turns out this causes difficulty printing out the working structure. Neko will recognize the value of __parent as "....", but Flash 9/10 will recurse into the field again and get a stack overflow. So I had to add more code to write a pretty-printer which is aware of such traps. |