<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 7, 2013 at 3:50 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">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>   Why would it not be? Your editor is not capable of ever displaying more than one buffer ever?<br></div>
</blockquote><div><br></div><div>Now I'll have two versions of the "same file". I could probably even script Emacs to handle this better than it normally does (like a keybinding to flip between original and preprocessed), but everyone that interacted with the code would have to do the same. Would we use this method in examples or would they all contain CHKERRQ stuff?</div>
<div><br></div><div style>It would be a disaster to require everyone to run our preprocessor just to compile their code. It is tantamount to creating another language.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>

<br>
   If you want to think in terms of revision control systems and working directories then when using the debugger your "smudged" version of the code has all the "generated" (CHKERRQ….)<br>
stuff displayed. How it could work: while using the debugger you realize a bug exists, you "fix" the bug in the "smudged" version in your working directory based on what you see in the debugger, run the compile, load the new executable in the debugger, verify your fix works and then "add" in git your smudged (now fixed) code into the "index" at which point it is "desmudged" back into the standard form. You can then commit and push.<br>
</div></blockquote><div><br></div><div style>Wait, which version do we edit when we don't have a bug?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>

<br>
Note that this does not even require some GUI development system and is similar to our current work flow. The only "new" concept is the concept of having various "smudged" versions of the code in the working directory.<br>
</div></blockquote><div><br></div><div style>Yeah, I think that having multiple versions will be much more difficult to work with than you seem to think.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>
> I agree that CPP is a crappy code generator. In lieu of hygienic macros, we either need to use a separate source language<br>
<br>
</div>   Why? C is a great language, we can just generate from C.<br></div></blockquote><div><br></div><div style>You must mean C plus some yet-to-be-defined templating system. I've never seen such a thing done well.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div></div>
<br>
  Generating code on a case by case ad hoc basis will result in a mess. Doing it in a systematic way using a good representation need not.</div></blockquote></div><br>If you really believe this, start proposing semantics. I think it will be very difficult to avert a disaster and I don't think it could possibly offer that much value.</div>
</div>