FAQ
According to the docs, 'when' performs a smart match on '$_'.

However:

$ perl -wlE '$_ = "bar"; print "foo" when ( "bar" )'
foo
Can't use when() outside a topicalizer at -e line 1.
$

The warning is only issued when the match succeeds:

$ perl -wlE '$_ = "xxx"; print "foo" when ( "bar" )'
$

Apparently, when the match fails, control transfers to the next
statement. When the match succeeds, control wants to transfer to the end
of the given, which is not.

This is Perl 5.14.0 RC1.

-- Johan

Search Discussions

  • Leon Timmermans at May 3, 2011 at 1:37 pm

    On Tue, May 3, 2011 at 3:51 PM, Johan Vromans wrote:
    According to the docs, 'when' performs a smart match on '$_'.

    However:

    $ perl -wlE '$_ = "bar"; print "foo" when ( "bar" )'
    foo
    Can't use when() outside a topicalizer at -e line 1.
    $

    The warning is only issued when the match succeeds:

    $ perl -wlE '$_ = "xxx"; print "foo" when ( "bar" )'
    $

    Apparently, when the match fails, control transfers to the next
    statement. When the match succeeds, control wants to transfer to the end
    of the given, which is not.
    To quote perlsyn: «Every when block is implicitly ended with a break».
    That is exactly the part that makes when useful, without that it would
    be yet another way to write if.

    Leon
  • Johan Vromans at May 4, 2011 at 12:43 pm

    Leon Timmermans writes:

    To quote perlsyn: «Every when block is implicitly ended with a break».
    ... which is not true.

    Topicalizer 'foreach' does not accept a 'break'. The semantics seem to
    indicate that in this case, the 'when' block is implicitly ended with
    'next'.

    Also (from perlsyn):

    "when" executes the statement when $_ smart matches "EXPR", and th en
    either "break"s out if it's enclosed in a "given" scope or skips to the
    "next" element when it lies directly inside a "for" loop.

    In the case of foreach, a 'continue' block is executed.

    -- Johan
  • Tom Christiansen at May 3, 2011 at 1:39 pm
    Johan Vromans wrote
    on Tue, 03 May 2011 14:51:10 +0200:
    According to the docs, 'when' performs a smart match on '$_'.
    However:
    $ perl -wlE '$_ = "bar"; print "foo" when ( "bar" )'
    foo
    Can't use when() outside a topicalizer at -e line 1.
    $
    The warning is only issued when the match succeeds:
    $ perl -wlE '$_ = "xxx"; print "foo" when ( "bar" )'
    $
    Apparently, when the match fails, control transfers to the next
    statement. When the match succeeds, control wants to transfer to the end
    of the given, which is not.
    This is Perl 5.14.0 RC1.
    It works when it's in a foreach (which I find more reliable than
    given as a topicalizer):

    % blead -wlE 'for("xxx") { print "foo" when ( "bar" ) }'

    % blead -wlE 'for("bar") { print "foo" when ( "bar" ) }'
    foo

    --tom
  • Dave Mitchell at May 3, 2011 at 3:24 pm

    On Tue, May 03, 2011 at 02:51:10PM +0200, Johan Vromans wrote:
    According to the docs, 'when' performs a smart match on '$_'.

    However:

    $ perl -wlE '$_ = "bar"; print "foo" when ( "bar" )'
    foo
    Can't use when() outside a topicalizer at -e line 1.
    $

    The warning is only issued when the match succeeds:

    $ perl -wlE '$_ = "xxx"; print "foo" when ( "bar" )'
    $

    Apparently, when the match fails, control transfers to the next
    statement. When the match succeeds, control wants to transfer to the end
    of the given, which is not.

    This is Perl 5.14.0 RC1.
    So what part, if any, of the current behaviour or docs, do you think needs
    changing?

    --
    The Enterprise's efficient long-range scanners detect a temporal vortex
    distortion in good time, allowing it to be safely avoided via a minor
    course correction.
    -- Things That Never Happen in "Star Trek" #21
  • Johan Vromans at May 3, 2011 at 3:12 pm

    Dave Mitchell writes:
    On Tue, May 03, 2011 at 02:51:10PM +0200, Johan Vromans wrote:
    According to the docs, 'when' performs a smart match on '$_'.

    However:

    $ perl -wlE '$_ = "bar"; print "foo" when ( "bar" )'
    foo
    Can't use when() outside a topicalizer at -e line 1.
    $

    The warning is only issued when the match succeeds:

    $ perl -wlE '$_ = "xxx"; print "foo" when ( "bar" )'
    $

    Apparently, when the match fails, control transfers to the next
    statement. When the match succeeds, control wants to transfer to the end
    of the given, which is not.

    This is Perl 5.14.0 RC1.
    So what part, if any, of the current behaviour or docs, do you think needs
    changing?
    If the problem is that 'when' is used outside of a topicalizer (as the
    message suggests), I'd expect a warning in the second example as well.

    If the problem is that the implicit 'break' cannot be executed, I'd
    expect the warning to say just that, e.g.:

    $ perl -wlE 'say "foo" ; break'
    foo
    Can't "break" outside a given block at -e line 1.

    But there's still something strange.

    $ perl -wlE 'given ($_) { say "hi" when undef }'
    hi
    $ perl -wlE 'foreach ($_) { say "hi" when undef }'
    hi

    Implicit break works for given and foreach. But:

    $ perl -wlE 'given ($_) { say "hi"; break }'
    hi
    $ perl -wlE 'foreach ($_) { say "hi"; break }'
    hi
    Can't "break" in a loop topicalizer at -e line 1.

    Explicit break behaves different.

    And, while on the topic:

    $ perl -wle 'continue'
    syntax error at -e line 1, near "continue"
    Execution of -e aborted due to compilation errors.

    $ perl -wle 'break'
    Unquoted string "break" may clash with future reserved word at -e line 1.
    Useless use of a constant (break) in void context at -e line 1.

    (Both keywords are accepted with -E.)

    - Johan
  • Zefram at May 3, 2011 at 4:46 pm

    Johan Vromans wrote:
    If the problem is that 'when' is used outside of a topicalizer (as the
    message suggests), I'd expect a warning in the second example as well.
    It would be much nicer if the warning came at compile time. In principle
    it's quite detectable at compile time whether there's an enclosing
    block of the right type. We don't actually manage the right sort of
    information in the parser yet, because the parser doesn't resolve things
    like which block a "break" refers to. The resolution of the "break"
    is handled entirely dynamically, at runtime, which is where the warning
    currently comes from.

    There's an architectural problem with generating the warning by a
    different mechanism from the actual jump resolution. Perhaps the compiler
    should add a link from each op_break to the corresponding op_given, and
    at runtime pop context frames to the one with the right blk_loop.my_op.
    (Currently it pops context frames to the nearest given or loop, and looks
    at blk_loop.my_op of whatever context it got to.) Such a move towards
    compile-time resolution would make manipulation of control structures
    in op trees more robust.

    -zefram
  • Zsbán Ambrus at May 3, 2011 at 6:39 pm

    On Tue, May 3, 2011 at 6:46 PM, Zefram wrote:
    Johan Vromans wrote:
    If the problem is that 'when' is used outside of a topicalizer (as the
    message suggests), I'd expect a warning in the second example as well.
    It would be much nicer if the warning came at compile time.  In principle
    it's quite detectable at compile time whether there's an enclosing
    block of the right type.
    No, it's not, because the topicalizer block can be in an outer function.

    $ ~/local/perl5.14.0RC1/bin/perl -wE 'sub f { when ("au") { say "gold"
    } when ("ag") { say "silver" } default { say "other" } } for (qw"au ag
    cu ag") { f() } f()'
    gold
    silver
    other
    silver
    other
    Can't use when() outside a topicalizer at -e line 1.
    $

    Ambrus
  • Leon Timmermans at May 3, 2011 at 6:45 pm

    On Tue, May 3, 2011 at 9:38 PM, Zsbán Ambrus wrote:
    No, it's not, because the topicalizer block can be in an outer function.
    Exactly. I can't be the only one who's depending on that. I would be
    fairly pissed if we broke that.

    Leon
  • Tom Christiansen at May 3, 2011 at 6:54 pm
    Leon Timmermans wrote
    on Tue, 03 May 2011 21:45:08 +0300:
    Exactly. I can't be the only one who's depending on that. I would be
    fairly pissed if we broke that.
    How come next/last/redo warn about jumps that rely on
    the dynamic scope, but this doesn't?

    Just curious.

    --tom
  • Leon Timmermans at May 3, 2011 at 8:00 pm

    On Tue, May 3, 2011 at 9:54 PM, Tom Christiansen wrote:
    How come next/last/redo warn about jumps that rely on
    the dynamic scope, but this doesn't?

    Just curious.
    They only do that when not given a label. I have no idea why when
    doesn't do that, but I've come to like it. A lot of design decisions
    around 5.10.0 are mysterious to me.

    Leon
  • Zsbán Ambrus at May 3, 2011 at 8:12 pm

    On Tue, May 3, 2011 at 9:59 PM, Leon Timmermans wrote:
    On Tue, May 3, 2011 at 9:54 PM, Tom Christiansen wrote:
    How come next/last/redo warn about jumps that rely on
    the dynamic scope, but this doesn't?

    Just curious.
    They only do that when not given a label.
    I believe they do that even with a label.

    $ ~/local/perl5.14.0RC1/bin/perl -wE 'sub la { last; } A: { la(); say
    1; } say 2;'
    Exiting subroutine via last at -e line 1.
    2
    $ ~/local/perl5.14.0RC1/bin/perl -wE 'sub la { last A; } A: { la();
    say 1; } say 2;'
    Exiting subroutine via last at -e line 1.
    2
    $

    Ambrus
  • Johan Vromans at May 4, 2011 at 11:35 am

    Johan Vromans writes:

    And, while on the topic:

    $ perl -wle 'continue'
    syntax error at -e line 1, near "continue"
    Execution of -e aborted due to compilation errors.

    $ perl -wle 'break'
    Unquoted string "break" may clash with future reserved word at -e line 1.
    Useless use of a constant (break) in void context at -e line 1.
    Forget I ever mentioned this....

    -- Johan
  • Johan Vromans at May 4, 2011 at 6:47 pm
    Can anyone explain why given and foreach are treated almost but not
    quite similar?

    If this behaviour is intended, where in the docs can I find the
    description?

    -- Johan

    ----snip----
    #!/usr/bin/perl

    use strict;
    use warnings;
    use feature ":5.14";

    my $tag;

    $tag = "given37";
    given ( 37 ) {
    when (36) { say "$tag: $_ ~~ 36" }
    when (37) { say "$tag: $_ ~~ 37" }
    when (38) { say "$tag: $_ ~~ 38" }
    say "$tag: $_ falls through";
    }

    $tag = "given1";
    given ( 1 ) {
    when (36) { say "$tag: $_ ~~ 36" }
    when (37) { say "$tag: $_ ~~ 37" }
    when (38) { say "$tag: $_ ~~ 38" }
    say "$tag: $_ falls through";
    }

    $tag = "foreach37";
    foreach ( 37 ) {
    when (36) { say "$tag: $_ ~~ 36" }
    when (37) { say "$tag: $_ ~~ 37" }
    when (38) { say "$tag: $_ ~~ 38" }
    say "$tag: $_ falls through";
    }

    $tag = "foreach1";
    foreach ( 1 ) {
    when (36) { say "$tag: $_ ~~ 36" }
    when (37) { say "$tag: $_ ~~ 37" }
    when (38) { say "$tag: $_ ~~ 38" }
    say "$tag: $_ falls through";
    }

    sub foo {
    when (36) { say "$tag: $_ ~~ 36" }
    when (37) { say "$tag: $_ ~~ 37" }
    when (38) { say "$tag: $_ ~~ 38" }
    say "$tag: $_ falls through";
    }

    $tag = "given37+sub";
    given ( 37 ) { foo() }
    $tag = "given1+sub";
    given ( 1 ) { foo() }

    $tag = "foreach37+sub";
    foreach ( 37 ) { foo()}
    $tag = "foreach1+sub";
    foreach ( 1 ) { foo() }
    ----snip----
  • Tom Christiansen at May 4, 2011 at 7:04 pm

    Can anyone explain why given and foreach are treated almost but not
    quite similar?
    If this behaviour is intended, where in the docs can I find the
    description?
    Johan,

    I would very much like to know the same thing. Whenever I have
    problems with given -- and I often do, believe me -- if I just
    switch things over to using a foreach, those weird problems
    *always* disappear. And I never know why.

    That seems to suggest that I'm missing something important with what given
    is actually doing. It doesn't match my mental model. The remarks I've
    heard from people who know Perl at least as well and often much better than
    I do, do not inspire confidence in its current implementation.

    I truly wish I understood it better -- so I'd stop doing things with
    it that don't work. :(

    --tom
  • Eric Brine at May 4, 2011 at 7:56 pm

    On Wed, May 4, 2011 at 2:47 PM, Johan Vromans wrote:
    Can anyone explain why given and foreach are treated almost but not
    quite similar?
    Don't know.
    If this behaviour is intended, where in the docs can I find the
    description?
    given assigns to a fresh lexical $_.

    Under "Switch statements" in perlsyn:

    "given(EXPR) will assign the value of EXPR to $_ within the lexical
    scope of the block, so it's similar to do { my $_ = EXPR; ... }"


    foreach aliases to existing $_.

    Under "Foreach Loops" in perlsyn:

    "If VAR is omitted, $_ is set to each value.", immediately followed by
    "If any element of LIST is an lvalue, you can modify it by modifying
    VAR inside the loop."

    - Eric
  • Tom Christiansen at May 5, 2011 at 3:13 am
    Eric Brine wrote
    on Wed, 04 May 2011 15:56:16 EDT:
    If this behaviour is intended, where in the docs can I find
    the description?
    given assigns to a fresh lexical $_.
    Under "Switch statements" in perlsyn:
    "given(EXPR) will assign the value of EXPR to $_ within the lexical
    scope of the block, so it's similar to do { my $_ = EXPR; ... }"
    foreach aliases to existing $_.
    Not always, actually.
    Under "Foreach Loops" in perlsyn:
    "If VAR is omitted, $_ is set to each value.", immediately followed by
    "If any element of LIST is an lvalue, you can modify it by modifying
    VAR inside the loop."
    Ah, but *which* $_?

    If you put a my $_ before a foreach, it will create a new lexical
    for the loop. That will cause Johan's program to behave the same
    with the foreaches and it does with the givens.

    That is, unlike

    for (LIST) { }

    when there is already a lexical by the same name as
    the loop variable, it's different. That makes

    my $_;
    for (LIST) { }

    work the same way that as

    my $x;
    for my $x (LIST) { }

    because now there's a pre-existing lexical in scope
    come the foreach.

    I'm pretty sure that that's has not been at the
    heart of my own given problems. But I can't say
    for sure, because I didn't keep the failure cases.

    Next time I'll try to keep them around.

    --tom
  • Johan Vromans at May 5, 2011 at 6:24 am

    Eric Brine writes:

    Under "Switch statements" in perlsyn:

    "given(EXPR) will assign the value of EXPR to $_ within the lexical
    scope of the block, so it's similar to do { my $_ = EXPR; ... }"

    Under "Foreach Loops" in perlsyn:

    "If VAR is omitted, $_ is set to each value.", immediately followed by
    "If any element of LIST is an lvalue, you can modify it by modifying
    VAR inside the loop."
    This contradicts "Switching in a loop" in perlsyn:

    Instead of using "given()", you can use a "foreach()" loop.

    At least, the way it is described here must be considered incomplete.

    To summarize:

    'given(EXPR)' is like 'for(EXPR)' except
    a. 'given' creates a new topic (lexical $_) while 'for' uses the
    current $_
    b. 'when' blocks, when executed, perform an implicit 'break' in a
    'given' and 'next' in a 'for'.
    c. 'given' takes only a single EXPR, no label, no 'continue' block,
    and its 'when' blocks cannot be put in a subroutine unless you
    explicitly pass the topic to the subroutine.

    So, except for the lexical $_, 'given' does not add any value, it only
    reduces value and adds confusion.

    Since the same can be achieved with 'for my $_ (EXPR)' I suggest
    changing the documentation as follows:

    - 'for' (and 'foreach') are preferred for switch statements using
    'when' blocks.
    - 'given' is just a convenient shorthand for 'for my $_'.

    I might even suggest to deprecate 'given' and 'break', but no doubt that
    will raise the anger of the whole Perl5 and Perl6 communities.

    -- Johan
  • Aristotle Pagaltzis at May 5, 2011 at 1:19 pm

    * Johan Vromans [2011-05-05 08:25]:
    I might even suggest to deprecate 'given' and 'break', but no
    doubt that will raise the anger of the whole Perl5 and Perl6
    communities.
    Not mine. I’ve always felt they are superfluous in Perl 5. The
    5.10.1 smartmatch is useful when used very carefully, and `when`
    is *very* useful for its implicit `next`, but I saw little point
    to `given` and none whatever to `break`. The latter should be
    taken out back and shot as long as it’s young. OTOH `given` did
    grow one useful feature in 5.13.5 (I think): it can return
    a value, so you can write eg.

    my $sep = given ( 0 + @elem ) {
    '' when 0;
    ' and ' when 1;
    default { ',' }
    };

    which you can’t do with `for`. (It would be nice if you could!
    That would make `for` a reverse-order alternative to `map`. Pity
    we can’t really fix that now… since existing code that has subs
    ending with `for` loops may then misbehave.)

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Tom Christiansen at May 5, 2011 at 1:24 pm

    Not mine. I’ve always felt they are superfluous in Perl 5. The
    5.10.1 smartmatch is useful when used very carefully, and `when`
    is *very* useful for its implicit `next`, but I saw little point
    to `given` and none whatever to `break`. The latter should be
    taken out back and shot as long as it’s young. OTOH `given` did
    grow one useful feature in 5.13.5 (I think): it can return
    a value, so you can write eg.

    my $sep = given ( 0 + @elem ) {
    '' when 0;
    ' and ' when 1;
    default { ',' }
    };
    Without a do{} around it? I hadn't realized that.

    --tom
  • Zefram at May 5, 2011 at 1:24 pm

    Aristotle Pagaltzis wrote:
    OTOH `given` did
    grow one useful feature in 5.13.5 (I think): it can return
    a value, so you can write eg.

    my $sep = given ( 0 + @elem ) {
    No, you can't write that. It "returns a value" only in the sense that you
    get something sensible when it's the last statement in a sub or do block.
    You *can* write "my $sep = do { given(...) { ... } };".

    -zefram
  • Aristotle Pagaltzis at May 5, 2011 at 4:18 pm

    * Zefram [2011-05-05 15:25]:
    Aristotle Pagaltzis wrote:
    OTOH `given` did grow one useful feature in 5.13.5 (I think):
    it can return a value, so you can write eg.

    my $sep = given ( 0 + @elem ) {
    No, you can't write that. It "returns a value" only in the
    sense that you get something sensible when it's the last
    statement in a sub or do block. You *can* write "my $sep = do
    { given(...) { ... } };".
    Ah, crud. I misremembered and didn’t have a sufficiently recent
    perl handy to verify.

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Tom Christiansen at May 5, 2011 at 1:25 pm

    OTOH `given` did grow one useful feature in 5.13.5 (I think): a
    value, so you can write eg.
    Yet another thing that needs a version warning guard:

    use 5.13.5; # so given can return a value

    --tom
  • Jan Dubois at May 5, 2011 at 6:10 pm

    On Thu, 05 May 2011, Tom Christiansen wrote:
    OTOH `given` did grow one useful feature in 5.13.5 (I think): a
    value, so you can write eg.
    Yet another thing that needs a version warning guard:

    use 5.13.5; # so given can return a value
    It is not clear to me if you are talking about code, or docs.

    For docs I would prefer if we don't mention development
    releases at all. Use either 5.12.x, or 5.14.x, but not
    5.13.x. Documenting features as being "supported" since
    a particular dev release sends the wrong message about what
    these monthly releases should be used for.

    I've met various Perl *users* who never ever heard about p5p,
    and who still have not grasped that 5.odd.x releases are
    not meant for public consumption.

    Cheers,
    -Jan
  • Tom Christiansen at May 5, 2011 at 6:20 pm
    "Jan Dubois" <jand@activestate.com> wrote
    on Thu, 05 May 2011 11:09:49 PDT:
    OTOH `given` did grow one useful feature in 5.13.5 (I think): a
    value, so you can write eg.
    Yet another thing that needs a version warning guard:

    use 5.13.5; # so given can return a value
    It is not clear to me if you are talking about code, or docs.
    For docs I would prefer if we don't mention development
    releases at all. Use either 5.12.x, or 5.14.x, but not
    5.13.x. Documenting features as being "supported" since
    a particular dev release sends the wrong message about what
    these monthly releases should be used for.
    I *do* see what you mean. Honest. In fact, I even find
    myself agreeing with you that even-numbered releases are
    an advisable way to go when talking about stuff.

    But gee, the nondelta docs do have a lot of odd releases in them:

    perlapi.pod:hash key scalars, or full Copy On Write scalars if 5.9.0 is configured for
    perlapi.pod:In 5.9.3, newSV() replaces the older NEWSV() API, and drops the first
    perlapio.pod:Introduced just after perl5.7.0, this is a re-implementation of the
    perldebguts.pod:compile time and run time. Since Perl 5.9.5, this pragma is lexically
    perlembed.pod:perl 5.7.2 you can specify C<PL_exit_flags |= PERL_EXIT_DESTRUCT_END>
    perldiag.pod:Beginning with perl 5.9.4, you can also use C<state> variables to
    perldiag.pod:perls, has been removed as of 5.9.0 and is no longer supported. In
    perldiag.pod:perls, has been removed as of 5.9.3 and is no longer supported. You
    perldiag.pod:Note that since Perl 5.9.0 a // can also be the I<defined-or>
    perldiag.pod:in Perl 5.9.0 or later that uses the // as the I<defined-or> can be
    perldiag.pod:misparsed by pre-5.9.0 Perls as a non-terminated search pattern.
    perlfaq1.pod:minor release (i.e. perl5.9.x, where 9 is the minor release).
    perlfaq9.pod:in perl5.7.3, can get you the fully qualified domain name (FQDN), the host
    perlfunc.pod:As of Perl 5.9.1, as a form of purely syntactic sugar, you can stack file
    perlfunc.pod:Starting with Perl 5.9.2, integer and floating-point formats, along with
    perlfunc.pod:It is planned to change this behavior in 5.16, but the exact rules
    perlfunc.pod:As of Perl 5.11.2 you can use a bare C<readdir> in a C<while> loop,
    perlfunc.pod:inputs.) In 5.7, the quicksort implementation was replaced with
    perlfunc.pod:Prior to Perl version 5.9.1, the result of using an lvalue multiple times was
    perlfunc.pod:Also, if the specified Perl version is greater than or equal to 5.9.5,
    perlfunc.pod:5.11.0, strictures are enabled lexically as with C<use strict> (except
    perlfunc.pod:Since Perl 5.7.2, if the first two elements of the list are C<undef>,
    perliol.pod:just an abstraction until perl5.7.0. However during that time a number
    perliol.pod:This was the driving need for including the scheme in perl 5.7.0+ - we
    perlipc.pod:Prior to Perl 5.7.3 it was necessary to do as little as you possibly
    perlipc.pod:Before Perl 5.7.3, installing Perl code to deal with signals exposed you to
    perlipc.pod:Perl 5.7.3 and later avoid these problems by "deferring" signals. That is,
    perlipc.pod:The default in Perl 5.7.3 and later is to automatically use
    perlipc.pod:Perl 5.7.3 and later do I<not> use SA_RESTART. Consequently,
    perlipc.pod:L</Deferred Signals (Safe Signals)> above) in Perl 5.7.3 means that
    perlmod.pod:be cloned automatically. Perl after 5.7.2 has support for the C<CLONE>
    perlre.pod:but this option was removed in perl 5.9.)
    perlreapi.pod:As of Perl 5.9.5 there is a new interface for plugging and using other
    perlreguts.pod:In the 5.9.x development version of perl you can C<< use re Debug => 'PARSE' >>
    perlreguts.pod:efforts of Dave Mitchell in the 5.9.x development track, that has changed: now an
    perlsub.pod:Beginning with perl 5.9.4, you can declare variables with the C<state>
    perlsub.pod:example, the following statement dies, as of perl 5.9.0, with an error
    perluniprops.pod:release 5.13. If those change, a deprecation cycle will be done first. These

    So if something says

    perlfunc.pod:As of Perl 5.11.2 you can use a bare C<readdir> in a C<while> loop,

    which I think it does need to, then should that be telling
    people to use

    use 5.11.2;

    or
    use 5.012;

    And why?

    --tom
  • Tom Christiansen at May 5, 2011 at 6:23 pm

    For docs I would prefer if we don't mention development
    releases at all. Use either 5.12.x, or 5.14.x, but not
    5.13.x. Documenting features as being "supported" since
    a particular dev release sends the wrong message about what
    these monthly releases should be used for.
    I *do* see what you mean. Honest. In fact, I even find
    myself agreeing with you that even-numbered releases are
    an advisable way to go when talking about stuff.
    In my own talks, I only ever talk about even-numbered releases:

    5.8
    5.10
    5.12
    5.14
    5.16

    --tom
  • Johan Vromans at May 7, 2011 at 6:45 pm

    Tom Christiansen writes:

    In my own talks, I only ever talk about even-numbered releases:

    5.8
    5.10
    While on the subject...

    What is the preferred way to refer to (e.g.) Perl 5.12.2?

    Perl version 5.12.2
    Perl version 5 release 12.2
    Perl version 5 release 12 patch 2
    Perl revision 5 version 12 subversion 2
    Perl5 revision 5 version 12 subversion 2
    Perl5 version 12.2
    Perl5 release 12.2

    -- Johan
  • Nicholas Clark at May 7, 2011 at 6:56 pm

    On Sat, May 07, 2011 at 08:44:55PM +0200, Johan Vromans wrote:
    Tom Christiansen <tchrist@perl.com> writes:
    In my own talks, I only ever talk about even-numbered releases:

    5.8
    5.10
    While on the subject...

    What is the preferred way to refer to (e.g.) Perl 5.12.2?
    There is no uncontentious answer to this.
    Perl version 5.12.2
    Perl version 5 release 12.2
    Perl version 5 release 12 patch 2
    Perl revision 5 version 12 subversion 2
    Perl5 revision 5 version 12 subversion 2
    Perl5 version 12.2
    Perl5 release 12.2
    I strongly dislike anything that ends up with 12.2 somewhere as you can't do
    this:

    $ perl -le 'require 12.2'
    Perl v12.200.0 required--this is only v5.12.3, stopped at -e line 1.

    or this:

    $ perl -le 'require v12.2'
    Perl v12.2.0 required--this is only v5.12.3, stopped at -e line 1.


    and I see it only leading to confusion having the first period in 5.12.2
    converted to a space, and the second remaining as a period.


    I keep thinking that something *like*

    5.14.0 => Perl 5, version 14
    5.14.1 => Perl 5, version 14, update 1

    would

    upside: avoid the confusion I seek to avoid
    upside: never actually has a ".0" release
    downside: is unwieldy.


    Nicholas Clark
  • David Golden at May 7, 2011 at 7:44 pm

    On Sat, May 7, 2011 at 2:44 PM, Johan Vromans wrote:
    What is the preferred way to refer to (e.g.) Perl 5.12.2?
    My take:

    $ perl -v

    This is perl 5, version 12, subversion 3 (v5.12.3) built for x86_64-linux

    Perl 5 is the language, this is version 12, etc...

    David
  • Tom Christiansen at May 7, 2011 at 7:45 pm
    Perl 5 is the language, this is version 12, etc...
    Not really. Perl is the language.

    --tom
  • Jesse Vincent at May 7, 2011 at 8:25 pm

    Tom Christiansen wrote:

    Perl 5 is the language, this is version 12, etc...
    Not really. Perl is the language.
    Not really.

    Perl is a family of languages. These days _ours_ is called Perl 5. Perl 5 has a kid sister named Perl 6. The two them have the same father, but Perl 6 won't replace or obsolete Perl 5.

    Jesse
    --tom
    --
    Sent from my Android phone with K-9 Mail. Please excuse my brevity.
  • Tom Christiansen at May 7, 2011 at 9:51 pm

    Perl 5 is the language, this is version 12, etc...
    Not really. Perl is the language.
    Not really.
    Perl is a family of languages. These days _ours_ is called Perl 5.
    Perl 5 has a kid sister named Perl 6. The two them have the same
    father, but Perl 6 won't replace or obsolete Perl 5.
    I believe, sir, that this is what one calls revisionist history.
    I recognize that what you attempting this for the best of
    reasons, but I do not buy it.

    I do not have to read perlhist to recall perl's history--
    which is just as well, since that document seems now in
    peril of retroactive revision.

    perl2 was not a different language from perl1. It was never
    intended to be such, nor was there ever the least perception
    that it had somehow become that.

    perl3 was not a different language from perl2, and by the
    transitive property of equality, also not a different language
    from perl1.

    About perl4 the same can be said in relation to the others. It endured for
    more than two years, undergoing during that time subsequent minor revisions
    that spanned the integers from one to third-six. No one in their right
    mind nor any other ever feigned to purport that perl4.036 was a different
    language from perl4 -- nor by virtue of the supercited transitive property,
    a language different from all of its antecessors.

    It is true that perl5 brought many changes, changes that erased
    all lingering doubt that the language was but some sort of awk
    flopping about at a fancy-dress party.

    Since perl4.036 there have been hundreds and hundreds of perl
    releases. This is not "a family of languages". It is one
    language that has evolved through time. Were it otherwise, we
    would call perl5.13.9 a different language from perl5.13.10, a
    proposition I find risible at best and duplicitous at worst.

    Your historical rivisionism attempts to rewrite history in a way
    that negotiates a continued coexistence of the language we call
    perl and the experiment they call perl6. They have chosen a very
    unfortunate name for their experiment. Like Web 2.0, the name
    perl6 is mostly about marketing tricks.

    Make no mistake: perl6 is just as much perl as Java is C. And yet no one
    stopped using C just because Java came into existence. That's because the
    Java people didn't try to piggyback on the "brand" of C, as in some ways
    the C++ people and even the C# indeed both attempted. In none of those
    cases did anyone have the gumption to choose whatever the current release
    number was, grab the next slot, and call their brand-new language that
    thing and of the next release number. It would have caused no end of
    trouble, and have elicited no end of ridicule.

    For good reason.

    I certainly agree that perl6 is at least as much a different language
    from perl5 as Java is a different language from C. I am appalled at
    how messed up things have become. Even people who should know better,
    people whom I explain this all to again and again and again and again,
    will ever a few weeks' time lapse again into the Successionist Heresy.

    They once again start thinking of perl6 succeeding perl5 **NOT** in the way
    that Java has succeeded C, but rather in the way that Windows 98 succeeded
    Windows 95 or the Intel 586 processor succeeded the 386. It is intensely
    aggravating to watch, yet who can blame them? Every technical product
    they're ever used that comes with an ever-increasing numeric suffix is one
    that is meant to be "the next" version, one that will soon supplant that
    old dinosaur.

    This is a miserable situation that we're now quagmired in. It is harmful
    to perl, because it is superlatively misleading. What you are trying to
    do, Jesse, through your revisionist retelling of history, is an
    understandable reaction to an unreasonable situation. I do not agree with
    what you are saying, but I do agree with your goal: to try to fight against
    the nearly unshakable belief that perl6 is to perl5 as Windows 7 is to
    whatever the hell came before it. It's all because of damned marketing
    lies, branding, and false expectations.

    Is "Standard" C a different language from K&R C? Is C89 a different language
    from C90. Yes and no, perhaps -- but *mostly no*. There are all the same
    language from the perspective of FORTRAN and Prolog. It's like pretending
    that British English is somehow a different language from American English:
    anybody who really believes that needs to be dropshipped to Outer Mongolia
    without a guidebook to see what a different language *really* is.

    I will only accept calling perl5 a separate language if it comes affixed with
    the rest of the release numbers, as in "the perl5.13.3 language". Surely
    you will see how silly that seems.

    What you're really trying to do is mop up the fiasco caused by that thing
    they call perl6, a thing *WHICH* *WILL* *NOT* *SUPPLANT* perl5. I do not
    disagree with your goal. I just do not think you will succeed. As long as
    it has the designed-to-deceive name perl6, people will always always always
    get the wrong idea.

    I have an alternate proposal. Let's just call the would-be perl5.16, perl6.

    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

    I mean, **WHY NOT**? At least it wouldn't deceive people anymore. Let the
    perl6 people go find a name that isn't faciley deceitful.

    I don't know how else you're going to fix this problem. The current
    approach is failing terribly. It's time for new ideas.

    Let's add mandatory warnings and a few other things to it, then
    call it perl6. Bingo!! Our problem is solved.

    --tom
  • Ricardo Signes at May 7, 2011 at 10:08 pm
    * Tom Christiansen [2011-05-07T17:51:01]
    This is a miserable situation that we're now quagmired in. It is harmful
    to perl, because it is superlatively misleading. What you are trying to
    do, Jesse, through your revisionist retelling of history, is an
    understandable reaction to an unreasonable situation.
    This is not some unhistory that Jesse has devised as a gimmick to improve
    marketing. It is the way it has been pitched for a few years by many of the
    Perl 6 developers, including Larry Wall. It is incorrect and quite unfair of
    you to try to saddle Jesse with being the author of this current mess.

    --
    rjbs
  • Elizabeth Mattijsen at May 7, 2011 at 10:11 pm

    On May 8, 2011, at 12:08 AM, Ricardo Signes wrote:
    * Tom Christiansen [2011-05-07T17:51:01]
    This is a miserable situation that we're now quagmired in. It is harmful
    to perl, because it is superlatively misleading. What you are trying to
    do, Jesse, through your revisionist retelling of history, is an
    understandable reaction to an unreasonable situation.
    This is not some unhistory that Jesse has devised as a gimmick to improve
    marketing. It is the way it has been pitched for a few years by many of the
    Perl 6 developers, including Larry Wall. It is incorrect and quite unfair of
    you to try to saddle Jesse with being the author of this current mess.
    Ricardo++



    Liz
  • Tom Christiansen at May 7, 2011 at 10:11 pm

    * Tom Christiansen [2011-05-07T17:51:01]
    This is a miserable situation that we're now quagmired in. It is harmful
    to perl, because it is superlatively misleading. What you are trying to
    do, Jesse, through your revisionist retelling of history, is an
    understandable reaction to an unreasonable situation.
    This is not some unhistory that Jesse has devised as a gimmick to improve
    marketing. It is the way it has been pitched for a few years by many of the
    Perl 6 developers, including Larry Wall. It is incorrect and quite unfair of
    you to try to saddle Jesse with being the author of this current mess.
    It would be -- if I were doing that. I absolutely am not.

    He's just trying to make the best of things. So are we all.

    I don't think it flies. I say this after endless explanation to
    coworkers and colleagues, who no matter how many time I explain
    that perl6 doesn't do to perl6 what Windows98 did to Windows95,
    they *always* revert to their prior thinking. Every time.

    It took me nearly two years to convince O'Reilly to do a Camel
    revision, because every couple months they slid back to the old
    heresy that perl5 was moribund because of perl6.

    So long as it keeps that name, it's a mess.

    Hence my wicked subject line. :)

    --tom
  • Aristotle Pagaltzis at May 8, 2011 at 12:36 am

    * Tom Christiansen [2011-05-07 23:55]:
    I believe, sir, that this is what one calls revisionist
    history. I recognize that what you attempting this for the best
    of reasons, but I do not buy it.

    I do not have to read perlhist to recall perl's history --
    which is just as well, since that document seems now in peril
    of retroactive revision.
    Hopefully you need not read it for a reminder that Larry can do
    whatever the hell Larry wants, either.

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • David Golden at May 8, 2011 at 12:42 am

    On Sat, May 7, 2011 at 5:51 PM, Tom Christiansen wrote:
    Perl 5 is the language, this is version 12, etc...
    Not really.  Perl is the language.
    Not really.
    Read patchlevel.h:

    #define PERL_REVISION 5 /* age */
    #define PERL_VERSION 14 /* epoch */
    #define PERL_SUBVERSION 0 /* generation */

    I understand that to mean "5" is the fifth revision of the language.
    Within the fifth revision, "14" is the version and "0" is the
    "subversion".

    Seems pretty straightforward to me.

    -- David
  • Tom Christiansen at May 8, 2011 at 12:44 am
    David Golden wrote
    on Sat, 07 May 2011 20:42:15 EDT:
    Perl 5 is the language, this is version 12, etc...
    Not really. =C2=A0Perl is the language.
    Not really.
    Read patchlevel.h:
    #define PERL_REVISION 5 /* age */
    #define PERL_VERSION 14 /* epoch */
    #define PERL_SUBVERSION 0 /* generation */
    I understand that to mean "5" is the fifth revision of the language.
    Within the fifth revision, "14" is the version and "0" is the
    "subversion".
    Seems pretty straightforward to me.
    Yep.

    --tom
  • Johan Vromans at May 8, 2011 at 6:20 am

    David Golden writes:

    Read patchlevel.h:

    #define PERL_REVISION 5 /* age */
    #define PERL_VERSION 14 /* epoch */
    #define PERL_SUBVERSION 0 /* generation */

    I understand that to mean "5" is the fifth revision of the language.
    Within the fifth revision, "14" is the version and "0" is the
    "subversion".
    So Perl 5.14.0 means Perl5 version 14.0?

    (And now go back in this thread to the articles where this alternative
    was discussed, and rejected.)

    From the user perspective, there are a couple of places where a version
    number is used:

    use version 5.12.3;
    use 5.12.3;
    use feature ":5.12";

    (Note that use [version] allows 5.012003, but use feature does not.)

    Perl -V says:

    perl5 (revision 5 version 12 subversion 3)

    Perl --version says:

    perl 5, version 12, subversion 3 (v5.12.3)

    And $] yields:

    5.012003

    So we can boil this down to:

    Perl5, revision 5 version 12 subversion 3,
    traditionally shortened to "Perl version 5.12.3".
    If a single number is required, use 5.012003, where the version
    and subversion each take 3 decimal places.

    -- Johan
  • Jesse Vincent at May 8, 2011 at 12:54 am

    On Sat 7.May'11 at 15:51:01 -0600, Tom Christiansen wrote:

    I believe, sir, that this is what one calls revisionist history.
    I recognize that what you attempting this for the best of
    reasons, but I do not buy it.
    It's revisionism, but it's not historical revisionism. I agree that
    historically and colloquially, the language gets called Perl. (Though
    it also gets called PERL, perl5, Perl5, p5, perl P.E.R.L., pearl and a
    host of other names even more unfit for publication.)

    What we call the language has been evolving, just as the language
    has been evolving. If Orwant hadn't thrown a bunch of hotel
    coffee mugs around, I might have proposed something different...
    or I might have been lamenting the apparently-painful Python 3
    transition.

    As far as I know, Larry named Perl 6 Perl 6. I haven't heard him
    invoke Rule 2.

    p5p is not the place to debate the merits of Perl 6. Perl 6 isn't
    the same language as Perl 5, but it's still a Perlish language and
    its developers are still part of the Perl community.

    Until Perl 6 came about, the "5" in Perl 5 may well have been a
    version number. If Perl 6 isn't the same language as Perl 5 and
    Perl 5 is to have a life after Perl 6 came into existence, then those
    numbers must be something other than versions of the language.

    My completely unfounded personal belief is that Perl has always been
    the language that's excellent for whatever Larry was doing at the time
    he created it.

    Perls 1-4 were great scripting and automation languages. By the time
    Perl 5 rolled around, Perl had becomme a programming language that was
    great for building software.

    These days, Larry is a language designer. And Perl 6's runtime mutable
    grammer looks like it's going to make Perl 6 an amazing platform
    for designing and building languages.

    The version numbers pretty clearly represent versions of Larry's brain.
    If you ask me to justify the "2", "3" and "4", I'll claim that sysadmins
    just aren't very good at versioning.

    I will only accept calling perl5 a separate language if it comes affixed with
    the rest of the release numbers, as in "the perl5.13.3 language". Surely
    you will see how silly that seems.
    That's your choice, though I think you mean the perl5.013003 language.
    I have an alternate proposal. Let's just call the would-be perl5.16, perl6.
    I'm just going to presume you're joking, though many people have seriously
    proposed that we rename the language (or increment its version). Some say
    "Perl 5 should be called Perl 6." Some say "Perl 5 should be called
    Perl 7." I don't think I've ever actually written out my feelings on
    the matter publicly. It's not going to happen on my watch.

    It's quite possible that most of the planet will continue to call Perl 5
    "Perl" until a 128 bit time_t overflows. I'm ok with that. But the
    language I'm resposible for is more likely to get renamed to "Pumpkin"
    than to have that "5" get incremented.

    Best,
    Jesse
  • Tom Christiansen at May 8, 2011 at 1:06 am

    The version numbers pretty clearly represent versions of Larry's brain.
    If you ask me to justify the "2", "3" and "4", I'll claim that sysadmins
    just aren't very good at versioning.
    Which is *the* whole problem with the number thing.

    It is my belief that when "perl6" appeared, it *was*
    indeed intended to supplant our current perl, but
    that this is no longer the understanding.

    Is that your understanding?

    We are going to be forever fighting (and losing) the
    succession wars because a name chosen to mean exactly
    what such names always meant now no longer means that.

    I don't think any amount of publicity will *ever* change
    that, even if sysadmins "aren't very good at versioning".

    Everyone who isn't reading this will always expect that
    perl6 succeeds perl5. I don't think we will ever shake
    that. I agree that it does no good to argue about it,
    because we aren't going to ever win over minds that
    haven't heard the argument. It's a lost battle.

    --tom
  • Jesse Vincent at May 8, 2011 at 1:20 am

    On Sat, May 07, 2011 at 07:05:45PM -0600, Tom Christiansen wrote:
    It is my belief that when "perl6" appeared, it *was*
    indeed intended to supplant our current perl, but
    that this is no longer the understanding.

    Is that your understanding? Yes.
    Everyone who isn't reading this will always expect that
    perl6 succeeds perl5. I don't think we will ever shake
    that. I agree that it does no good to argue about it,
    because we aren't going to ever win over minds that
    haven't heard the argument. It's a lost battle.
    I'm glad we agree that it's not worth arguing over, though I disagree
    that it's unshakable. I believe that the next step is to make sure that
    Perl 5 has identity that is distinct from the more inclusive "Perl" that
    includes Perl 6, Perl 5 and those other Perls we don't talk about anymore.


    --
  • David Golden at May 8, 2011 at 1:21 am

    On Sat, May 7, 2011 at 9:05 PM, Tom Christiansen wrote:
    It's a lost battle.
    Unless someone(s) convince Larry to choose a different name for Perl 6.

    -- David
  • Konovalov, Vadim (Vadim)** CTR ** at May 8, 2011 at 7:03 pm

    Perl is a family of languages. These days _ours_ is called Perl 5.
    Perl 5 has a kid sister named Perl 6. The two them have the same
    father, but Perl 6 won't replace or obsolete Perl 5.
    It would be just fantastic if this idea will be explained cleanly everywhere,
    so people will not get confused.

    So "perl -v", "perldoc perlrun" "man perl" "www.perl.org" explain that,
    then problem will be no more.

    Otherwise new to perl people will think that by installing perl5 they're
    not installing latest version, but after installing perl6 they will be
    frustrated and go to python.

    From: Tom Christiansen
    I have an alternate proposal. Let's just call the would-be
    perl5.16, perl6.
    Tom++

    I like the idea,
    but it is not realistic,
    so other ideas should be searched.
    I mean, **WHY NOT**? At least it wouldn't deceive people
    anymore. Let the
    perl6 people go find a name that isn't faciley deceitful.
    this last sentence contains an exact answer to "WHY NOT"

    Making perl6 to search another name for perl6 will not happen,
    and insisting on that will do nothing good to anyone.
    I don't know how else you're going to fix this problem. The current
    approach is failing terribly. It's time for new ideas.

    Let's add mandatory warnings and a few other things to it, then
    call it perl6. Bingo!! Our problem is solved.
    unfortunately the name is already occupied.

    maybe steal naming idea from python?
    Python has pypy, CPython, Jython, etc, so perl could have cperl and parrot-perl6

    anyway, even if cperl6 will exist, it should be compatible with parrot-perl6 (that is rakudo)
    and this will not happen, for obvious reasons.

    If "dual" versioning was possible "perl 5.16.0 aka cperl 6.0.0" - like soft link...

    I doubt this will get enough supporters, though.

    Vadim.
  • Alberto Simões at May 8, 2011 at 7:13 pm
    I understand it is too late to rename Perl 6 to other name. But
    unfortunately at the moment the fact of Perl 6 being in the limbo for a
    decade, and seem the natural next version of Perl 5 is doing bad
    marketing to our language.

    Therefore, I agree that:
    - we need to clarify that perl5 and perl6 are different languages;
    - and probably name perl5 v14, perl5 v16, etc.

    Just to cents.
    ambs
    On 08/05/2011 20:02, Konovalov, Vadim (Vadim)** CTR ** wrote:
    Perl is a family of languages. These days _ours_ is called Perl 5.
    Perl 5 has a kid sister named Perl 6. The two them have the same
    father, but Perl 6 won't replace or obsolete Perl 5.
    It would be just fantastic if this idea will be explained cleanly everywhere,
    so people will not get confused.

    So "perl -v", "perldoc perlrun" "man perl" "www.perl.org" explain that,
    then problem will be no more.

    Otherwise new to perl people will think that by installing perl5 they're
    not installing latest version, but after installing perl6 they will be
    frustrated and go to python.

    From: Tom Christiansen
    I have an alternate proposal. Let's just call the would-be
    perl5.16, perl6.
    Tom++

    I like the idea,
    but it is not realistic,
    so other ideas should be searched.
    I mean, **WHY NOT**? At least it wouldn't deceive people
    anymore. Let the
    perl6 people go find a name that isn't faciley deceitful.
    this last sentence contains an exact answer to "WHY NOT"

    Making perl6 to search another name for perl6 will not happen,
    and insisting on that will do nothing good to anyone.
    I don't know how else you're going to fix this problem. The current
    approach is failing terribly. It's time for new ideas.

    Let's add mandatory warnings and a few other things to it, then
    call it perl6. Bingo!! Our problem is solved.
    unfortunately the name is already occupied.

    maybe steal naming idea from python?
    Python has pypy, CPython, Jython, etc, so perl could have cperl and parrot-perl6

    anyway, even if cperl6 will exist, it should be compatible with parrot-perl6 (that is rakudo)
    and this will not happen, for obvious reasons.

    If "dual" versioning was possible "perl 5.16.0 aka cperl 6.0.0" - like soft link...

    I doubt this will get enough supporters, though.

    Vadim.
    --
    Alberto Simoes
    CCTC-UM / CEHUM
  • David Golden at May 9, 2011 at 3:40 am

    2011/5/8 Alberto Simões <albie@alfarrabio.di.uminho.pt>:
    I understand it is too late to rename Perl 6 to other name. But
    unfortunately at the moment the fact of Perl 6 being in the limbo for a
    decade, and seem the natural next version of Perl 5 is doing bad marketing
    to our language.

    Therefore, I agree that:
    - we need to clarify that perl5 and perl6 are different languages;
    - and probably name perl5 v14, perl5 v16, etc.
    Version numbers in Perl 5 are already such a monumental nightmare.
    (e.g. "5.XXXYYY" vs "5.X.Y" vs ":5.X")

    That said, dropping "v5.X.Y" in favor of "v16.X" is somewhat appealing.

    I'm sure it would be a headache somewhere, but maybe just ripping the
    band-aid off is the way to go.

    -- David
  • Marvin Humphrey at May 8, 2011 at 8:27 pm

    On Sun, May 08, 2011 at 09:02:33PM +0200, Konovalov, Vadim (Vadim)** CTR ** wrote:
    From: Tom Christiansen
    I have an alternate proposal. Let's just call the would-be
    perl5.16, perl6.
    Tom++

    I like the idea,
    but it is not realistic,
    so other ideas should be searched.
    Perl7.

    :D

    Marvin Humphrey
  • Jan Dubois at May 5, 2011 at 6:39 pm

    On Thu, 05 May 2011, Tom Christiansen wrote:
    So if something says

    perlfunc.pod:As of Perl 5.11.2 you can use a bare C<readdir> in a C<while> loop,

    which I think it does need to,
    Well, I don't think it should; it should say 5.12.0.

    The only places that should mention 5.odd.x version numbers are the
    perl5${odd}${x}delta.pod files. And those should not even be
    included in the 5.even releases. I remember that we talked about
    dropping those in 5.14, but somehow we forgot to do anything about
    it in time.

    All the parts in perl513xdelta.pod that regular users should care
    about have been copied (and edited) into perl5140delta.pod (and at
    that time should have changed all 5.13.x references to 5.14.0).
    There is no reason to ship those files; they are just intermediate,
    internal artefacts of our development process.

    Non-perldelta.pod style docs should never get any 5.odd references at all.

    All in my humble, but considered opinion, of course. :)

    Cheers,
    -Jan
  • Jesse Vincent at May 5, 2011 at 9:23 pm

    On Thu, May 05, 2011 at 11:38:56AM -0700, Jan Dubois wrote:
    On Thu, 05 May 2011, Tom Christiansen wrote:

    So if something says

    perlfunc.pod:As of Perl 5.11.2 you can use a bare C<readdir> in a C<while> loop,

    which I think it does need to,
    Well, I don't think it should; it should say 5.12.0.
    I don't think that we should be using dev point releases in our
    "durable" documentation, either.

    If nobody presents me with compelling arguments as to why we _should_
    do so, I'll accept a patch to fix it early in the 5.15 series.
  • Tom Christiansen at May 5, 2011 at 9:25 pm
    Jesse Vincent wrote
    on Thu, 05 May 2011 17:23:08 EDT:
    If nobody presents me with compelling arguments as to why we _should_
    do so, I'll accept a patch to fix it early in the 5.15 series.
    It seems dishonest.

    --tom
  • Jesse Vincent at May 5, 2011 at 9:35 pm

    On Thu 5.May'11 at 15:24:38 -0600, Tom Christiansen wrote:
    Jesse Vincent <jesse@fsck.com> wrote
    on Thu, 05 May 2011 17:23:08 EDT:
    If nobody presents me with compelling arguments as to why we _should_
    do so, I'll accept a patch to fix it early in the 5.15 series.
    It seems dishonest.
    How so? We're pretty up front about the fact that blead releases
    shouldn't be run in production and that we disavow them the second
    a new point release comes out.

    They're not supported and intended solely as a vehicle for testing
    and development.

    -jesse
    --tom

Related Discussions

People

Translate

site design / logo © 2018 Grokbase