Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

each($scalar) error message anomalies #15291

Closed
p5pRT opened this issue Apr 23, 2016 · 5 comments
Closed

each($scalar) error message anomalies #15291

p5pRT opened this issue Apr 23, 2016 · 5 comments

Comments

@p5pRT
Copy link

p5pRT commented Apr 23, 2016

Migrated from rt.perl.org#127976 (status was 'resolved')

Searchable as RT127976$

@p5pRT
Copy link
Author

p5pRT commented Apr 23, 2016

From @cpansprout

In these examples, 5.12.4 represents perl before the each $scalar feature. 5.14.4 includes the feature. ./perl is 5.24-to-be, in which the feature has been removed.

$ perl5.12.4 -e 'print each 1'
Type of arg 1 to each must be hash or array (not constant item) at -e line 1, at EOF
Execution of -e aborted due to compilation errors.
$ perl5.14.4 -e 'print each 1'
Type of arg 1 to each must be hash (not constant item) at -e line 1, at EOF
Execution of -e aborted due to compilation errors.
$ ./perl -e 'print each 1'
Type of arg 1 to each must be hash (not constant item) at -e line 1, at EOF
Execution of -e aborted due to compilation errors.

Notice how the last two error messages are wrong. The last one is wrong because arrays are also accepted.

$ perl5.12.4 -e 'print each $1'
Type of arg 1 to each must be hash or array (not scalar dereference) at -e line 1, at EOF
Execution of -e aborted due to compilation errors.
$ perl5.14.4 -e 'print each $1'
Type of argument to each on reference must be unblessed hashref or arrayref at -e line 1.
$ ./perl -e 'print each $1'
Experimental each on scalar is now forbidden at -e line 1.

This last message is correct, but differs from the constant case.

This may not be a problem (it is, after all, just an error message; not something encountered much in working code), but it does make testing a little inconvenient.

The ‘hash (not constant item)’ should really be fixed, though. Should it be changed to the old ‘hash or array’, or should it change to match the ‘Experimental forbidden’ message? (Take note that each(1) was never permitted.)

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Apr 24, 2016

From @cpansprout

On Sat Apr 23 14​:27​:58 2016, sprout wrote​:

In these examples, 5.12.4 represents perl before the each $scalar
feature. 5.14.4 includes the feature. ./perl is 5.24-to-be, in which
the feature has been removed.

$ perl5.12.4 -e 'print each 1'
Type of arg 1 to each must be hash or array (not constant item) at -e
line 1, at EOF
Execution of -e aborted due to compilation errors.
$ perl5.14.4 -e 'print each 1'
Type of arg 1 to each must be hash (not constant item) at -e line 1,
at EOF
Execution of -e aborted due to compilation errors.
$ ./perl -e 'print each 1'
Type of arg 1 to each must be hash (not constant item) at -e line 1,
at EOF
Execution of -e aborted due to compilation errors.

Notice how the last two error messages are wrong. The last one is
wrong because arrays are also accepted.

$ perl5.12.4 -e 'print each $1'
Type of arg 1 to each must be hash or array (not scalar dereference)
at -e line 1, at EOF
Execution of -e aborted due to compilation errors.
$ perl5.14.4 -e 'print each $1'
Type of argument to each on reference must be unblessed hashref or
arrayref at -e line 1.
$ ./perl -e 'print each $1'
Experimental each on scalar is now forbidden at -e line 1.

This last message is correct, but differs from the constant case.

This may not be a problem (it is, after all, just an error message;
not something encountered much in working code), but it does make
testing a little inconvenient.

The ‘hash (not constant item)’ should really be fixed, though. Should
it be changed to the old ‘hash or array’, or should it change to match
the ‘Experimental forbidden’ message? (Take note that each(1) was
never permitted.)

I now think the old message is best in this case.

Also, since some syntax errors produce multiple error messages, for the ‘Experimental forbidden’ case I suggest we give two messages, since it will be more helpful, like this​:

$ perl -e 'print each $1'
Experimental each on scalar is now forbidden at -e line 1, at EOF
Type of arg 1 to each must be hash or array (not scalar dereference) at -e line 1, at EOF
Execution of -e aborted due to compilation errors.

I hope to push patches after 5.24 if nobody objects.

(Note also that I have discovered since by previous post that the hash functions use croak, whereas the array functions use yyerror. I propose making the hash functions also use yyerror, which allows for multiple messages and provides more diagnostic information, such as ‘at EOF’, ‘near blah blah blah’, etc.)

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Apr 24, 2016

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented May 17, 2016

From @cpansprout

On Sun Apr 24 14​:47​:40 2016, sprout wrote​:

I now think the old message is best in this case.

Also, since some syntax errors produce multiple error messages, for
the ‘Experimental forbidden’ case I suggest we give two messages,
since it will be more helpful, like this​:

$ perl -e 'print each $1'
Experimental each on scalar is now forbidden at -e line 1, at EOF
Type of arg 1 to each must be hash or array (not scalar dereference)
at -e line 1, at EOF
Execution of -e aborted due to compilation errors.

I hope to push patches after 5.24 if nobody objects.

(Note also that I have discovered since by previous post that the hash
functions use croak, whereas the array functions use yyerror. I
propose making the hash functions also use yyerror, which allows for
multiple messages and provides more diagnostic information, such as
‘at EOF’, ‘near blah blah blah’, etc.)

I have pushed 69e7f50 and dc26b61 to address these issues.

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented May 17, 2016

@cpansprout - Status changed from 'open' to 'resolved'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant