0000067: if (cond)

(0000222)
xclerc (Administrator)
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 (Reporter)
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 (Administrator)
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 (Reporter)
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 (Reporter)
2011-01-19 10:14

(In the first example above, the "+" is under "1".)

(0000233)
xclerc (Administrator)
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.

Problem-Historie
Änderungsdatum	Benutzername	Feld	Änderung
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 (Administrator) 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 (Reporter) 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 (Administrator) 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 (Reporter) 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 (Reporter) 2011-01-19 10:14	(In the first example above, the "+" is under "1".)

(0000233) xclerc (Administrator) 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.

Problem-Beziehungen