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$
    – Szabolcs
    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$
    – Szabolcs
    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$
    – xzczd ♦
    Commented Jun 30, 2020 at 6:26
  • 1
    $\begingroup$ @sza Aha, here comes another broken example: mathematica.stackexchange.com/a/29366/1871 $\endgroup$
    – xzczd ♦
    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$
    – John Fultz
    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$
    – xzczd ♦
    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$
    – Szabolcs
    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$
    – John Fultz
    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$
    – xzczd ♦
    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$
    – xzczd ♦
    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$
    – xzczd ♦
    Commented Jun 30, 2020 at 7:14

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.