John Porter writes:
: Michael Mathews wrote:
: > how shall I, as an RFC > Maintainer determine what that status is?
: >
: > Personally I don't want anything to do with judging the "status" of this
: > RFC, beyond my one voice. I do accept responsibility for compiling some
: > organized record of the responses I've received, but who shall decide
: > (before Larry decides)?
:
: You have to determine the status, but that shouldn't be scary,
: considering these RFCs are ultimately just recommendations for
: Larry's consideration. Since the broad concensus seems to have
: been that inline comments might be very useful, and not breaking
: anything else, the status could be "Good".
As long as everyone realizes that I might reject a good many "Good"
things merely because if I accepted them all, Perl would become twice
as complicated as it is. Note in particular that multi-line comments
are something we *could* have added at any time, but chose not to.
This means you're gonna have to argue a little harder for it than you
would for something that wasn't possible before, but that we think
might become possible with the redesign.
As I see it, given the proclivities of design-by-committee, my main job
at this point is to prevent feature bloat. There are various prongs to
this strategy. The obvious ones include culling "bad" features from
Perl 5, and limiting the introduction of marginal features into Perl 6.
A less obvious strategy is to try to see where various marginal
features could be subsumed under some more powerful feature. To some
extent, you see this with the ability to use pod for multiline
comments. For embedded comments, we might rather see some kind of
macro facility that could turn qc// or any other quoted form into a
list of zero or more tokens.
Larry
