5
$\begingroup$

I believe it's a bug in notebook's comment parser. I can't comment strings with *) inside it. Something like:

(*"this is a bug*)"*)

I discovered it trying to comment a code with a regular expression RegularExpression["((re)*)"] inside it.

Can someone else check it?

Using V10.0.2 in MacOS

Improve this question
$\endgroup$
2
  • 1
    $\begingroup$ Same issue with V10.0.2.0 in Windows 8.1 (64 bit). $\endgroup$
    – bbgodfrey
    Jan 22 '15 at 0:38
  • 3
    $\begingroup$ A quick fix: RegularExpression["((re)*"<>")"] $\endgroup$
    – ybeltukov
    Jan 22 '15 at 11:19
10
$\begingroup$

We already have some answers explaining the issue. Let me give a solution to your problem. Let's say you have the code

RegularExpression["((re)*)"]

that you want to comment out. Since we have nested comments in Mathematica, just use a pair of (* to prevent your issue:

Mathematica graphics

Although I don't know the internal implementation of Mathematicas parser, the reason why this goes wrong is pretty universal. Parsing is usually a two-step process. First, the input is broken down into tokens by a so-called lexer and comments are often separated from the rest of the code in this stage. Taking your example 

(* RegularExpression["((re)*)"] *)

this means the lexer first reads the token COMMENT_OPEN. Then, the lexer usually reads over everything until it meets the closing *). And here it is important to know that the lexer really stupidly reads over the input.

Unfortunately, the next closing *) is inside the stuff you wanted to comment out. At this point the lexer leaves its stupid comment mode again and tries to tokenize real code. Now, he is in the middle of your expression and everything goes wrong.

Btw, using the fultzTokenize of this answer shows how Mathematica breaks your code down. Note that I had to quote the quotes accordingly. See that strings are kept together when the lexer is in code mode when going over str2:

str1="(* RegularExpression[\"((re)*)\"] *)";
str2="RegularExpression[\"((re)*)\"]";
fultzTokenize/@{str1,str2}

  {(*, ,RegularExpression,[,"((re),*),"] *)}
  {     RegularExpression,[,"((re)*)",]}
Improve this answer
$\endgroup$
1
  • 2
    $\begingroup$ +1 Clever. It exploits the fact that Mathematica is unusual among languages in that it supports nested matchfix comments (unlike, say, C). $\endgroup$
    – WReach
    Jan 22 '15 at 1:14
9
$\begingroup$

This behaviour is very common, possibly near universal, in programming languages with matchfix comment syntax. The reason is that the contents of a comment sequence is presumed not to be code. Usually that presumption is correct, but not in this case. The general rule is

You should be able to put anything inside a comment and the only special tokens inside comments are the tokens (* and *) itself.

C, C++, Java and SQL, just to name a few, exhibit the same problem. Those languages also offer a prefix syntax that can be used to work around the problem -- provided you can isolate the relevant expression to its own line. C also offers a way to disable whole blocks of code using IFDEF, etc.

Unfortunately, Mathematica only offers the matchfix syntax. Thus, there is no analog to the prefix/block notations in other languages. A prefix comment syntax would probably make a good addition to the language -- but there are mighty few left-over special characters for that purpose :). Additionally, we should not forget that lines don't really exist in the front-end since it shuffles code around automatically.

Improve this answer
$\endgroup$
3
$\begingroup$

I would not call this a bug in the sense that the behaviour of the Front End and the Kernel (run in command line mode) are consistent with each other.

Yes, this does make code like "asd *)" un-commentable, so you might call it bad design. But I wouldn't call it a bug.

Contrast this with certain bugs where the Front End parses expressions differently from the Kernel. For example, the M10.0.2 front end still has some difficulties with expressions of the type #"one two" while the kernel handles them. The existence of these types of bugs proves that the Front End and Kernel do indeed use separate parsers.

Improve this answer
$\endgroup$
2
$\begingroup$

This happens because characters inside the comment are not actually parsed. Ponder these two code fragments:

(*  "This string contains the end of a comment  *)"  *)
(*  "This comment begins with a quote character *)

How can the parser tell whether the quote is the start of a string or just a quote?

Improve this answer
$\endgroup$
1
$\begingroup$

the "bug":

(*"this is a bug*)"*)

the work around:

(*"this is a solution\*)"*)
Improve this answer
$\endgroup$
1
  • 1
    $\begingroup$ If the closing *) is, like in Murta's case, part of a working Mathematica expression, I wouldn't use this because when you un-comment the region again, you have to go through your entire expression and remove the `. Using (*(*` at the beginning is easier IMO here. $\endgroup$
    – halirutan ♦
    Jan 22 '15 at 2:26
0
$\begingroup$

Based on the procedure outlined in the first Answer to 40396, the internal representation of 

(*"this is a bug*)"*)

is

RowBox[{RowBox[{"(*", "\"\<this is a bug\>", "*)"}], "\"\<*)\>"}]

We see that (*"this is a bug*) is interpreted as a comment, and "*) as additional code that is syntactically incorrect. As other Answers here have explained, this is not surprising.

If someone really wants to display this item, it can be accomplished with

RowBox[{RowBox[{"(*", "\"\<this is a bug\>", "*)"}], "\"\<*)\>"}]//DisplayForm

yielding 

(*"this is a bug*)"*)

in an In cell (but without the red color, which is added by SE).

Improve this answer
$\endgroup$

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.