[petsc-dev] Symbol visibility

[Barry Smith]

On Dec 6, 2010, at 3:15 PM, Jed Brown wrote:

> On Mon, Dec 6, 2010 at 21:59, Barry Smith <bsmith at mcs.anl.gov> wrote:
> This is nice but doesn't demonstrate that the compiler keeps all the information; for example does it keep in the AST all the information in the unvisited #else of an #if?
> 
> That's infinite in some real cases where header guards are actually required from having circular includes.

  Yes, this is an example of the difficulties of mixing CPP with C and why it is best to eliminate the CPP :-)

>  But keeping that "unused" information is, I'm pretty sure, much less deep than having the type checker look put a carrot at the place in a macro definition that caused a type mismatch.
>  
> 
>   I disagree. That still relies on us editing source code which is a very inefficient way of developing code (though it is the only way I know). The only reason for plain text files is because that is what the compilers and RCS want to see; it doesn't have anything to do with working with Fortran/python etc easily. We should generate plain text files only when we need to for other tools like compilers.
> 
> I guess I don't understand.  Do you want to program without editing text (i.e. in a non-textual language)?  Or do you just want to edit a representation that is oblivious of which files the text is actually stored in (and how it is indented, etc)?  Smalltalks usually store everything in an "image" which usually has its own versioning system and its own tools to manipulate.  What that offers sounds a lot like what you describe, it's something that a lot of smalltalkers love, but it's also arguably the reason why languages like Python and Ruby are a lot more popular, despite not being very innovative as languages (both, especially Ruby, borrow a lot from Smalltalk).
> 
> As "inefficient" as it may feel, I think it's premature to label our current methods as such without a proof-of-concept of something better.  Languages can be a lot more expressive than C, but I'm not convinced that editing text is inherently inefficient.

  Of course in the end we will be editing "code fragments" in an editor. But I would like to see much of the code obtained by "manipulating" the code fragments with powerful tools (beyond CPP or regular expressions), for example all the code that is in there for different block sizes should be "generated"; but I don't want it generated by crude m4 macros and crap like that.  Note that C++ templates try to provide a mechanism for this type of thing but we both think that mechanism is crappy.

  BTW: we don't disagree about anything,

   Barry



> 
> Jed