On Dec 6, 2010, at 1:50 PM, Jed Brown wrote: > On Mon, Dec 6, 2010 at 20:13, Barry Smith <bsmith at mcs.anl.gov> wrote: > 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. > > Actually, look at their error messages > (http://clang.llvm.org/diagnostics.html) > > double *x,y; > > bar.c:6:3: error: invalid operands to binary expression ('double **' and > 'double') > PetscPrefetchBlock(&x,y,0,PETSC_PREFETCH_HINT_NTA); > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > In file included from bar.c:1: > /home/jed/petsc/include/petscsys.h:1862:64: note: instantiated from: > const char *_p = (const char*)(a),*_end = (const char*)((a)+(n)); \ > ~~~^~~~ > > (These are also in color.) The translation back through the macro is > certainly still available to the type checker.
This is nice but doesn't demonstrate that the compiler keeps all the information; for example does it keep in the AST all the information in the unvisited #else of an #if? > > 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. > > Just make compilation fast enough that it can happen automatically while you > edit. C cannot be as dynamic as a Lisp or Smalltalk, you necessarily have to > restart the program to change the definition of a struct, for example. > PFString-style tricks get you a little ways, but it's still far less > interactive. Having source reside in plain text files is a significant part > of "plays well with other languages/tools". We just need good tools for > navigating the source so that the existence of files is mostly transparent. I disagree. That still relies on us editing source code which is a very inefficient way of developing code (though it is the only way I know). The only reason for plain text files is because that is what the compilers and RCS want to see; it doesn't have anything to do with working with Fortran/python etc easily. We should generate plain text files only when we need to for other tools like compilers. Barry > IDEs like Eclipse do this more reliably than Emacs (even with CEDET and > global), but I still can't stand using them. My biggest complaint about > these tools is that the amount of analysis that I can turn on is limited by > interactive performance (mostly due to silly database decisions). > > It's insane that it's 2010 and I'm complaining that my editor is too slow. I > can do full text search of my 6 GB mail archive in under a second, but it > takes many seconds for my editor to find every place that MatGetSubMatrix is > used (plain grep is faster, but without semantic analysis -- it's only > searching text). We should have the compiler spitting out semantic > information and the editor should put it in a decent database with an index, > then semantic queries (both forward and reverse) would be answered in under > 100ms and we could get on with life. Duplicating a slow, buggy, incomplete > parser inside the editor is insane. Clang/LLVM is something Apple has been > behind that I think is unambiguously good. Now we just need a way to have > Emacs use it correctly (or a replacement for Emacs, but that seems even less > likely). > > Jed
