[petsc-dev] Symbol visibility

[Jed Brown]

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.  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.

Jed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20101206/794c1ff1/attachment.html>