3
$\begingroup$

There are situations that the caret cursor symbol ^ remains in the code like if the code is not finished and something has to be added in its position yet the code works without any error message.

Is this style of programming correct?

Divide[Sequence @@ {2, 3}] 
2/3

The above input looks like this in notebook:

enter image description here

I know it can be written also as Divide @@ {2, 3} but there are sometimes situations when you need to use Sequence like in the first example.

Another strange behavior of syntax highlighting is the following code like if there is an error in the syntax indicated by red brackets:

Divide{2, 3} Divide {2, 3} Divide*{2, 3} 
{2 Divide, 3 Divide} {2 Divide, 3 Divide} {2 Divide, 3 Divide}

The above input looks like this in notebook:

enter image description here

Again no error (in fact there is no reason why there should be any error) but the brackets in the first two lines are red even though they represent the same code as third line which has no red brackets.

So why are the brackets red?

By the way I do not have much trouble with that behavior of Mathematica, it is more a question out of curiosity.

Improve this question
$\endgroup$
6
  • 2
    $\begingroup$ I think the caret in the 1st example is reasonable since Divide is expecting 2 arguments and it has no means to snoop the evaluation of the 1st argument to see its result. The red curly brackets make sense because the symbol is a function expecting parameters and that usage will not result in the evaluation of the function. The last is explicit with the multiplication so no highlighting given. I think all cases make good sense. $\endgroup$ Commented Aug 29, 2024 at 21:18
  • 1
    $\begingroup$ My guess is that the front end can only look at the literal syntax of what you've input. It can't know that Sequence @@ {2, 3} will evaluate to an acceptable argument list. It could only do that if it first asked the kernel to perform the calculation, but of course it can't do that without, well, the calculation happening (presumably prematurely, since the user is still trying to input stuff), $\endgroup$ Commented Aug 29, 2024 at 21:18
  • 1
    $\begingroup$ Also, these are just hints--they have no impact on the actual expressions themselves, so I wouldn't really ponder them too much. In my experience, they are useful much more often than not, so I'm not really too distracted when I want to intentionally ignore them. $\endgroup$ Commented Aug 29, 2024 at 21:22
  • $\begingroup$ @Edmund I think using space for multiplication is as explicit as using asterisk. It is just less visible ;-) $\endgroup$ Commented Aug 29, 2024 at 21:23
  • $\begingroup$ I agree with the front end, Divide{2,3} is almost certainly a bug in your code even if it is valid syntax. $\endgroup$ Commented Aug 30, 2024 at 12:20

1 Answer 1

Reset to default
4
$\begingroup$

Since the evaluation proceeds without any issues, this certainly can be considered a correct style of programming. I also remember seeing similar things several times in internal Mathematica functions.

Note that the new Static Analysis Tool doesn't even consider this as an issue:

Needs["CodeInspector`"] CodeInspectSummarize["Divide[Sequence@@{2,3}]"] (* No issues. *) CodeInspectSummarize["Divide{2,3}"] (* No issues. *)

If you are bothered by the front-end highlighting this in red, you can turn it off. Note that your first case is an example of missing arguments, and the second one is the example of possible (!) misused parenthesis or braces (think of people writing Sin(x)).

enter image description here

SetOptions[$FrontEnd, AutoStyleOptions -> { "HighlightMissingArguments" -> False, "HighlightMisusedParens" -> False }]
Improve this answer
$\endgroup$
4
  • $\begingroup$ Another similar highlighting is 2 #^2 + 3 # + 1; % /. # -> x where slot is pink. $\endgroup$ Commented Aug 30, 2024 at 12:02
  • 2
    $\begingroup$ @azerbajdzan, well, you would rarely ever want to have Slot live outside Function, that is why it is highlighted ... CodeInspectSummarize["2 #^2+3 #+1"] gives Unscoped Slot error. $\endgroup$ Commented Aug 30, 2024 at 12:36
  • $\begingroup$ I have already used it in some of my own defined functions. I do not say I could not have avoided it, surely I could, but that was the easiest and shortest way to write the code that did what I wanted. But then you have found a bug in CodeInspectSummarize or discrepancy between what CodeInspectSummarize thinks is an error and what kernel thinks is an error. $\endgroup$ Commented Aug 30, 2024 at 12:45
  • 1
    $\begingroup$ It's not a bug, because it doesn't say that there is necessary an error. It just warns you that you might not have wanted to write this. I suggest reading about static analysis and its purpose. $\endgroup$ Commented Aug 30, 2024 at 12:59

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.