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.
