As soon as you do colored error messages, you'll get complaints from people on *nix systems that haven't been updated in 15 years about the weird output.

Perhaps make it an option when you compile perl?

----
send money to your kernel via the boot loader.. This and more wisdom available from Markov Hardburn.

Perhaps make it an option when you compile perl?

No, because on *nix, the sysadmin then has the unenviable position of annoying half of the people. And if you've ever been the sysadmin for a thousand users, someone will complain that the system wide time is off by 0.03 nanoseconds, never mind that Perl is giving them wonky characters in the error messages.

Make it an environment option, or a command line option. And make it off by default.

-QM
--
Quantum Mechanics: The dreams stuff is made of

Go on, write a module that gives you colored error messages by setting $SIG{__DIE__} and $SIG{__WARN__}. Just don't make it default.

You're all missing the point. My comment had almost nothing to do with a desire for colored error messages, and almost everything to do with designing a language compiler that won't confuse people by default, however that is to be accomplished. The basic underlying problem is that the messages are prioritized in a deceptive manner. An optional module does nothing to fix that.

When you get a slew of errors and warnings all mixed together, you can reduce the clutter by disabling the warnings on the command line using -X option:

P:\test>type junk.pl
#! perl -slw
use strict;

my( $a, @b, %c );

if 1 ) {
        my( $a, @b, %c );
}

P:\test>perl -c junk.pl
"my" variable $a masks earlier declaration in same scope at junk.pl li
+ne 8.
"my" variable @b masks earlier declaration in same scope at junk.pl li
+ne 8.
"my" variable %c masks earlier declaration in same scope at junk.pl li
+ne 8.
syntax error at junk.pl line 7, near "if 1"
junk.pl had compilation errors.

P:\test>perl -Xc junk.pl
syntax error at junk.pl line 7, near "if 1"
junk.pl had compilation errors.
[download]

This even seems to disable use warnings which is nice.

so I went looking for missing }s and )s, as this is one of my frequent failings

My way of solving this is to write out:

if( condition ) {
}
[download]

And then go back and fill in the block. I almost never miss a curly. I tend to be lazier about doing the same with parens, since those are usually much shorter (and likewise tend to get bitten by unbalnced parens more often).

My way of solving this is to write out:

if( condition ) {
}
[download]

Yes, that's helpful. However, I often have more complicated conditions, such as:

if ( ( $flag1 or $flag2 )
 and ( length( $string ) )
[download]

[Note the missing ')']

and that was the case this time as well.

-QM
--
Quantum Mechanics: The dreams stuff is made of

if ( ( $flag1 or $flag2 )
 and ( length( $string ) )
[download]

This is where lining up your delimiters makes a lot of sense. Had you lined up the interior parens, giving

if ( ( $flag1 or $flag2  )
 and ( length( $string ) )
[download]

the unbalanced leading paren would be a bit more obvious; in fact,

if ( ( $flag1 or $flag2  ) and
     ( length( $string ) )
[download]

might be even better: the if's leading paren isn't "masked" by the and.

In this case, though, I'd be sorely tempted to break the if's condition out into a small sub with a meaningful name. I think

if ( &condition( $flag1, $flag2, $string ) )
[download]

is plenty readable, and gives you less punctuation to worry about.

--
F o x t r o t U n i f o r m
Found a typo in this node? /msg me
% man 3 strfry

That can still be helped by better formatting rules. The way I write complex conditionals that would be too long to fit on one line is to treat the parens like curlies and line them up the same way, indenting the content.

See what your mistake would look like then:

if(
    ( $flag1 or $flag2 )
    and ( length( $string )
) {
    # ...
}
[download]

It still isn't perfectly obvious, but it's much easier to see now.

It also helps to have an editor that will match brackets/parens/curlies for you; go through your delimiters one by one and check that there is a matching one where you expect it.

Makeshifts last the longest.

I'd like to see an example of the error such that Perl complains about multiple "my" declarations when there was only one.

This code:

#!/your/perl/here

use strict;
use warnings;

if (( 1) # missing closing paren
{
    my $x;
    ($x) = 'abc' =~ /(b)/;
    $x++;
}
[download]

generates these errors:

C:\Perl\perl>perl -c syntax_error2.pl
"my" variable $x masks earlier declaration in same scope at syntax_err
+or2.pl line 9.
"my" variable $x masks earlier declaration in same scope at syntax_err
+or2.pl line 10.
syntax error at syntax_error2.pl line 7, near ") # missing closing par
+en
{"
syntax error at syntax_error2.pl line 11, near "}"
syntax_error2.pl had compilation errors.
[download]

In the real code, several variables (which had been declared outside of the if block) were referenced, and were reported as "masking".

-QM
--
Quantum Mechanics: The dreams stuff is made of

Thats why I like my IDE (Apple's Project Builder), it *bonks* at me whenever I add to many or two few parens/brackets (open or close).

You must have very forgiving neighbors. I would tend to bonk you every time your IDE bonked you. :p

-QM
--
Quantum Mechanics: The dreams stuff is made of

You must have very forgiving neighbors. I would tend to bonk you every time your IDE bonked you.

With all that bonking going on "friendly" might be a better term than "forgiving" :)

-In Australia at least "bonking" is a euphemism for... another human activity *grin*

--
Do not seek to follow in the footsteps of the wise. Seek what they sought. -Basho

However, no one seems to have added their own anecdotes:

I thought this would be a good place to gather similar examples of awkward or dense compile errors from everyone here.

Calling all honest coders: Please regale us with your darkest compiler error conundrums, stricture miseries, and "WTF?" moments!

After all, the world loves a good story :)