Hi everyone!
Continuing with the theme of discussing the PDDs, here is a starter
email to kick off discussion of PDD07 - the coding standards of
Parrot. Coding standards can often be a really touchy subject, so I
hope we can amicably come to consensus decisions about the various
points I'm about to bring up in the document.
=item *
Under "Language Standards and Portability" there is the todo item:
{{ RT#45359: Enumerate all other non-C89 assumptions that Parrot
depends on. }}
Currently we have such assumptions as:
In addition, C code may assume that any pointer value can be coerced to an
integral type (no smaller than typedef C<INTVAL> in Parrot), then back to its
original type, without loss.
Are there any others?
=item *
Under "Code Structure" there is the comment:
Avoid dependency on "FIXME" and "TODO" labels; if a bug must be fixed soon,
use "XXX", else use the external bug tracking system.
Shouldn't we put everything into the bug tracking system? There are
so many XXX items sitting in the code currently (I've converted many
into RT tickets, but there are hundreds to go) and they've been in
there quite a while. Is it a good idea to make a blanket "put
everything into RT" policy (and isn't that the current policy anyway)?
=item *
Chip only got so far through the coding standards PDD before other
things in his life took over (which I hope are now going better!).
Therefore much of the rest of the document (after "Naming
Conventions") needs to be discussed and decided upon.
=item Subsystems and APIs
The C<misc> subsystem is mentioned in this section. It doesn't seem
to appear anywhere. Do we need such a subsystem? Is there a list of
known subsystems anywhere?
=item Filenames
It's mentioned that ideally filenames should be restricted to 8.3
format. Should this really be the case? Windows has handled longer
filenames for a long time now (and so have unix-based systems); so do
we really need to worry? This is probably only a recommendation
anyway.
=item Macro names
The document mentions macro names such as C<PERL_IN_CORE>,
C<PERL_IN_FOO>, and C<PERL_USE_STDIO>. I'm guessing this is as a
result of copy and paste from an original Perl 5 document, so
shouldn't these macro names be C<PARROT_IN_CORE>, C<PARROT_IN_FOO> and
C<PARROT_USE_STDIO>?
A related question: shouldn't the text (mentioned later under "Global
variables")
# define GLOBALS_BASE (Perl_globals)
really be
# define GLOBALS_BASE (Parrot_globals)
=item foo.sym file format
It is mentioned that the format and contents of the C<foo.sym> file
(for the Parrot subsystem C<foo>) need to be decided.
=item Per-entity comments
I've noticed in the source lots of C<FUNCDOC> sections in C-language
code. Shouldn't this just be plain pod as mentioned in PDD07? This
would mean that more docs are picked up when we run C<make html>,
isn't that right?
=item Performance
There's a mention in this section about what the dominant factor in
2001 is for processor performance. Being at least 6 years away from
that point, what's changed? Is cache still the biggest factor for
performance hits/gains? Clock rates haven't increased that much of
late (the docs currently mention that they've been going up a lot) and
multi-processor systems seem to be the "way of the future" currently
(I saw a talk recently where a guy was talking about commodity systems
with 64 or 128 cores in about 5 years). So is it worth noting such
stuff here? Are there any other performance issues we should discuss
in this section?
=cut
Again, if you got to here, well done! And thanks!
Paul
