> Yes, Python exposes the “ast” module for direct introspection of Python code > https://docs.python.org/3/library/ast.html.
This looks good. We write the object hierarchy completely in Python with "sample" implementations in Python. From the resulting AST, we automatically generate the C++ class hierarchy, Fortran 2008 class monstrosities, some kind of reasonable mapping to Julia, a mapping to C, we can also have checkers on the AST to ensure we are following all our style rules. In addition, presumably, this would make semi-automatic refactoring of the Python code straightforward. I don't think that "Python famously optimizes almost nothing" is important in our case. In other words the Python AST becomes our SIDL. I would say C++ is immediately out of the running as the base implementation language since there cannot be this clean automation because of the clang crappy AST, which I have heard from others also. Note: our basic building blocks must cleanly support derivative-enabled libraries everywhere, including the API mapping to other languages. So we need to keep this in mind. > On Jul 31, 2022, at 12:31 PM, Jacob Faibussowitsch <jacob....@gmail.com> > wrote: > > Responding to 2 things here: > >> Jacob, would you consider VTK to be "Modern C++"? It was designed in the 90s >> and I think C++11 isn't widely used (architecturally) since it was first >> allowed a few years ago. > > > I don’t know, I have personally never interacted or read their codebase. > Certainly any library that is pre-C++11 will have old C++ cruft. To give a > counter-example, I would consider Kokkos or Thrust to be relatively modern > C++ libraries. > >> Does clang work with a high enough level of abstraction in its >> representation of C++ to map directly to Python classes, for example. > > Sure, we can walk the Clang AST. But then we are in the business of writing a > domain-specific language, and are firmly tied to a compiler. From my time > writing the clang linter I am personally very comfortable with libclang but I > can tell you that it: > > A. Takes a while to get up to speed. AST closely align with the source but > are not overly “friendly". As an example, try walking the AST backwards (to > for example find wherever a variable is written to). You’ll find this is a > monumental undertaking. > B. Many small idiosyncrasies to learn that are somewhat sparsely documented. > There are also no real “examples” to copy/learn from. > >> Does Python have any useful high-level representation that could be used so >> that we write in Python and generate from its representation? > > Yes, Python exposes the “ast” module for direct introspection of Python code > https://docs.python.org/3/library/ast.html. You can then use this to generate > arbitrary code. Team green uses this in their WARP library > (https://github.com/NVIDIA/warp) to generate CUDA kernels from python src. > But doing so has enormous pitfalls, mostly to do with optimization. Python > famously optimizes almost nothing because you can never be sure that an > expression doesn’t have a side-effect. > > Best regards, > > Jacob Faibussowitsch > (Jacob Fai - booss - oh - vitch) > >> On Jul 31, 2022, at 12:09, Barry Smith <bsm...@petsc.dev> wrote: >> >> >>> My issue with C++ is not the language itself, but the lack of discipline of >>> C++ developers. There are disastrous stories we all know well. But there >>> are successful ones, like VTK/ParaView. >> >> I fear that it would be difficult to learn and maintain discipline in PETSc >> C++ developments. We are largely self-taught, want functionality quickly, >> and the google approach to learning C++ and implementing PETSc will be a >> disaster. We would need to have a starting mechanism that prevents the >> monkeys with machine guns. >> >> To do multiple language mappings properly, I think we need to start with a >> language with a powerful, high-level useful AST (or some similar >> representation) that automated tools can scarf through to generate language >> bindings and verify the code is properly written from day one. Rather than >> picking the language based on its syntax, flexibility etc, we should pick it >> based on this property. Does clang work with a high enough level of >> abstraction in its representation of C++ to map directly to Python classes, >> for example. Does Python have any useful high-level representation that >> could be used so that we write in Python and generate from its >> representation? Rust? Zig? Carbon? Fortran 2035? >> >> >> >>> On Jul 31, 2022, at 10:26 AM, Lisandro Dalcin <dalc...@gmail.com> wrote: >>> >>> >>> >>> On Sun, 31 Jul 2022 at 17:07, Matthew Knepley <knep...@gmail.com> wrote: >>> On Sun, Jul 31, 2022 at 9:06 AM Lisandro Dalcin <dalc...@gmail.com> wrote: >>> On Sun, 31 Jul 2022 at 16:41, Jacob Faibussowitsch <jacob....@gmail.com> >>> wrote: >>> >>>> Please don't take my words as advocacy for C++ >>> >>> I’m going to pretend like I didn’t read this :) >>> >>> Whatever the final decision is, PETSc should keep providing a plain C API. >>> C is lingua franca, C++ is not. Many other programming languages have >>> runtime FFIs mostly based on the C ABI guarantees (Java, Python, MATLAB, >>> Rust, Julia, etc). C++ may be great for development, but I do not consider >>> it great for crossing language boundaries. >>> >>> Maybe the right approach for petsc4py is to first get nice and modern C++ >>> bindings implemented by wrapping the C interface. And then map these C++ >>> bindings to Python. >>> >>> My crystal ball says that such a C++ binding would eventually be thrown >>> away just as in the case of MPI. >>> >>> MPI C++ failed because it provided little added value. But if a PETSc C++ >>> API would become the base of bindings for other OO languages, then there is >>> value in maintaining these C++ bindings. >>> Furthermore, these C++ bindings could serve as the foundation for a >>> reimplementation of PETSc in C++, if that ever happens. And that can be >>> done gradually. >>> >>> PS: Modern C++ is a great language to implement stuff. People using C++ is >>> another story, it is like giving a machine gun to monkeys. Well, at this >>> point, I could say exactly the same about Python. >>> My issue with C++ is not the language itself, but the lack of discipline of >>> C++ developers. There are disastrous stories we all know well. But there >>> are successful ones, like VTK/ParaView. >>> >>> >>> -- >>> Lisandro Dalcin >>> ============ >>> Senior Research Scientist >>> Extreme Computing Research Center (ECRC) >>> King Abdullah University of Science and Technology (KAUST) >>> http://ecrc.kaust.edu.sa/ >> >
