=item Bareword "%s" not allowed while "strict subs" in use
(F) With "strict subs" in use, a bareword is only allowed as a
-subroutine identifier, in curly braces or to the left of the "=>" symbol.
+subroutine identifier, in curly brackets or to the left of the "=>" symbol.
Perhaps you need to predeclare a subroutine?
=item Bareword "%s" refers to nonexistent package
(S) This is an educated guess made in conjunction with the message "%s
found where operator expected". Often the missing operator is a comma.
-=item Missing right bracket
+=item Missing right curly or square bracket
-(F) The lexer counted more opening curly brackets (braces) than closing ones.
-As a general rule, you'll find it's missing near the place you were last
-editing.
+(F) The lexer counted more opening curly or square brackets than
+closing ones. As a general rule, you'll find it's missing near the place
+you were last editing.
=item Modification of a read-only value attempted
expressions. If you're a vi user, the % key is valuable for finding
the matching parenthesis. See L<perlre>.
-=item Unmatched right bracket
+=item Unmatched right %s bracket
-(F) The lexer counted more closing curly brackets (braces) than opening
-ones, so you're probably missing an opening bracket. As a general
-rule, you'll find the missing one (so to speak) near the place you were
-last editing.
+(F) The lexer counted more closing curly or square brackets than
+opening ones, so you're probably missing a matching opening bracket.
+As a general rule, you'll find the missing one (so to speak) near the
+place you were last editing.
=item unmatched [] in regexp
=item *
-In B<USE RULE 1>, you can omit the curly braces whenever the thing
+In B<USE RULE 1>, you can omit the curly brackets whenever the thing
inside them is an atomic scalar variable like C<$aref>. For example,
C<@$aref> is the same as C<@{$aref}>, and C<$$aref[1]> is the same as
C<${$aref}[1]>. If you're just starting out, you may want to adopt
-the habit of always including the curly braces.
+the habit of always including the curly brackets.
=item *
useful.
Regarding aesthetics of code lay out, about the only thing Larry
-cares strongly about is that the closing curly brace of
+cares strongly about is that the closing curly bracket of
a multi-line BLOCK should line up with the keyword that started the construct.
Beyond that, he has other preferences that aren't so strong:
########
/(?{"{"}})/ # Check it outside of eval too
EXPECT
-Unmatched right bracket at (re_eval 1) line 1, at end of line
+Unmatched right curly bracket at (re_eval 1) line 1, at end of line
syntax error at (re_eval 1) line 1, near ""{"}"
Compilation failed in regexp at - line 1.
########
a(?{}})b - c - /a(?{}})b/: Sequence (?{...}) not terminated or not {}-balanced
a(?{"{"})b - c - /a(?{"{"})b/: Sequence (?{...}) not terminated or not {}-balanced
a(?{"\{"})b cabd y $& ab
-a(?{"{"}})b - c - Unmatched right bracket
+a(?{"{"}})b - c - Unmatched right curly bracket
a(?{$bl="\{"}).b caxbd y $bl {
x(~~)*(?:(?:F)?)? x~~ y - -
^a(?#xxx){3}c aaac y $& aaac
PL_last_uni = 0;
PL_last_lop = 0;
if (PL_lex_brackets)
- yyerror("Missing right bracket");
+ yyerror("Missing right curly or square bracket");
TOKEN(0);
}
if (s++ < PL_bufend)
case ']':
s++;
if (PL_lex_brackets <= 0)
- yyerror("Unmatched right bracket");
+ yyerror("Unmatched right square bracket");
else
--PL_lex_brackets;
if (PL_lex_state == LEX_INTERPNORMAL) {
rightbracket:
s++;
if (PL_lex_brackets <= 0)
- yyerror("Unmatched right bracket");
+ yyerror("Unmatched right curly bracket");
else
PL_expect = (expectation)PL_lex_brackstack[--PL_lex_brackets];
if (PL_lex_brackets < PL_lex_formbrack)