I'll try to free up some time, and come back. However, it is clear that I won't have time for this in the next 3 weeks.
@v3ss0n Should I create issues on github? (Sorry, I didn't get the checkbox reference.) Some of these are already there, and some of these are not issues, but feature requests. It would take some time to track all of these. I can promise that I won't forget this list and keep bringing it up :) Speaking about the topics, here is what I would do first. **Q7** (adding "const" to refs) seems hard, so I would just take some files in the compiler and rename the variables of functions, e.g., `n: PNode` to `n_const: PNode` if I'm sure that `n` will not be modified in the function. This would make my life much easier. Then fixing **Q12** (fixing concept) looks like a good task for me, and I really hope that others would start writing good concepst (all kind of containers with the same API, general database API where the server can be "list your favorite databases here", etc.). Also fixing the destructor **Q8** can have a big impact, because it can introduce smart pointers, which could help in sharing data between threads, or have a special list type, which looks mutable but a copying it wouldn't copy the elements unless it is necessary (R does that with data.tables). My other dream is to write an AST->code converter. It looks like a task which is easy to test: we have lot of nim code, all I have to do is check "AST_generated_from(test.nim) == AST_generated_from(myCodeGenerator(AST_generated_from(test.nim))" is true or false. I understand that it is not possible in 100%, but I would like to try this, because it would make macro expansion live :) The iterator/closure reference/promise not to change a pointer/immutable string look like the same to me. We need some extra smart logic in the compiler to track the variables (their life and place in memory). Definitely not an easy task. > Peter
