Re: multi method dispatching of optional arguments (further refined)
On Tuesday 05 September 2006 07:52, Trey Harris wrote:
I don't think you're dumb; the Synopses just require that you intuit
certain things from each other, from examples in other Synopses, and so on
in a Perlish sort of way; what you're looking for is not spelled out
explicitly. It can be found by noticing how you specify subtypes, along
with noticing that subtypes can be specified as parameter types. There's
also an example showing explicitly what you want in S12.
Ok, I'll try to dive through the documentation before asking questions.
It's just
multi sub SomeThing(Num $a where {$^a == 4}, Num $b) { $b + 2 }
multi sub SomeThing(Num $a, Num $b where {$^b == 3}) { $a + 1 }
multi sub SomeThing(Num $a, Num $b) { $a * $b }
Yes, the signatures are different--the first two multis specify subtypes
as their signatures, the last specifies a canonical type.
Thank you *very* much! That clears it up.
Regards,
Phil
Re: Parrot-14347 Patches to get Parrot to build on VMS VAX
Leo wrote: I wrote: Bear with me on the VMSish filenames; xxx;1 is the original version, xxx; is the patched version of the file. I wrote a small perl helper, dealing with that. But what about filenames like: +++ lib/parrot.configure/step.pm; which actually is: +++ lib/Parrot/Configure/Step.pm As I said: bear with me. The filenames looked like [lib.Parrot.Configure]Step.pm originally, and I tried to make things easier for a *ix diff by unixifying them. Obviously I failed miserably... ;-) I now have an original source tree at the side of my devel directory, so I can diff -urdN the whole thing. This makes things interesting another way, though, because the files' capitalization is lost that way. sigh Please disregard the patch posted, as (it contained a bug and) I've done some more work last night. I now have a version that runs through Configure.pl without errors. The settings generated look sound, and the generated makefiles don't look too bad [1], but are not yet totally MMS-clean. I'll come back with a patch (against the latest SVN revision, of course) when it's good enough to be published. That said, it was a relatively painless port so far. Thanks to all who wrote the configuration scripts with portability in mind. cu, Martin [1] for a make/MMS comparison, please see http://vms.pdv-systeme.de/users/martinv/VMS_Programming_FAQ.html#4.1. (and yes, the trailing dot is part of the URL) -- | Martin Vorlaender | OpenVMS rules! VMS is today what | work: [EMAIL PROTECTED] Microsoft wants| http://www.pdv-systeme.de/users/martinv/ Windows NT 8.0 to be! | home: [EMAIL PROTECTED]
Re: cperl-mode.el: twigils and opers
Trey Harris [EMAIL PROTECTED] writes:
In a message dated Mon, 4 Sep 2006, Steffen Schwigon writes:
First you could try an older revision, I recommend r7845 or r10822 of
pugs repository.
No, neither of those work. To see what I'm talking about, just create
a file containing:
use v6-alpha;
class Point {
has $.x;
has $.y;
}
and try creating more code under the has $.y line, and notice that
indenting and highlighting after that point don't work because emacs
thinks it's in the middle of a y///.
I checked and indeed the twigils don't work. My test source file
(which worked correctly some time ago) also highlights wrong. It's for
sure a bug I introduced.
I can't promise that it also worked with y as variable name. That's
probably a second issue. But it should also be possible to solve.
Well, a fork for cperl6-mode wouldn't be the worst thing... at least
then it would be possible to have working syntax highlighting and
indention for Perl 6.
This time the issues should be solvable. Forking shouldn't be
neccessary for this. I try to have a look at it this week.
Sorry that I'm not as fast as pugs development normally feels. :-)
GreetinX
Steffen
--
Steffen Schwigon [EMAIL PROTECTED]
Dresden Perl Mongers http://dresden-pm.org/
Re: multi method dispatching of optional arguments (further refined)
Ph. Marek schreef:
[Haskell]
SomeThing a b
| a = 4 : b+2
| b = 3 : a+1
| otherwise : a*b
In Perl5 this looks like
sub SomeThing
{
my($a, $b)[EMAIL PROTECTED];
return b+2 if ($a == 4);
return a+1 if ($b == 3);
return a*b;
}
Or like:
sub SomeThing
{
alias my ($p, $q) = @_ ;
$p == 4 ? $q + 2 :
$q == 3 ? $p + 1 :
$p * $q ;
}
--
Groet, Ruud
synopses on smoke server
Agentz++ writes, in a Pugs blog comment: if someone can offer regular smoke results (i.e. the tests.yml generated by `make smoke'), we can render the Synopses on feather with smoke results as well The obvious way to get this to happen, for all runtimes, is to integrate the synopsis-with-smoke production with the existing smoke server infrastructure. I've started hacking this in, but have some concerns. A few are mainly directed to iblech++. 1. Multi-versioning the tests: The inlined tests need to match the revision at which the smoke was produced. Is it okay to have the smoke server check out the relevant revision of the pugs/t directory each time a smoke of a new revision is submitted, or is that too expensive? 2. Should the synopses just be provided by a third » column on the existing smoke.pugscode.org index page, or should the synopses-with-smoke have a dedicated index page organized somewhat differently? 3. What is the full path to smartlinks.pl on the smoke server? 4. Is the smoke server getting refreshed copies of the synopses somewhere already? 5. Will a commit that changes smokeserv-server.pl be picked up by the smoke server right away? I might down the whole smoke system with my commit. Anyone willing to debug with me when I do? In summary, the basic pattern would be: (a) smokeserv-client sends both .html and .yml of smoke (b) If smokeserv-server gets .yml, it checks out the t/ directory for that revision, and (c) smokeserv-server runs smartlinks.pl on the .yml with that t/ directory and indexes it. Christopher
Re: synopses on smoke server
There are two other smoke servers to look into... One is written in Catalyst + DBIC, by yours truly. http://dev.catalystframework.org/repos/Catalyst/trunk/examples/SmokeServer I've stopped working on it due to lack of interest - nobody seemed unhappy enough with the currrent smoke server. Another is written in Jifty: http://search.cpan.org/dist/Test-Chimps/ It's further along, but is a little more specific to BP's workflow. -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgpyHr3SZiGXL.pgp Description: PGP signature
Re: clarify: how WALK arguments can be combined
Brad Bowman wrote:
Mark Stosberg wrote:
In the Objects chapter, a WALK pseudo-class is spec'ed for using
when calling sets of methods:
http://feather.perl6.nl/syn/S12.html#Calling_sets_of_methods
These are the arguments listed that can be used with WALK:
:canonical # canonical dispatch order
:ascendant # most-derived first, like destruction order
:descendant # least-derived first, like construction order
:preorder # like Perl 5 dispatch
:breadth# like multi dispatch
First, it would be nice if the comments like Perl 5 and like multi
dispatch could be expanded, if only to provide references to their
complete specs. Also, if canonical means something besides I don't
care, it would be nice to have a reference for that, too.
I think Class::C3 on CPAN describes and implements the Perl 6 dispatch
algorithm in Perl 5. I don't know if it's in the Synopses, etc.
So that would the preorder or the canonical case. In either case,
since multi methods don't (normally) exist in Perl 5, it's still not
clear what order multi methods will be resolved in.
My concern for the moment is clarification how these options can be
combined. Clearly, combining :ascendant and :descendant doesn't make
sense.
But, I assume a self.*meth call can work along both the inheritance
axis and the multi method access.
Therefore, it seems fair to combine one option that affects each axis.
Wouldn't :breadth just be the breadth first order of the same set
of methods? Mentioning multi dispatch kind of confusing...
So I think the permitted combinations are:
One sorting adverb (defaulting to :canonical):
:canonical, :ascendant, :descendant, :preorder, :breadth
Some number of filtering adverbs:
:super # only immediate parent classes
:methodname # only classes containing method declaration
:omit(Selector) # only classes that don't match selector
:include(Selector) # only classes that match selector
I agree in general, but still wonder about how the details sorting
adverbs apply to multi methods AND inherited methods.
I'd like to be able to access the list of methods returned by
the WALK traversal. Perhaps it is:
@methods = $object.*WALK::can('meth');
That looks potentially useful. The use case might be checking to see
which which methods /might/ be called and then perhaps changing or
avoiding the method set call based on the result.
Mark
Re: synopses on smoke server
Actually, it uses Jifty::DBI for its storage, but it's not a jifty app ;) http://search.cpan.org/dist/Test-Chimps/ It's further along, but is a little more specific to BP's workflow. The _intent_ was to make the tool more general than the existing pugs smoker. If we've somehow messed that up, I'd like to hear about it. And I should say that if you're interested in hacking on Chimps, we'd love more hackers. -j Jesse -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 -- --
Re: synopses on smoke server
On Tue, Sep 05, 2006 at 12:26:32 -0400, jesse wrote: Actually, it uses Jifty::DBI for its storage, but it's not a jifty app ;) Oh! The _intent_ was to make the tool more general than the existing pugs smoker. If we've somehow messed that up, I'd like to hear about it. Oh! I thought the Anna integration with the repo and all that was the tailored precisely for you guys. I stand corrected =) -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 pgp2Etmw71YFR.pgp Description: PGP signature
Re: synopses on smoke server
On Tue, Sep 05, 2006 at 07:24:14PM +0300, Yuval Kogman wrote: There are two other smoke servers to look into... One is written in Catalyst + DBIC, by yours truly. http://dev.catalystframework.org/repos/Catalyst/trunk/examples/SmokeServer I've stopped working on it due to lack of interest - nobody seemed unhappy enough with the currrent smoke server. Another is written in Jifty: Actually, it uses Jifty::DBI for its storage, but it's not a jifty app ;) http://search.cpan.org/dist/Test-Chimps/ It's further along, but is a little more specific to BP's workflow. The _intent_ was to make the tool more general than the existing pugs smoker. If we've somehow messed that up, I'd like to hear about it. Jesse -- Yuval Kogman [EMAIL PROTECTED] http://nothingmuch.woobling.org 0xEBD27418 --
[perl #40278] [CAGE] perl coding standards coda.
# New Ticket Created by Will Coleda # Please include the string: [perl #40278] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40278 From the recently updated pdd07: Perl source files must end with this block: # Local Variables: # mode: cperl # cperl-indent-level: 4 # fill-column: 100 # End: # vim: expandtab shiftwidth=4: -- Will Coke Coleda [EMAIL PROTECTED]
[svn:parrot-pdd] r14416 - in trunk: . docs/pdds
Author: chip
Date: Tue Sep 5 10:42:07 2006
New Revision: 14416
Added:
trunk/docs/pdds/pdd07_codingstd.pod (contents, props changed)
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
Log:
Move pdd07 out of clip
Added: trunk/docs/pdds/pdd07_codingstd.pod
==
--- (empty file)
+++ trunk/docs/pdds/pdd07_codingstd.pod Tue Sep 5 10:42:07 2006
@@ -0,0 +1,930 @@
+# Copyright (C) 2001-2006, The Perl Foundation.
+# $Id$
+
+=head1 NAME
+
+docs/pdds/pdd07_codingstd.pod - Conventions and Guidelines for Parrot Source
+Code
+
+=head1 ABSTRACT
+
+This document describes the various rules, guidelines and advice for those
+wishing to contribute to the source code of Parrot, in such areas as code
+structure, naming conventions, comments etc.
+
+=head1 DESCRIPTION
+
+One of the criticisms of Perl 5 is that its source code is impenetrable to
+newcomers, due to such things as inconsistent or obscure variable naming
+conventions, lack of comments in the source code, and so on. We don't intend
+to make the same mistake when writing Parrot. Hence this document.
+
+We define three classes of conventions. Those that say Imust are mandatory,
+and code will not be accepted (apart from in exceptional circumstances) unless
+it follows these rules. Those that say Ishould are strong guidelines that
+should normally be followed unless there is a sensible reason to do otherwise.
+Finally, those that say Imay, are tentative suggestions to be used at your
+discretion.
+
+Note this particular PDD makes some recommendations that are specific to the C
+programming language. This does not preclude Parrot (or Perl 6) being
+implemented in other languages, but in this case, additional PDDs may need to
+be authored for the extra language-specific features.
+
+=head1 IMPLEMENTATION
+
+=head2 Coding style
+
+The following Imust apply:
+
+=over 4
+
+=item *
+
+4 column indents for code and 2 column indents for nested CPP #directives. All
+indentation must consist of spaces, no tabs (for ease of patching).
+
+There are two exceptions to the CPP indenting- neither PARROT_IN_CORE nor the
+outermost _GUARD #ifdefs cause the level of indenting to increase.
+
+To ensure that tabs aren't inadvertently used for indentation, the following
+boilerplate code must appear at the bottom of each source file. (This rule may
+be rescinded if I'm ever threatened with a lynching)
+
+ /*
+* Local variables:
+* c-indentation-style: bsd
+* c-basic-offset: 4
+* indent-tabs-mode: nil
+* End:
+*
+* vim: expandtab shiftwidth=4:
+*/
+
+
+=item *
+
+Any other tabs are assumed to be on an 8-character boundary.
+
+=item *
+
+ANSI C function prototypes
+
+=item *
+
+KR style for indenting control constructs: ie the closing C} should line
+up with the opening Cif etc.
+
+=item *
+
+When a conditional spans multiple lines, the opening C{ must line up with the
+Cif or Cwhile, or be at the end-of-line otherwise.
+
+=item *
+
+Uncuddled Celses: ie avoid C} else {
+
+=item *
+
+C-style comments only (C/* comment */). Not all C compilers handle
+C++-style comments.
+
+=item *
+
+Mark places that need to be revisited with XXX (and preferably your initials
+too), and revisit often!
+
+=item *
+
+In function definitions, the name starts in column 0, with the return type on
+the previous line.
+
+=item *
+
+However, in function declarations (in header files) the return type is kept on
+the same line.
+
+=item *
+
+Variable names should be included for all function parameters in the function
+declarations. These names should match the parameters in the function
+definition.
+
+=item *
+
+Single space after keywords that are followed by C(), eg Creturn (x+y)*2,
+but no space between function name and following C(), eg Cz = foo(x+y)*2
+
+=back
+
+The following Ishould apply
+
+=over 4
+
+=item *
+
+Do not exceed 79 columns
+
+=item *
+
+Creturn foo; rather than Creturn (foo);
+
+=item *
+
+Cif (!foo) ... rather than Cif (foo == FALSE) ... etc.
+
+=item *
+
+Avoid assignments in conditionals, but if they're unavoidable, use Extra paren,
+e.g. Cif (a (b = c)) ...
+
+=item *
+
+Avoid double negatives, eg C#ifndef NO_FEATURE_FOO
+
+=item *
+
+Binary operators should have a space on either side; parentheses should not
+have space immediately after the opening paren nor immediately before the
+closing paren, commas should have space after but not before, eg
+
+x = (a + b) * f(c, d / e)
+
+=item *
+
+Long lines should be split before an operator so that it is immediately obvious
+when scanning the LHS of the code that this has happened, and two extra levels
+of indent should be used.
+
+=item *
+
+and/or split on matching parens, with the content on separate line(s) and with
+one extra indent:
+
+do_arbitrary_function(
+list_of_parameters_with_long_names, or_complex_subexpression(
+of_more_params,
[svn:parrot-pdd] r14419 - in trunk: . docs/pdds
Author: chip
Date: Tue Sep 5 10:42:52 2006
New Revision: 14419
Modified:
trunk/docs/pdds/pdd07_codingstd.pod
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
Log:
About 25% done with update of pdd07.
Modified: trunk/docs/pdds/pdd07_codingstd.pod
==
--- trunk/docs/pdds/pdd07_codingstd.pod (original)
+++ trunk/docs/pdds/pdd07_codingstd.pod Tue Sep 5 10:42:52 2006
@@ -3,9 +3,13 @@
=head1 NAME
-docs/pdds/pdd07_codingstd.pod - Conventions and Guidelines for Parrot Source
+docs/pdds/pdd07_codingstd.pod - Conventions and Guidelines for Parrot Source
Code
+=head1 VERSION
+
+$Revision$
+
=head1 ABSTRACT
This document describes the various rules, guidelines and advice for those
@@ -19,316 +23,306 @@
conventions, lack of comments in the source code, and so on. We don't intend
to make the same mistake when writing Parrot. Hence this document.
-We define three classes of conventions. Those that say Imust are mandatory,
-and code will not be accepted (apart from in exceptional circumstances) unless
-it follows these rules. Those that say Ishould are strong guidelines that
-should normally be followed unless there is a sensible reason to do otherwise.
-Finally, those that say Imay, are tentative suggestions to be used at your
-discretion.
-
-Note this particular PDD makes some recommendations that are specific to the C
-programming language. This does not preclude Parrot (or Perl 6) being
-implemented in other languages, but in this case, additional PDDs may need to
-be authored for the extra language-specific features.
-
-=head1 IMPLEMENTATION
-
-=head2 Coding style
-
-The following Imust apply:
+We define three classes of conventions:
=over 4
-=item *
-
-4 column indents for code and 2 column indents for nested CPP #directives. All
-indentation must consist of spaces, no tabs (for ease of patching).
+=item Imust
-There are two exceptions to the CPP indenting- neither PARROT_IN_CORE nor the
-outermost _GUARD #ifdefs cause the level of indenting to increase.
+Items labelled Imust are mandatory; and code will not be accepted (apart
+from in exceptional circumstances) unless it obeys them.
-To ensure that tabs aren't inadvertently used for indentation, the following
-boilerplate code must appear at the bottom of each source file. (This rule may
-be rescinded if I'm ever threatened with a lynching)
+=item Ishould
- /*
-* Local variables:
-* c-indentation-style: bsd
-* c-basic-offset: 4
-* indent-tabs-mode: nil
-* End:
-*
-* vim: expandtab shiftwidth=4:
-*/
+Items labelled Ishould are strong guidelines that should normally be
+followed unless there is a sensible reason to do otherwise.
+=item Imay
-=item *
-
-Any other tabs are assumed to be on an 8-character boundary.
-
-=item *
-
-ANSI C function prototypes
+Items labelled Imay are tentative suggestions to be used at your discretion.
-=item *
+=back
-KR style for indenting control constructs: ie the closing C} should line
-up with the opening Cif etc.
+Note that since Parrot is substantially implemented in C, these rules apply to
+C language source code unless otherwise specified.
-=item *
+=head1 IMPLEMENTATION
-When a conditional spans multiple lines, the opening C{ must line up with the
-Cif or Cwhile, or be at the end-of-line otherwise.
-=item *
+=head2 Language Standards and Portability
-Uncuddled Celses: ie avoid C} else {
+=over 4
=item *
-C-style comments only (C/* comment */). Not all C compilers handle
-C++-style comments.
+C code must generally depend on only those language and library features
+specified by the ISO C89 standard.
-=item *
+In addition, C code may assume that any pointer value can be coerced to an
+integral type (no smaller than typedef CINTVAL in Parrot), then back to its
+original type, without loss.
-Mark places that need to be revisited with XXX (and preferably your initials
-too), and revisit often!
+C code that makes assumptions beyond these must depend on the configuration
+system, either to not compile an entire non-portable source where it will not
+work, or to provide an appropriate #ifdef macro.
-=item *
-
-In function definitions, the name starts in column 0, with the return type on
-the previous line.
+{{ TODO: Enumerate all other non-C89 assumptions that Parrot depends on. }}
=item *
-However, in function declarations (in header files) the return type is kept on
-the same line.
+Perl code must be written for Perl 5.6.1 and all later versions.
-=item *
+Perl code may use features not available in Perl 5.6.1 only if it is not vital
+to Parrot, and if it uses C$^O and C$] to degrade or fail gracefully when
+it is run where the features it depends on are not available.
-Variable names should be included for all function parameters in the function
-declarations. These names should match the parameters in the
#parrotsketch logs: 05SEP06
http://www.parrotcode.org/misc/parrotsketch-logs/ irclog.parrotsketch-200609/irclog.parrotsketch.20060905 -- Will Coke Coleda [EMAIL PROTECTED]
Re: [svn:parrot-pdd] r14416 - in trunk: . docs/pdds
On Tuesday 05 September 2006 10:42, [EMAIL PROTECTED] wrote: *snip* Did you mean the macros PERL_IN_* or PARROT_IN_*? -- c
[perl #40279] [CAGE] C coding standards coda.
# New Ticket Created by Will Coleda # Please include the string: [perl #40279] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40279 From the recently updated pdd07: C source files, and files largely consisting of C (e.g. yacc, lex, PMC, and opcode source files), must end with this block: /* * Local variables: * c-file-style: parrot * End: * vim: expandtab shiftwidth=4: */ -- Will Coke Coleda [EMAIL PROTECTED]
Re: [perl #40279] [CAGE] C coding standards coda.
On 9/5/06, via RT Will Coleda [EMAIL PROTECTED] wrote: From the recently updated pdd07: C source files, and files largely consisting of C (e.g. yacc, lex, PMC, and opcode source files), must end with this block: /* * Local variables: * c-file-style: parrot * End: * vim: expandtab shiftwidth=4: */ added a new test file (t/codingstd/code_coda.t) for these tests. C files are currently tested. i'll do the perl files when i find some tuits, or will gladly accept patches. also needed are patches to get these tests passing. ~jerry
[svn:parrot-pdd] r14432 - in trunk: . docs/pdds
Author: chip
Date: Tue Sep 5 15:00:42 2006
New Revision: 14432
Modified:
trunk/docs/pdds/pdd07_codingstd.pod
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
Log:
Move pdd07 out of clip
Modified: trunk/docs/pdds/pdd07_codingstd.pod
==
--- trunk/docs/pdds/pdd07_codingstd.pod (original)
+++ trunk/docs/pdds/pdd07_codingstd.pod Tue Sep 5 15:00:42 2006
@@ -3,13 +3,9 @@
=head1 NAME
-docs/pdds/pdd07_codingstd.pod - Conventions and Guidelines for Parrot Source
+docs/pdds/pdd07_codingstd.pod - Conventions and Guidelines for Parrot Source
Code
-=head1 VERSION
-
-$Revision$
-
=head1 ABSTRACT
This document describes the various rules, guidelines and advice for those
@@ -23,306 +19,316 @@
conventions, lack of comments in the source code, and so on. We don't intend
to make the same mistake when writing Parrot. Hence this document.
-We define three classes of conventions:
+We define three classes of conventions. Those that say Imust are mandatory,
+and code will not be accepted (apart from in exceptional circumstances) unless
+it follows these rules. Those that say Ishould are strong guidelines that
+should normally be followed unless there is a sensible reason to do otherwise.
+Finally, those that say Imay, are tentative suggestions to be used at your
+discretion.
+
+Note this particular PDD makes some recommendations that are specific to the C
+programming language. This does not preclude Parrot (or Perl 6) being
+implemented in other languages, but in this case, additional PDDs may need to
+be authored for the extra language-specific features.
+
+=head1 IMPLEMENTATION
+
+=head2 Coding style
+
+The following Imust apply:
=over 4
-=item Imust
+=item *
-Items labelled Imust are mandatory; and code will not be accepted (apart
-from in exceptional circumstances) unless it obeys them.
+4 column indents for code and 2 column indents for nested CPP #directives. All
+indentation must consist of spaces, no tabs (for ease of patching).
-=item Ishould
+There are two exceptions to the CPP indenting- neither PARROT_IN_CORE nor the
+outermost _GUARD #ifdefs cause the level of indenting to increase.
-Items labelled Ishould are strong guidelines that should normally be
-followed unless there is a sensible reason to do otherwise.
+To ensure that tabs aren't inadvertently used for indentation, the following
+boilerplate code must appear at the bottom of each source file. (This rule may
+be rescinded if I'm ever threatened with a lynching)
-=item Imay
+ /*
+* Local variables:
+* c-indentation-style: bsd
+* c-basic-offset: 4
+* indent-tabs-mode: nil
+* End:
+*
+* vim: expandtab shiftwidth=4:
+*/
-Items labelled Imay are tentative suggestions to be used at your discretion.
-=back
+=item *
-Note that since Parrot is substantially implemented in C, these rules apply to
-C language source code unless otherwise specified.
+Any other tabs are assumed to be on an 8-character boundary.
-=head1 IMPLEMENTATION
+=item *
+ANSI C function prototypes
-=head2 Language Standards and Portability
+=item *
-=over 4
+KR style for indenting control constructs: ie the closing C} should line
+up with the opening Cif etc.
=item *
-C code must generally depend on only those language and library features
-specified by the ISO C89 standard.
+When a conditional spans multiple lines, the opening C{ must line up with the
+Cif or Cwhile, or be at the end-of-line otherwise.
-In addition, C code may assume that any pointer value can be coerced to an
-integral type (no smaller than typedef CINTVAL in Parrot), then back to its
-original type, without loss.
+=item *
+
+Uncuddled Celses: ie avoid C} else {
-C code that makes assumptions beyond these must depend on the configuration
-system, either to not compile an entire non-portable source where it will not
-work, or to provide an appropriate #ifdef macro.
+=item *
-{{ TODO: Enumerate all other non-C89 assumptions that Parrot depends on. }}
+C-style comments only (C/* comment */). Not all C compilers handle
+C++-style comments.
=item *
-Perl code must be written for Perl 5.6.1 and all later versions.
+Mark places that need to be revisited with XXX (and preferably your initials
+too), and revisit often!
-Perl code may use features not available in Perl 5.6.1 only if it is not vital
-to Parrot, and if it uses C$^O and C$] to degrade or fail gracefully when
-it is run where the features it depends on are not available.
+=item *
-=back
+In function definitions, the name starts in column 0, with the return type on
+the previous line.
+=item *
-=head2 Code Formatting
+However, in function declarations (in header files) the return type is kept on
+the same line.
-The following Imust apply:
+=item *
+
+Variable names should be included for all function parameters in the function
+declarations.
[svn:parrot-pdd] r14435 - in trunk: . docs/pdds
Author: chip
Date: Tue Sep 5 15:01:18 2006
New Revision: 14435
Modified:
trunk/docs/pdds/pdd07_codingstd.pod
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
Log:
About 25% done with update of pdd07.
Modified: trunk/docs/pdds/pdd07_codingstd.pod
==
--- trunk/docs/pdds/pdd07_codingstd.pod (original)
+++ trunk/docs/pdds/pdd07_codingstd.pod Tue Sep 5 15:01:18 2006
@@ -3,9 +3,13 @@
=head1 NAME
-docs/pdds/pdd07_codingstd.pod - Conventions and Guidelines for Parrot Source
+docs/pdds/pdd07_codingstd.pod - Conventions and Guidelines for Parrot Source
Code
+=head1 VERSION
+
+$Revision$
+
=head1 ABSTRACT
This document describes the various rules, guidelines and advice for those
@@ -19,316 +23,306 @@
conventions, lack of comments in the source code, and so on. We don't intend
to make the same mistake when writing Parrot. Hence this document.
-We define three classes of conventions. Those that say Imust are mandatory,
-and code will not be accepted (apart from in exceptional circumstances) unless
-it follows these rules. Those that say Ishould are strong guidelines that
-should normally be followed unless there is a sensible reason to do otherwise.
-Finally, those that say Imay, are tentative suggestions to be used at your
-discretion.
-
-Note this particular PDD makes some recommendations that are specific to the C
-programming language. This does not preclude Parrot (or Perl 6) being
-implemented in other languages, but in this case, additional PDDs may need to
-be authored for the extra language-specific features.
-
-=head1 IMPLEMENTATION
-
-=head2 Coding style
-
-The following Imust apply:
+We define three classes of conventions:
=over 4
-=item *
-
-4 column indents for code and 2 column indents for nested CPP #directives. All
-indentation must consist of spaces, no tabs (for ease of patching).
+=item Imust
-There are two exceptions to the CPP indenting- neither PARROT_IN_CORE nor the
-outermost _GUARD #ifdefs cause the level of indenting to increase.
+Items labelled Imust are mandatory; and code will not be accepted (apart
+from in exceptional circumstances) unless it obeys them.
-To ensure that tabs aren't inadvertently used for indentation, the following
-boilerplate code must appear at the bottom of each source file. (This rule may
-be rescinded if I'm ever threatened with a lynching)
+=item Ishould
- /*
-* Local variables:
-* c-indentation-style: bsd
-* c-basic-offset: 4
-* indent-tabs-mode: nil
-* End:
-*
-* vim: expandtab shiftwidth=4:
-*/
+Items labelled Ishould are strong guidelines that should normally be
+followed unless there is a sensible reason to do otherwise.
+=item Imay
-=item *
-
-Any other tabs are assumed to be on an 8-character boundary.
-
-=item *
-
-ANSI C function prototypes
+Items labelled Imay are tentative suggestions to be used at your discretion.
-=item *
+=back
-KR style for indenting control constructs: ie the closing C} should line
-up with the opening Cif etc.
+Note that since Parrot is substantially implemented in C, these rules apply to
+C language source code unless otherwise specified.
-=item *
+=head1 IMPLEMENTATION
-When a conditional spans multiple lines, the opening C{ must line up with the
-Cif or Cwhile, or be at the end-of-line otherwise.
-=item *
+=head2 Language Standards and Portability
-Uncuddled Celses: ie avoid C} else {
+=over 4
=item *
-C-style comments only (C/* comment */). Not all C compilers handle
-C++-style comments.
+C code must generally depend on only those language and library features
+specified by the ISO C89 standard.
-=item *
+In addition, C code may assume that any pointer value can be coerced to an
+integral type (no smaller than typedef CINTVAL in Parrot), then back to its
+original type, without loss.
-Mark places that need to be revisited with XXX (and preferably your initials
-too), and revisit often!
+C code that makes assumptions beyond these must depend on the configuration
+system, either to not compile an entire non-portable source where it will not
+work, or to provide an appropriate #ifdef macro.
-=item *
-
-In function definitions, the name starts in column 0, with the return type on
-the previous line.
+{{ TODO: Enumerate all other non-C89 assumptions that Parrot depends on. }}
=item *
-However, in function declarations (in header files) the return type is kept on
-the same line.
+Perl code must be written for Perl 5.6.1 and all later versions.
-=item *
+Perl code may use features not available in Perl 5.6.1 only if it is not vital
+to Parrot, and if it uses C$^O and C$] to degrade or fail gracefully when
+it is run where the features it depends on are not available.
-Variable names should be included for all function parameters in the function
-declarations. These names should match the parameters in the
[svn:parrot-pdd] r14436 - in trunk: . docs/pdds editor
Author: chip Date: Tue Sep 5 15:01:35 2006 New Revision: 14436 Modified: trunk/docs/pdds/pdd07_codingstd.pod Changes in other areas also in this revision: Added: trunk/editor/parrot.el (contents, props changed) Modified: trunk/ (props changed) trunk/editor/README.pod Log: Commit initial version of parrot.el, in 'editor' directory as it should be. Update pdd07 and editor/README accordingly. Modified: trunk/docs/pdds/pdd07_codingstd.pod == --- trunk/docs/pdds/pdd07_codingstd.pod (original) +++ trunk/docs/pdds/pdd07_codingstd.pod Tue Sep 5 15:01:35 2006 @@ -276,19 +276,17 @@ =head2 Smart Editor Style Support All developers using Emacs must ensure that their Emacs instances load the -elisp source file Ftools/dev/parrot.el before opening Parrot source files. -This may be done by adding this line to F.emacs: +elisp source file Feditor/parrot.el before opening Parrot source files. +See Leditor/README.pod for instructions. -(load-file /path-to-parrot/tools/dev/parrot.el) - -All source files must end with an editor instruction block: +All source files must end with an editor instruction coda: =over 4 =item * C source files, and files largely consisting of C (e.g. yacc, lex, PMC, and -opcode source files), must end with this block: +opcode source files), must end with this coda: /* * Local variables: @@ -299,7 +297,7 @@ =item * -Perl source files must end with this block: +Perl source files must end with this coda: # Local Variables: # mode: cperl
