[petsc-dev] ugliness due to missing lapack routines

[Barry Smith]

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. 

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().

    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.

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?

   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.

  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.

   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).

   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.