On Feb 7, 2013, at 6:56 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
> 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).
Yup, absolutely and not a problem since we write the implementations and only
the interface is generated. Surely we would not write some generator that is so
stupid that it would generate the same thing twice and then barf because it got
confused? We have slightly higher standards than Babel.
>
>
> 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.
I knew you would say that. Using comments would only be a temporary thing
until the tools knew a bit about the class structure and could do everything
automatically.
>
> 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 never said it was worse than vpscat.h; I agree using the include file on
my part is not as good as your approach. BTW: I hate the paste operator.
> 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?
No, based on dependencies it can figure out the types of the internal
variables from the the type change to the argument thus doesn't need you to
"mark" the variables with some "type" crap name.
>
>
> 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.
Yes and that is part of the problem. We are dependent on these
non-machine-manipulatable constructs in our code (yes, my fault). Hacks, if you
will.
>
>
> 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?
Why would you ever like to manipulate the internals of the atom? What would
that ability ever give you? Nothing important I'm sure.
Regardless, we are using code generation today. Why don't we at least do it
honestly and have the generators separate from the data they use to do the
generation and the location where the generated code goes? Now it is all in the
same damn file!
I gave Jim a hard time for using m4 as a code generator; we are doing
something even more primitive.
Barry
>
>
> 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.
