<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 7, 2013 at 11:48 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 id=":6ct"> This is not a problem, because I will be implementing in Haskell a system to manipulate Python code. Thus managing the python code that manages the C code will become a far easier task :-)<br>
</div></blockquote><div><br></div><div style>Where does m4 fit in?</div><div style><br></div><div style>And hopefully Perl. Anything that uses _both_ m4 and another language to manipulate a third language is bound to be good.</div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":6ct">
<br>
   You are perfectly happy using a really crappy system for manipulating C code (CPP) but fear that a better system would be impossible to get right?  What if I proposed just one tweak to CPP to make PETSc source code better, would you consider that?</div>
</blockquote></div><br>I would consider it based on the value of that tweak, acknowledging that changing CPP in any way presents a severe workflow contortion.</div></div>