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

pos++ #14232

Closed
p5pRT opened this issue Nov 11, 2014 · 6 comments
Closed

pos++ #14232

p5pRT opened this issue Nov 11, 2014 · 6 comments

Comments

@p5pRT
Copy link

p5pRT commented Nov 11, 2014

Migrated from rt.perl.org#123184 (status was 'rejected')

Searchable as RT123184$

@p5pRT
Copy link
Author

p5pRT commented Nov 11, 2014

From @cpansprout

Yes, I actually tried to do pos++ recently, and quickly realised why it didn’t work.

But ‘pos++;’ could only mean one thing, so why shouldn’t perl do that?

Making this work for the unambiguous cases that are currently syntax errors is not that hard, and I can make it generic enough to work with custom lvalue subs, too.

The only drawback I can think of is that, while the first line here will work, the second will not, since it is not sufficiently unambiguous​:

  pos++;
  pos++ if $necessary;

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Nov 11, 2014

From @cpansprout

On Tue Nov 11 14​:01​:11 2014, sprout wrote​:

Yes, I actually tried to do pos++ recently, and quickly realised why
it didn’t work.

But ‘pos++;’ could only mean one thing, so why shouldn’t perl do that?

Making this work for the unambiguous cases that are currently syntax
errors is not that hard, and I can make it generic enough to work with
custom lvalue subs, too.

The only drawback I can think of is that, while the first line here
will work, the second will not, since it is not sufficiently
unambiguous​:

pos++;
pos++ if $necessary;

In case it’s not clear, the reason pos++ fails is that the lexer is expecting an expression after ‘pos’ and treats ++ as a preincrement where an expression is expected.

This is how I would solve it​: If ++ is followed by a terminator of some sort (closing bracket, semicolon) or an unambiguous infix operator (e.g., &&), then it can’t possibly be a preincrement, but it *might* be a postincrement. So tell the parser it is a postincrement, resulting in either a syntax error (as before) or something meaningful.

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Nov 11, 2014

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

@p5pRT
Copy link
Author

p5pRT commented Aug 11, 2016

From @cpansprout

On Tue Nov 11 14​:01​:11 2014, sprout wrote​:

The only drawback I can think of is that, while the first line here
will work, the second will not, since it is not sufficiently
unambiguous​:

pos++;
pos++ if $necessary;

And I think it would cause more confusion that the construct is allowed until you stick ‘if’ after it. So I am rejecting this ticket.

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Aug 11, 2016

From [Unknown Contact. See original ticket]

On Tue Nov 11 14​:01​:11 2014, sprout wrote​:

The only drawback I can think of is that, while the first line here
will work, the second will not, since it is not sufficiently
unambiguous​:

pos++;
pos++ if $necessary;

And I think it would cause more confusion that the construct is allowed until you stick ‘if’ after it. So I am rejecting this ticket.

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Aug 11, 2016

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

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