On Feb 7, 2013, at 10:51 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> > On Thu, Feb 7, 2013 at 10:33 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > You're proposing manipulating your new language that looks like C with > > annotations in comments or special keywords or new control structures or > > something and can be compiled to C by your "preprocessor". > > You are imagining the "annotations in comments" and the "special keywords" > I never said they would be there. > > I want tools that OPERATE on C code. That is they take a chunk of pure C > code as input and return a chunk of pure C code as output > (the transformations I want to perform on the code are completely external to > that chunk of code). You still want to insist that the transformations I > want to perform and the C code I want it performed on MUST be in the same > file mixed together in a bunch of ASCII (i.e formatted comments or special > keywords). I submit that this is absolutely the wrong way to do it (sorry > Boyana). > > I think we agree that PetscTryMethod and PetscOptionsBegin are not > expressible in C (without a lot of code duplication), but are an important > part of PETSc. That means your preprocessor thingy has to be told when to > inject that stuff. Since it can't possibly make the right decision every time > without you saying anything, you will have to tell it somehow. How do you > propose to do that? You need to know the right approach to everything you are going to do down to the last detail before you start a project? Hell when I start a project I just enter my editor and start typing :-) Maybe instead of having a PetscOptionsBegin macro the entire XXXSetFromOptions() function is called multiple times by its caller to get the same effect. We don't need exact mappings from the current constructs to the new constructs so long as we have the same positive user experience. We are too quick to come up with CPP hacks to do something that we don't even contemplate other possibilities. Barry
