Project

General

Profile

Actions

Bug #10388

closed

Operator precedence problem in multiple assignment (massign)

Added by knu (Akinori MUSHA) about 10 years ago. Updated almost 5 years ago.

Status:
Rejected
Target version:
-
ruby -v:
ruby 2.2.0dev (2014-10-13 trunk 47904) [x86_64-freebsd10]
[ruby-core:65714]

Description

I understand it wouldn't be easy to fix this, but since I happened to find it here it goes.

  • a, b = c = 1, 2 is currently taken as a, b = (c = 1), 2; I'd expect it to be taken as a, b = (c = 1, 2).

  • a, b = *c = 1, 2 is currently taken as a, b = *(c = 1), 2; I'd expect it to be taken as a, b = *(c = 1, 2) or even a, b = (*c = 1, 2).

  • a, b = c, d = 1, 2 is currently taken as a, b = (c), (d = 1), 2; I'd expect it to be taken as a, b = (c, d = 1, 2).

Should they be fixed/changed or not, issuing a warning would be greatly helpful.

Updated by jeremyevans0 (Jeremy Evans) about 5 years ago

I tried working on this a couple weeks ago and I don't believe the current LALR(1) parser can support it. Attempting to modify the parser to support the behavior you desire leads to many shift/reduce or reduce/reduce conflicts. It is possible that switching from the default LALR(1) parser to a GLR parser (which bison also supports) may allow for the behavior your desire, but I'm not sure what the ramifications of that are. It's also possible there is a way to introduce this behavior with the existing LALR(1) parser, and I am just not aware of it, as I do not have much experience in this area.

Actions #2

Updated by hsbt (Hiroshi SHIBATA) almost 5 years ago

  • Tags set to unfixable, parser

Updated by matz (Yukihiro Matsumoto) almost 5 years ago

We are not going to change the behavior. We may warn (with -W) if we see the simple assignments on the right-hand side of multiple assignments.

Matz.

Actions #4

Updated by matz (Yukihiro Matsumoto) almost 5 years ago

  • Status changed from Open to Rejected
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0