This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
We're out of tree codes; now what?
- From: Tarmo Pikaro <tapika at yahoo dot com>
- To: gcc at gcc dot gnu dot org
- Date: Sat, 24 Mar 2007 05:55:17 -0700 (PDT)
- Subject: We're out of tree codes; now what?
> One advantage of most computer languages (with the arguable exception of
> C, but even it has preprocessor macros) is that they provide high-level
> constructs that make it easier to write programs.
Constructors and destructors are quite simple functions which are
executed at particular time. You could code constructs and destructs in C
if you would like to do it. Have you seen symbian's two-pass constructs ?
You may think that yes, constructs are the essence of programming,
but in fact they are not. More important is 1. clear, self-descriptive terminology
2. testing 3. dependency tracking (which source depends on which)
1 allows more fluent communication between programmers (and not only programmers)
2 allows to make programs which actually work. 3 improves reusability.
(Which is currently does not exist in block box form - most of code is
copy pasted from one place to another - white box reuse.)
> I believe that many
> of these high-level constructs are reduced to more verbose lower-level
> constructs in some of the language front ends (I know that this is true
> in Fortran; I'm not as sure about other front ends), which means that
> programming in Generic will require programming at a much lower level.
How to present a program in visual form so it would be easy to
understand and edit is another question. I have seen programs written
in C++ which were not working at all, and I have seen a programs written in
pure C - which were properly tested and worked faster than C++ analogues.
(And gcc is one of the examples which is written in C)
Sometime high level becomes too "high". Just try to read XML standards
- they are suffering from overabstraction and not bound to any
particular / real problem.
> I don't think your expected advantages to editing the compiler's
> representation directly will counteract that disadvantage.
If I edit assembler code - of course I will not benefit from it. But
it must not be assembler code - it must be as close for human
to understand and as simple to edit/modify as possible.
--
Have a nice day!
Tarmo.
____________________________________________________________________________________
8:00? 8:25? 8:40? Find a flick in no time
with the Yahoo! Search movie showtime shortcut.
http://tools.search.yahoo.com/shortcuts/#news