[petsc-dev] ugliness due to missing lapack routines

[Jed Brown]

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>