On Dec 6, 2010, at 1:02 PM, Jed Brown wrote: > On Mon, Dec 6, 2010 at 19:53, Barry Smith <bsmith at mcs.anl.gov> wrote: > Worse comes to worse I put it back (but better next time :-). > > Apparently this can done purely with headers (no need to touch all the source > files) and (uglier in my opinion, but still possible) with a pragma to push > and pop the visibility state (C99 at least has _Pragma, it's dirtier to need > #pragma (of course wrapped based on a configure test)). This makes it a much > simpler issue to "put back, but better" if needed. > > Actually I think handling these "things" with CPP is not the way to go, in > fact, I'd like to see, if possible, almost no use of CPP in PETSc source. > Reason: PETSc source code currently is the combination of two relatively > simple but very different, languages CPP and C. Doing source to source > manipulations on this beast is a nightmare because one cannot even parse CPP > plus C. If we eliminate the CPP then it becomes only C which we parse and > manipulate relatively easily, this opens up enormous opportunities for a > whole new approach to code development we do not have currently and cannot > have with a CPP plus C code base. Of course, I could be totally on the wrong > track but I won't know without investigation. > > Clang/LLVM can parse the C with everything in it, then give you the AST or > whatever intermediate form you like.
Nonsense! Clang/LLVM preprocesses the CPP directives out and gives you the AST for the resulting C code. This is definitely not what we want because we cannot even go back from this form to the original code, and the first thing I want with any source to source translator is the identity operator. Now if I am wrong and Clang/LLVM does preserve all the CPP constructs (which I believe is pretty much impossible) then that is FANTASTIC and we are half-way to nirvana already and we can laden PETSc with as many complicated CPP macros as we want :-). Please tell me I am wrong. > > Honestly I am sick of having this big code base where making changes means > editing flat files and manually changing source code, I thinking that model > really needs to change. I don't really know how to change the model but I > really want to see if change and if that involves going down some wrong roads > that is ok with me, better than not trying things. > > Sounds like you should switch to Smalltalk. I want a language that people actually use and that plays well with other languages but I want the advantage of languages that support more than the edit file--run compiler paradigm and if no one else wants to develop that then we need to develop it. Barry > > Jed
