Re: [Cython] RFC: an inline_ function that dumps c/c++ code to the code emitter
Watching this thread for a long time now, and I must say I absolutely love how someone just barges in «oh just add parsing of C++ AST». C++ is a language with an extremely complex context-dependent grammar, much more so than C. Not to mention they took to updating the standard with new awesome features every 3 or 4 years, which all seem to absolutely need their own syntactic support. > 23 авг. 2016 г., в 8:03, Robert Bradshaw написал(а): > > On Mon, Aug 22, 2016 at 9:44 PM, Robert Bradshaw wrote: > >> And it would be a step back >> for the nice auto-conversion facilities you care about, e.g. >> >>py_func(c_func(py_value)) >> >> would become >> >>c_value = py_value >>cdef some_type c_ret >>inline_cpp "c_ret = c_func(c_value)" >>py_func(c_ret) >> >> It's just choosing a smaller unit (line vs. file) to swap between languages. > > And on this note it would also encourage use of the Python/C API (over > swapping "back" to Python) which is often a dangerous step backwards. > ___ > cython-devel mailing list > cython-devel@python.org > https://mail.python.org/mailman/listinfo/cython-devel ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] RFC: an inline_ function that dumps c/c++ code to the code emitter
> > > 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
Re: [Cython] RFC: an inline_ function that dumps c/c++ code to the code emitter
Just trying and improve the state of the art. Yea maybe we have to add some tricks to separate the two grammar wise, so they can play together. Besides, I didn't start with that complexity, it evolved into seeing if that was a viable path forward. On Tue, Aug 23, 2016 at 5:15 AM, Alex S. wrote: > Watching this thread for a long time now, and I must say I absolutely love > how someone just barges in «oh just add parsing of C++ AST». > C++ is a language with an extremely complex context-dependent grammar, > much more so than C. Not to mention they took to updating the standard with > new awesome features every 3 or 4 years, which all seem to absolutely need > their own syntactic support. > > 23 авг. 2016 г., в 8:03, Robert Bradshaw > написал(а): > > > > On Mon, Aug 22, 2016 at 9:44 PM, Robert Bradshaw > wrote: > > > >> And it would be a step back > >> for the nice auto-conversion facilities you care about, e.g. > >> > >>py_func(c_func(py_value)) > >> > >> would become > >> > >>c_value = py_value > >>cdef some_type c_ret > >>inline_cpp "c_ret = c_func(c_value)" > >>py_func(c_ret) > >> > >> It's just choosing a smaller unit (line vs. file) to swap between > languages. > > > > And on this note it would also encourage use of the Python/C API (over > > swapping "back" to Python) which is often a dangerous step backwards. > > ___ > > cython-devel mailing list > > cython-devel@python.org > > https://mail.python.org/mailman/listinfo/cython-devel > > ___ > cython-devel mailing list > cython-devel@python.org > https://mail.python.org/mailman/listinfo/cython-devel > ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
