11
$\begingroup$

Just check

i_: 0 | 1 // FullForm

In v12.0 or earlier the output is

Alternatives[Optional[Pattern[i, Blank[]], 0], 1]

enter image description here

But in v12.1 the output becomes

Optional[Pattern[i, Blank[]], Alternatives[0, 1]]

enter image description here

Seems that the precedence between : and | varies in v12.1. Is this an intentional change, or a bug?

Some more observations. Behavior in v3:

enter image description here

Behavior in v2.1:

enter image description here

Improve this question
$\endgroup$
9
  • 2
    $\begingroup$ I suspect that this was a bugfix. Try running the same in command-line mode, or try ToExpression["i_: 0 | 1 // FullForm"]. It parses the same way as in 12.1.1. I expect this fixed an inconsistency between the FE's and the kernel's parser. $\endgroup$ Commented Jun 30, 2020 at 6:14
  • 3
    $\begingroup$ I wonder how you came across this example. I can't see a reasonable use for either (i_ : 0) | 1 or i_ : (0 | 1). $\endgroup$ Commented Jun 30, 2020 at 6:23
  • 1
    $\begingroup$ @Szabolcs It's a simplified example of course. I found this because it breaks my code here (see revision 6 ): mathematica.stackexchange.com/posts/132713/revisions . Your guess looks reasonable. Post it as an answer? $\endgroup$ Commented Jun 30, 2020 at 6:26
  • 1
    $\begingroup$ @sza Aha, here comes another broken example: mathematica.stackexchange.com/a/29366/1871 $\endgroup$ Commented Jun 30, 2020 at 10:04
  • 2
    $\begingroup$ Actually the 2.1 screenshot answers a question for me. Because when I saw the FE implementation, which dated back to the very beginning of the box parser, I couldn't figure out why it was done that way...in obvious contradiction to the docs. But your 2.1 screenshot suggests that there was actually a change to the kernel (and maybe the docs as well) from 2.1 to 3.0. Maybe the box parser, which was implemented in 3.0, was based on what would become out-of-date info from the kernel. The box parser was implemented maybe a year before I started working on the FE. $\endgroup$ Commented Jul 1, 2020 at 17:05

2 Answers 2

Reset to default
9
$\begingroup$

I expect that this was a bugfix that corrected an inconsistency between how the Front End and the kernel parse this code. Here's a comparison from M12.0.0:

In[1]:= $Version Out[1]= 12.0.0 for Mac OS X x86 (64-bit) (April 7, 2019) In[2]:= i_: 0|1//FullForm Out[2]//FullForm= Alternatives[Optional[Pattern[i,Blank[]],0],1] In[3]:= ToExpression["i_: 0 | 1 // FullForm"] Out[3]//FullForm= Optional[Pattern[i,Blank[]],Alternatives[0,1]]
Improve this answer
$\endgroup$
4
  • 1
    $\begingroup$ Seeing the behavior of v2.1 , I'm a bit confused which change should be regarded as bug... (Check my update. ) $\endgroup$ Commented Jun 30, 2020 at 7:09
  • 1
    $\begingroup$ @xzczd I would always give the kernel's parsing priority because that is what is being used when a package (i.e. a plain text file) is loaded. $\endgroup$ Commented Jun 30, 2020 at 8:07
  • 2
    $\begingroup$ There's no need to guess here, or pick favorites between the kernel and the FE. The documentation trumps everything. Any variation from the documentation is always a bug (it might be a bug in the documentation, of course, but in practice that's pretty rare). reference.wolfram.com/language/tutorial/OperatorInputForms.html And, yes, it was indeed an intentional bugfix. Three external users had reported some variant of this, and IIRC it came up on the Redmine, too. $\endgroup$ Commented Jul 1, 2020 at 16:55
  • $\begingroup$ @JohnFultz So, the behavior of kernel is an incompatible change of kernel in v3.0, and the behavior of front end is a bug introduced in v3.0 and fixed in v12.1.0? $\endgroup$ Commented Jul 2, 2020 at 2:22
7
$\begingroup$

I think V. 12.1.1 is correct, because the precedence of Alternatives (|) is larger than that of Optional (:)

Precedence /@ {Alternatives, Optional} 
{160., 140.}

This result of Precedence is obtainable both in V. 12.1.1 and V. 12.0.0 (no V. 12.0.1 at hand). So it looks like a bug in V. 12.0.x when interpreting shorthand symbols.

Improve this answer
$\endgroup$
3
  • 1
    $\begingroup$ "it looks like a bug in V. 12.0.x" No, the behavior is much older than you thought. See my update. $\endgroup$ Commented Jun 30, 2020 at 7:06
  • 1
    $\begingroup$ @xzczd So what would Precedence return in those much older versions? $\endgroup$ Commented Jun 30, 2020 at 7:12
  • $\begingroup$ Same result in v3, but there doesn't seem to be a Precedence in v2.1. $\endgroup$ Commented Jun 30, 2020 at 7:14

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.