<div dir="ltr">On Thu, Feb 7, 2013 at 7:35 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote: <div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
<br>
</div>  Yup, absolutely and not a problem since we write the implementations and only the interface is generated. Surely we would not write some generator that is so stupid that it would generate the same thing twice and then barf because it got confused? We have slightly higher standards than Babel.<br>
</blockquote><div><br></div><div style>Okay, but now the generator needs a global view and/or an understanding of module dependencies. How will you express those dependencies? Here's a compiler guy talking about how to design a module system for C.</div>
<div style><br></div><div style><a href="http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf">http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
> No, you're just changing the behavior of the code by annotating using comments. I.e., extending the language. It's not plain C because the "comments" are semantically significant and not even optional.<br>

<br>
</div>   I knew you would say that. Using comments would only be a temporary thing until the tools knew a bit about the class structure and could do everything automatically.<br></blockquote><div><br></div><div style>But not "automatically" in C because these semantics are not directly expressible in C. Presumably you're going to add keywords/syntax to communicate that structure. And now you're making a new programming language.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im"><br>
> HOW does it "understand" the semantics you are writing down? Is it through more annotation that you're going to put in the comments? Or magic names and a piece of code in the preprocessor that recognizes that name and pattern?<br>

<br>
</div>   No, based on dependencies it can figure out the types of the internal variables from the the type change to the argument thus doesn't need you to "mark" the variables with some "type" crap name.<br>
</blockquote><div><br></div><div style>1. Is your language going to have type inference too?</div><div style><br></div><div style>2. Somewhere we have to decide between static and dynamic typing. Will your language have a JIT?</div>
<div>  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
</div>   Yes and that is part of the problem. We are dependent on these non-machine-manipulatable constructs in our code (yes, my fault). Hacks, if you will.<br></blockquote><div><br></div><div style>Sure, but what do you replace them with? Comments instructing the preprocessor to perform the equivalent of macro expansion? How is that machine-manipulatable? The manipulator needs to understand your comments to do anything.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im"></div>
<br>
   Regardless, we are using code generation today. Why don't we at least do it honestly and have the generators separate from the data they use to do the generation and the location where the generated code goes? Now it is all in the same damn file!<br>
</blockquote><div><br></div><div style>I don't think that distributing the logic between more languages/files is better in any way.</div></div></div></div>