From mstevens@kronos.imaginet.co.uk

mstevens@​wildcat​:~> cat test.pl
#!/usr/bin/perl

@​array = (1, 2, 3);

map { next if (2 == 2); } @​array;

mstevens@​wildcat​:~> perl test.pl
Can't "next" outside a block at test.pl line 5.
mstevens@​wildcat​:~>

The error generated claims that next is outside a block, but
the documentation below states that next is inside a block. I'm
told that perl 5.005_03 produces the same behaviour but I don't
have a copy available to test.

mstevens@​wildcat​:/usr/local/bin> perldoc -f map
=item map BLOCK LIST

=item map EXPR,LIST

Evaluates the BLOCK or EXPR for each element of LIST (locally setting $_ to each
element) and returns the list value composed of the results of each such
evaluation. Evaluates BLOCK or EXPR in a list context, so each element of LIST
may produce zero, one, or more elements in the returned value.

  @​chars = map(chr, @​nums);

translates a list of numbers to the corresponding characters. And

  %hash = map { getkey($_) => $_ } @​array;

is just a funny way to write

  %hash = ();
  foreach $_ (@​array) {
  $hash{getkey($_)} = $_;
  }

Note that, because $_ is a reference into the list value, it can be used
to modify the elements of the array. While this is useful and
supported, it can cause bizarre results if the LIST is not a named
array. See also L</grep> for an array composed of those items of the
original list for which the BLOCK or EXPR evaluates to true.

Site configuration information for perl 5.00404:

Configured by torin at Wed Feb  3 00:50:04 PST 1999.

Summary of my perl5 (5.0 patchlevel 4 subversion 4) configuration:
  Platform:
    osname=linux, osvers=2.0.36, archname=i386-linux
    uname='linux perv 2.0.36 #2 wed nov 18 03:00:48 pst 1998 i686 unknown '
    hint=recommended, useposix=true, d_sigaction=define
    bincompat3=n useperlio=undef d_sfio=undef
  Compiler:
    cc='cc', optimize='-O2', gccversion=2.7.2.3
    cppflags='-Dbool=char -DHAS_BOOL -D_REENTRANT'
    ccflags ='-Dbool=char -DHAS_BOOL -D_REENTRANT'
    stdchar='char', d_stdstdio=define, usevfork=false
    voidflags=15, castflags=0, d_casti32=define, d_castneg=define
    intsize=4, alignbytes=4, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -lndbm -lgdbm -ldbm -ldb -ldl -lm -lc -lposix -lcrypt
    libc=, so=so
    useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
    cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
	


@INC for perl 5.00404:
	/usr/lib/perl5/i386-linux/5.004
	/usr/lib/perl5
	/usr/local/lib/site_perl/i386-linux
	/usr/local/lib/site_perl
	.


