perl5
perl5 copied to clipboard
Perl
Say 'syntax error near "$"', not the following statement
$ cat $i.pl
for ( 0 .. $ ) {
#ho hum
if ( $_ % $n[0] || $_ % $n[1] ) { next; }
push @o, $_;
}
$ perl -c i.pl
syntax error at i.pl line 4, near "if"
i.pl had compilation errors.
Better would be
syntax error at i.pl line 1, near "$"
Else the user spends over five minutes trying to debug
if ( $_ % $n[0] || $_ % $n[1] ) { next; }
(True story. In fact the earlier message was
syntax error ... near "next if", causing me to
see if changing next if ... to if () {next}
would help.
What I am trying to say is this time the wild goose chase was so long that I should have brought sandwiches.) perl/5.38.2
Until the if, the syntax is still valid. $ ) { is the start of accessing an element of the %) variable. For example:
$ perl -ce'
for ( 0 .. $ ) {
#ho hum
4 } ) {
push @o, $_;
}'
-e syntax OK
So reporting the syntax error as the $ isn't really correct.
Well OK, but if it doesn't find what it was looking for, all the way to the end of the file even, then perhaps it should also mention the other case, that the user has simply forgotten something right after the $.
On Mon, Feb 26, 2024 at 09:50:29PM -0800, 積丹尼 Dan Jacobson wrote:
Well OK, but if it doesn't find what it was looking for, all the way to the end of the file even, then perhaps it should also mention the other case, that the user has simply forgotten something right after the $.
In general that sort of thing is hard. The parser has to kind of guess what you actually meant, then go back and try to work out where the problem started.
-- "Foul and greedy Dwarf - you have eaten the last candle." -- "Hordes of the Things", BBC Radio.
The parser has to kind of guess what you actually meant, then go back and try to work out where the problem started.
Whether I shall turn out to be the hero of my own life, or whether that station will be held by anybody else, these pages must show. To begin my life with the beginning of my life, I record that I was born...
Maybe instead of guessing the wrong one sometimes, the parser could just mention both possibilities...
I think you are still underestimating the complexity. If the parser took the time to figure out every possible thing your incorrect syntax was meant to be, the error checking routine would be incredibly complex and would result in errors with easily 10 possibilities...
Well okay then. Yes I do not think we should haul in the AI. But still, the parser could say there is a problem between two points, instead of just mentioning one of the points.
In other words problem between a and b, instead of problem before b, or problem after a, or problem around b, or problem around a.
Hmm. A lot of perls errors are +/- a line. Usually -.
Maybe the parser could explain what it thought it was parsing at the time would help ... ... while parsing a key for %) starting at $i.pl line 1
On Wed, Feb 28, 2024 at 02:15:35AM -0800, 積丹尼 Dan Jacobson wrote:
Well okay then. Yes I do not think we should haul in the AI. But still, the parser could say there is a problem between two points, instead of just mentioning one of the points.
In other words problem between a and b, instead of problem before b, or problem after a, or problem around b, or problem around a.
I think the thing you're missing is that that parser has no way of knowing that the problem is at point a, or that the point where the programmer went wrong is somewhere between and b. It only knows that something went wrong near b.
Lets look at your original example, stripped down a bit:
for ( 0 .. $ ) {
if (1) { 1; }
}
where the parser complains: '"syntax error .... near "if"'. In that example, the real error is the missing variable name on the preceding line. But consider this legal code:
my $name = $interface_names{$if+1};
Now consider a typo:
my $name = $interface_names{if+1};
The error here is clearly the missing sigil on the if. But that example is no different from
my $name = $){$if+1};
which is syntactically correct, because because perl allows hashes that have punctuation names. So there is no real way for the parser to know that the error is a missing sigil on $if,
Or to put it another way, the parser stops and reports an error at the point where the input stops being syntactically correct. It is then up to an intelligent coder, and not for a dumb parser, to be able to work backwards and find the point in the code which is, although syntactically correct, not what the programmer intended.
-- Overhead, without any fuss, the stars were going out. -- Arthur C Clarke
On Wed, Feb 28, 2024 at 03:47:30AM -0800, guest20 wrote:
Maybe the parser could explain what it thought it was parsing at the time would help ...
... while parsing a key for %) starting at $i.pl line 1
But the parser is parsing a lot of things at that point. It is parsing a file, a sub, a statement, a for loop, a for loop range value, a hash expression, a hash key, an expression, etc.
The parser has no way of knowing which if those is the significant one. So it would have to dump the whole lot. Which would make errors many-line, mostly full of irrelevant noise.
-- Never do today what you can put off till tomorrow.
I guess now we see the price for allowing $" $\ etc. in the language...
Must have seemed real cool at the time.
Too late to change now.
OK, feel free to close this report.
@iabyn it is parsing all those things, that's true.
maybe including that whole stack in the error could be too verbose... or too costly to implement
IMO the real problem here is that we allow whitespace where it doesn't make much sense.
IMO the real problem here is that we allow whitespace where it doesn't make much sense.
Whitespace use is one of the virtues in perl5. I know quite a bunch of people that have used liberal whitespace in interesting ways to express their way of thinking. What is logical to them (including me in them there) might be a complete mystery to others.
I personally would not write $h {key}, but it is allowed. I will always write foo ($arg) instead of foo($arg) or even worse foo( $arg ), but the fact that we can and that there are as many people that do makes the language rich and useful. Even if it does not make sense to some.
