Mantis - Mascot
Erweiterte Problemanzeige
67 general Feature-Wunsch immer 2011-01-09 19:52 2011-07-10 06:56
chris  
xclerc  
normal  
erledigt  
erledigt  
keine    
keine 1.0-beta  
0000067: if (cond)
It would be nice to detect useless parentheses after “if” which are often added by novices.
Problem-Historie
2011-01-09 19:52 chris Neues Problem
2011-01-11 19:34 xclerc Problemnotiz hinzugefügt: 0000221
2011-01-11 19:35 xclerc Problemnotiz hinzugefügt: 0000222
2011-01-11 19:35 xclerc Bearbeitung durch => xclerc
2011-01-11 19:35 xclerc Status neu => Rückmeldung
2011-01-11 19:35 xclerc Problemnotiz gelöscht: 0000221
2011-01-11 22:07 chris Problemnotiz hinzugefügt: 0000225
2011-01-19 06:38 anonymous Problemnotiz hinzugefügt: 0000226
2011-01-19 06:39 xclerc Problemnotiz hinzugefügt: 0000227
2011-01-19 06:39 xclerc Problemnotiz gelöscht: 0000226
2011-01-19 10:13 chris Problemnotiz hinzugefügt: 0000230
2011-01-19 10:14 chris Problemnotiz hinzugefügt: 0000231
2011-01-20 06:09 xclerc Problemnotiz hinzugefügt: 0000233
2011-01-26 20:11 xclerc Status Rückmeldung => anerkannt
2011-03-23 11:11 anonymous Problemnotiz hinzugefügt: 0000236
2011-03-23 18:02 anonymous Problemnotiz gelöscht: 0000236
2011-07-10 06:56 xclerc Status anerkannt => erledigt
2011-07-10 06:56 xclerc Behoben in Version => 1.0-beta
2011-07-10 06:56 xclerc Lösung offen => erledigt

Notiz
(0000222)
xclerc   
2011-01-11 19:35   
Good suggestion; I would like to have your feedback on the exact intended perimeter.
It seems quite clear that superfluous top-level parentheses should be detected in:
  - "if" constructs;
  - "while" constructs;
  - "when" constructs.

I am wondering if it should also be detected in:
  - "for" bounds;
  - "let/in" constructs;
  - top-level "let" constructs.

And I may also be missing other constructs.
(0000225)
chris   
2011-01-11 22:07   
Certainly "for" (especially the part after "to"/"downto"). Maybe also "match" — but the "mistake" seems less common in this case. For "let" is is more difficult to say, sometimes top-level parentheses may be desired if the expression is long (and for former version of tuareg since the indentation was influenced by them). If implemented, I would prefer it as a separate rule.
(0000227)
xclerc   
2011-01-19 06:39   
Thanks for your feedback.

I will probably implement the check for "if"/"while"/"when"/"for"/"let-in"
under the name "code.useles_external_parentheses". Then, for toplevel
"let" constructs, we will see if people actually request it...

Will close this bug when implemented in the repository.
(0000230)
chris   
2011-01-19 10:13   
Hum, sorry, when I wrote "let" I especially meant "let-in". Here is an example of useless parentheses that serve indentation purposes:

  let x = (1
           + 2) in

Without these parentheses, the (automatic) indentation would be:

  let y = 1
    + 2 in

which is not suitable for all cases.
(0000231)
chris   
2011-01-19 10:14   
(In the first example above, the "+" is under "1".)
(0000233)
xclerc   
2011-01-20 06:09   
My bad, I misinterpreted your point.

It is indeed quite a good thing not to analyze the "let/in" constructs,
as the asymmetry between the two forms of "let" made me fuzzy.


Thanks for the clarification.