On Thu, Feb 7, 2013 at 7:35 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
> > 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. > 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. http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf > > 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. > > 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. > 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. > > 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? > > 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. > 1. Is your language going to have type inference too? 2. Somewhere we have to decide between static and dynamic typing. Will your language have a JIT? > 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. > 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. > > 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! > I don't think that distributing the logic between more languages/files is better in any way. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130207/d37b02f1/attachment.html>
