9
$\begingroup$

Bug introduced in 7.0 or earlier and persisting through 11.0

While looking at A question about conditional replacement I think I discovered a bug in the Front End that affects both 7.0.1 and 10.0.1 under Windows.

If I copy and paste this line into a new Cell in a Notebook:

{g[x, y, z], h[x, y], f[]} /. (f_[t___] /; f != List) :> Plus[t]

then select ≠ (auto-converted to single character) and type over it =!= and evaluate I get:

{g[x, y, z], h[x, y], f[]}

Rather than the expected:

{x + y + z, x + y, 0}

If I use menu Cell > Convert To > InputForm the input cell is converted to:

{g[x, y, z], h[x, y], f[]} /. ((f_)[t___] /; f) =!= List :> Plus[t]

Note the parentheses: ((f_)[t___] /; f) is grouped separately from =!= List. The RHS therefore evaluates to:

True :> +t

Does this problem affect all recent versions on all platforms or is it more localized?

Improve this question
$\endgroup$
8
  • $\begingroup$ reproduced in V9.0.1.0 (windows 8) $\endgroup$
    – kglr
    Commented Nov 2, 2014 at 5:02
  • $\begingroup$ Reproduces in versions 8.0.4 and 10.0.1 under Win7 x64. Instead of converting the Cell to InputForm I just add //Hold at the end of the expression and evaluate it again. $\endgroup$
    – Alexey Popkov
    Commented Nov 2, 2014 at 5:03
  • $\begingroup$ Strangely enough, if you add a space anywhere before or after =!=, or edit anything else inside the parantheses, it gives the expected output. $\endgroup$
    – kglr
    Commented Nov 2, 2014 at 5:14
  • 1
    $\begingroup$ After you substituted =!= you can simply go left of the f and press Ctrl+. for expand selection. You see that the front-end parses it incorrectly because /; seems to have a higher precedence. Weird. Btw, M8.0.4 on OSX. $\endgroup$
    – halirutan
    Commented Nov 2, 2014 at 5:49
  • $\begingroup$ Yep. Reproduced 10.0.1.0 on Mac OS X. $\endgroup$
    – Mark Adler
    Commented Nov 2, 2014 at 6:18

1 Answer 1

Reset to default
6
$\begingroup$

I think when you press = over ≠, the underlying RowBox-es got re-grouped (which is a correct move), but somehow didn't re-group again when finishing input =!=. I don't know if the FrontEnd is supposed to re-parse code every 1/n second, but it does look like a bug to me.

One possible workaround: Select the cell, from the Edit menu, Copy As Plain Text, paste in to an empty Input Cell. This should enforce re-parsing the code.

Improve this answer
$\endgroup$
4
  • 1
    $\begingroup$ ... yet another work-around: type =!= in the order !=+ backspace + backspace = :) $\endgroup$
    – kglr
    Commented Nov 2, 2014 at 7:06
  • $\begingroup$ @kguler Or can we enforce an in-place re-parsing on the Cell? :) $\endgroup$
    – Silvia
    Commented Nov 2, 2014 at 7:08
  • $\begingroup$ Actually, retyping of any character to the left of =!= inside (f_ ... List) seems to force re-parsing. $\endgroup$
    – kglr
    Commented Nov 2, 2014 at 7:20
  • $\begingroup$ @kguler Yes I saw your comment :) Off topic: sometimes I wonder why human write code in plain text and ask for a parser to analyse/formalize it. It's unnatural ... $\endgroup$
    – Silvia
    Commented Nov 2, 2014 at 7:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.