> > > I have another idea/iteration to run by you then. One of your chief > > quibbles, although I don't think it's your underlying one, is Cython must > > understand what's going on. So how about we support a block of C/C++ > code > > as a proper construct. Same name but now, I guess braces maybe get > involved > > (since semicolons do too). Then to transform (mangle) the nested > > identifiers in accordance with scoping/shadowing rules we pull in the > python > > bindings to llvm/Clang to parse that complicated code, work with the AST > (or > > further down the rabbit-hole) appropriately and spit it back out. > Obviously > > you could detect and analyze embedded statements to your hearts content > to > > decide to do something smart about that (you mentioned exception handling > > and return statement as concerning items). > > > > The potential hazards here are that LLVM/Clang is brought in (LLVM is > > already on ~ everybody's linux boxes as a graphics shader dependency) and > > it's [python] api changes somewhat often. I've used it before with > success > > for python driven C++ POD boiler plate (IO, size checks, visitors methods > > etc) autocoding. > > > > If you can understand the underlying C/C++ and get over that Cython will > > always run on a C/C++ compiler in our universe, and make that a feature > to > > embrace, not a detail to hide (who actually benefits in the later case?) > - > > are you still against the significant convenience - and potentially only > way > > to make things work when Cython is not supporting a C++ way of doing > things > > (say things aren't finished/working yet)? > > That would help solve the analysis, though enormous cost in complexity > (one now has two ASTs one must understand and reconcile, and a huge > amount of C++ knowledge must be baked in to understand the AST (or > even lower levels) and it'd be neigh impossible to do "partial > analysis" for features we don't yet understand, probably harder than > putting them into Cython itself modulo parsing) and making LLVM/Clang > a dependency for Cython is probably a non-starter as well. >
Well, one thing occurred to me is that leaning on Clang may be the only way you'll be able to remove/improve the DRY violating Cython side declaration of C/C++ land stuff. -Jason
_______________________________________________ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