Environment for perl 5.00404:
    HOME=/home/mstevens
    LANG (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/usr/bin:/bin:/usr/bin:/usr/bin/X11:/usr/games:/usr/sbin:/sbin
    PERL_BADLANG (unset)
    SHELL=/usr/bin/zsh

From [Unknown Contact. See original ticket]

The error generated claims that next is outside a block, but
the documentation below states that next is inside a block. I'm
told that perl 5.005_03 produces the same behaviour but I don't
have a copy available to test.

next, last, and redo operate on blocks governed by while loops, for loops,
foreach loops, and singleton loops. That's all. And it's always
been that way.

--tom

From @TimToady

Tom Christiansen writes​:
: >The error generated claims that next is outside a block, but
: >the documentation below states that next is inside a block. I'm
: >told that perl 5.005_03 produces the same behaviour but I don't
: >have a copy available to test.
:
: next, last, and redo operate on blocks governed by while loops, for loops,
: foreach loops, and singleton loops. That's all. And it's always
: been that way.

The error message is misleading. It should say "loop block" rather than
just "block".

Larry

From [Unknown Contact. See original ticket]

On Wed, Nov 24, 1999 at 10​:57​:34AM -0700, Tom Christiansen wrote​:

The error generated claims that next is outside a block, but
the documentation below states that next is inside a block. I'm
told that perl 5.005_03 produces the same behaviour but I don't
have a copy available to test.
next, last, and redo operate on blocks governed by while loops, for loops,
foreach loops, and singleton loops. That's all. And it's always
been that way.

I happily accept "you can't do this".

What I dislike is an error message saying that a particular context is
not a block, and the documentation saying that context _is_ a block.

The two statements are contradictory as given, as far as I can tell.

The phrase 'block' may be an oversimplification, but what I'm bothered
by is that if so, that oversimplification is made, as it leads to
error reports that are at best misleading.

From [Unknown Contact. See original ticket]

On Wed, Nov 24, 1999 at 06​:08​:22PM +0000, Michael Stevens wrote​:

On Wed, Nov 24, 1999 at 10​:57​:34AM -0700, Tom Christiansen wrote​:

The error generated claims that next is outside a block, but
the documentation below states that next is inside a block. I'm
told that perl 5.005_03 produces the same behaviour but I don't
have a copy available to test.
next, last, and redo operate on blocks governed by while loops, for loops,
foreach loops, and singleton loops. That's all. And it's always
been that way.
I happily accept "you can't do this".
What I dislike is an error message saying that a particular context is
not a block, and the documentation saying that context _is_ a block.
The two statements are contradictory as given, as far as I can tell.
The phrase 'block' may be an oversimplification, but what I'm bothered
by is that if so, that oversimplification is made, as it leads to
error reports that are at best misleading.

Reply to my own email but... that's awful english. I mean that, if it
is an oversimplification, I'm bothered that it is made, as it leads to
the misleading error report.

From [Unknown Contact. See original ticket]

The error message is misleading. It should say "loop block" rather than
just "block".

I was thinking of that. Well, to be honest, I considered but discarded
suggesting that it be changed to simply "loop". The problem is that
people often use the words "loop" and "block", whether in conjunction
or separately, to indicate things that the cited four-letter words
don't affect. Many such examples spring easily to mind, such as do
loops, postfix foreaches, and if blocks. I am concerned for the people
already reading things into those words that aren't applicable, and
remain reluctant to place my faith in believe that your suggested fit
would necessarily ameliorate the confusion. But it may be better
than what we have. And there might be no feasible programmatic fix to
continued user error and occasional misunderstanding.

--tom

From @TimToady

Tom Christiansen writes​:
: >The error message is misleading. It should say "loop block" rather than
: >just "block".
:
: I was thinking of that. Well, to be honest, I considered but discarded
: suggesting that it be changed to simply "loop". The problem is that
: people often use the words "loop" and "block", whether in conjunction
: or separately, to indicate things that the cited four-letter words
: don't affect. Many such examples spring easily to mind, such as do
: loops, postfix foreaches, and if blocks. I am concerned for the people
: already reading things into those words that aren't applicable, and
: remain reluctant to place my faith in believe that your suggested fit
: would necessarily ameliorate the confusion. But it may be better
: than what we have. And there might be no feasible programmatic fix to
: continued user error and occasional misunderstanding.

None of the things you mention are loop blocks. Do loops come the closest,
but the block belongs to the do, not the loop. Admittedly, the existence
of the block is part of what triggers the do-once semantics of the loop.

Larry

From [Unknown Contact. See original ticket]

None of the things you mention are loop blocks.

I would not say they are, but then again, I happen to know what's
always worked there, and base my understanding on that experience.
People really do get tripped up by the subtleties here. I can't know
what everyone in the world is thinking, or would think. So limiting
the domain to the bug report submitted, if your change to "loop block"
would mean that Michael Stevens would stop expecting the block that grep
or map loops across to be affected by next/last/redo, then that's better
then changing to that wording would be better than leaving it as is.
I don't know that we'll ever be able to explain the do{}while issue
except from a low-level point of view that will lose most of the audience.

--tom

From [Unknown Contact. See original ticket]

If I send out one more message that fails to parse today, I'm going to
cancel the AI experiment. :-(

--tom

From [Unknown Contact. See original ticket]

Larry Wall writes​:

: >The error generated claims that next is outside a block, but
: >the documentation below states that next is inside a block. I'm
: >told that perl 5.005_03 produces the same behaviour but I don't
: >have a copy available to test.
:
: next, last, and redo operate on blocks governed by while loops, for loops,
: foreach loops, and singleton loops. That's all. And it's always
: been that way.

The error message is misleading. It should say "loop block" rather than
just "block".

Another thing which confuses a lot is "when an operator expected".
Should not we improve it as "when a binary/postfix operator expected",
or

  only a binary- or a postfix-operator makes sense here

or something similar?

Ilya

From The RT System itself

closed​: (at least) perl-current @​7385 contains Larry's requested fix.