I saw the ml Archives of Groovy, arguing that the EOS / EOL problem was argued.
C-style language does not have an EOS problem, the syntax specifies the explicit ';' 'as an EOS. However, from JavaScript, the use of Automatic Semicolon INSERTION is used, so that in many cases, ';' is omitted.
It has been seen that there is a design of some people, and now I suddenly discovered that the root caused by the mixture is: Others do not use ';' language is mostly eol as natural EOS, but this can omit'; 'design leads to lack determination EOS, sometimes EOL is EOS, sometimes not! The judgment of the context is not very intuitive in some cases.
This situation is more serious in Groovy.
Groovy has more abstract design principles called PHIM: "Parse How I mean". In this way, it is guided to generate a number of interesting and dangerous features, such as omitting Return keywords.
More free syntax does not seem to avoid bringing more ambiguity, PHIM often produces a mixed and conflict. The result of the weighing requires some more stringent restrictions, such as someone suggesting that only the Method / Closure last row can omit the return keyword.
According to the inactive and concise goals, participants continue to make and improve the suggestions for the EOS problem in ML's Threads, I think that the more acceptable comments are: unbalanced parentheses, operators (and a few inheriting Java) The EOL after the Keyword structure is like IF (...), for (...), ELSE, etc.) is not EOS. The cost of pay is inconsistent with Java / C, etc. in the meaning of the following statement:
A = 1 2 3;
At the same time, it is inconsistent with JavaScript:
A = f (param)
Similar questions are some. For example, the most funny comments:
A = 1 // Commentb = 2 // Comment 1 // CommentC = 3 / * Commentcomment * / 1
Obviously in / * comment * /, any Comment is ignored, including EOL. In // Comment grammar, the final EOL according to Java is also neglected, this is no problem, because EOS = 'in Java;'. However, the lack of clear EOS's Groovy cannot ignore EOL, otherwise there will be strange things (the results of the first, 2 lines become A = 1B = 2). Of course, this is mainly Issue on Grammar, not the ISSUE in practice.
It is foreseeable that the EOS problem will continue to be old, and the typical sentence pattern is: "If you remove Optional Semcolon's characteristics, this syntax is easy to solve ..."
However, although there are many evidence to show 省 省 ';' may bring a lot of trouble, but John Wilson is quite reasonable:
No expert programmers * hate * the situation in which the compiler throws out the program because of a missing semicolon. They ask the very reasonable question "if the compiler knows there should be a semicolon there why the **** does not it put IT IN? "So I generally agree with this feature.
