On Thu, Feb 7, 2013 at 6:32 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> > On Feb 7, 2013, at 5:56 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote: > > > > > On Thu, Feb 7, 2013 at 5:51 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > These are in the category of those that CANNOT be trivially > converted to C functions. They are the tough nuts to crack. We need to > categorize them and see what makes sense to do with them. > > > > Do you agree that the "new" version of those constructs will not be > plain C? Either you will be moving non-trivial logic from C to the > preprocessor itself (thus distributing logic between preprocessor > implementation and "normal" source files) or you will be adding some extra > semantics to the dialect of "C" that will be understood by the preprocessor? > > 1) All of the "sticking in extra error processing stuff" like > PetscFunctionBegin/CHKERRQ()/PetscStackCall() does not require any new > syntax in the C language. > It's just syntax, easily produced automatically from our editors, and easy to "look past". Either we put it in automatically everywhere, with some annotation or list of rules about where to _not_ put it in, or we put it in everywhere we need it. There are a lot of ways that we could handle this so let's focus on the more interesting parts. > > 2) Macros like PetscTryMethod() won't be needed. Instead the user > interface functions like KSPGMRESSetRestart() would be completely > auto-generated from the underlying implementation routines > KSPGMRESSetRestart_GMRES(). > Recall that there are multiple different implementations of the same interface (_GMRES and _FGMRES in this case). > > Now the question of how the system knows that the routine > KSPGMRESSetRestart_GMRES() should auto-generate KSPGMRESSetRestart() is a > good question. I don't think we need to resolve that now; it could be a > formatted comment in the code, it could be based on the function naming > convention; it is really associated with our class structure (whether we > want to teach our "source tools" about the class structure comes later). > But it doesn't need to require adding syntax to C. > No, you're just changing the behavior of the code by annotating using comments. I.e., extending the language. It's not plain C because the "comments" are semantically significant and not even optional. > 3) Code generation for different types and block sizes > > No matter what we do it couldn't be worse then the absolutely horrible > stuff you added recently in the top of sfbasic.c Didn't you feel all > itching when you were typing that stuff in? > Sure, but it's more contained and more generic than vpscat.h/vpscat.c. I would have used C++ templates there (very isolated) if we could use such a thing. I actually think C++ templates solve that problem about as well as any system could. (It's everything else templates are used for that is the disaster.) > > I actually would like the original routine(s) to be pure C and then to > separately indicate what other functions to build from that original one. > So for example if you have myfunction(int a,double *b, int *c) and you want > a version of the function build from my function() with arguments > int,int*,double*. You would tell the system this and it would generate the > new version. Note that because the AST "understands" the routine as C (not > ascii) there is no reason to do all the <type> crap that C++ templates or > your horrific sfbasic.c code requires. > HOW does it "understand" the semantics you are writing down? Is it through more annotation that you're going to put in the comments? Or magic names and a piece of code in the preprocessor that recognizes that name and pattern? > > So my answer is yes there will be no new language syntax added and yes > the "non-trivial" logic will be in a different place from the code. But I > submit that the "non-trivial" logic will generally be trivial certainly it > will be trivial to reproduce all the horrible stuff we manage now with CPP. > And the logic isn't associated with any one particular chunk of C code so > doesn't need to be with that particular source code. > The PetscOptions macros are far from trivial logic. > > Is what I propose possible? I don't know, nor do I particularly care, > but I do know that the stuff at the top of sfbasic.c is not a good approach > and the more stuff we add like that the more difficult it will ever get to > do things "a better way" since that kind of CPP can never be represented in > a way that allows manipulating the source code via source code tools > (because CPP plus C is not a language). > How would you like to manipulate that code? What would that achieve? > > Barry > > Jed, > > I am not meaning to attack you in particular for utilizing CPP in this > way. I am very guilty of it as well, because at those times I felt it was > the only "reliable" way to do things. I am now hoping I was wrong. > I felt it was the least-bad of the available choices in this case. I'd like to have a better mechanism, but that code only took a couple hours to write and it's working reliably now. I believe MPI should provide a way for us to avoid writing code like that, but not now. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130207/04a76b34/attachment-0001.html>
