<div class="gmail_quote">On Mon, Dec 6, 2010 at 20:13, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":1kg">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.<br>
</div></blockquote><div><br></div><div>Actually, look at their error messages (<a href="http://clang.llvm.org/diagnostics.html">http://clang.llvm.org/diagnostics.html</a>)</div><div><br></div><div><font class="Apple-style-span" face="'courier new', monospace">double *x,y;</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace"><br></font></div><div><div><font class="Apple-style-span" face="'courier new', monospace">bar.c:6:3: error: invalid operands to binary expression ('double **' and 'double')</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace">  PetscPrefetchBlock(&x,y,0,PETSC_PREFETCH_HINT_NTA);</font></div><div><font class="Apple-style-span" face="'courier new', monospace">  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace">In file included from bar.c:1:</font></div><div><font class="Apple-style-span" face="'courier new', monospace">/home/jed/petsc/include/petscsys.h:1862:64: note: instantiated from:</font></div>
<div><font class="Apple-style-span" face="'courier new', monospace">    const char *_p = (const char*)(a),*_end = (const char*)((a)+(n));   \</font></div><div><font class="Apple-style-span" face="'courier new', monospace">                                                            ~~~^~~~</font></div>
</div><div><br></div><div>(These are also in color.)  The translation back through the macro is certainly still available to the type checker.</div><div>  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div id=":1kg"><div class="im">
</div>   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.</div>
</blockquote></div><br><div>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.  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).</div>
<div><br></div><div>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).</div>
<div><br></div><div>Jed</div>