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?

$\endgroup$
  • $\begingroup$ reproduced in V9.0.1.0 (windows 8) $\endgroup$ – kglr Nov 2 '14 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 Nov 2 '14 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 Nov 2 '14 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 Nov 2 '14 at 5:49
  • $\begingroup$ Yep. Reproduced 10.0.1.0 on Mac OS X. $\endgroup$ – Mark Adler Nov 2 '14 at 6:18
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.

$\endgroup$
  • 1
    $\begingroup$ ... yet another work-around: type =!= in the order !=+ backspace + backspace = :) $\endgroup$ – kglr Nov 2 '14 at 7:06
  • $\begingroup$ @kguler Or can we enforce an in-place re-parsing on the Cell? :) $\endgroup$ – Silvia Nov 2 '14 at 7:08
  • $\begingroup$ Actually, retyping of any character to the left of =!= inside (f_ ... List) seems to force re-parsing. $\endgroup$ – kglr Nov 2 '14 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 Nov 2 '14 at 7:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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