Allow nested block comments in parser

[nickbattle]

This was recently raised on VDMJ (via VDM VSCode). It is quite useful to correctly parse nested /* ... */ style block comments because it means you can comment out large blocks of code without worrying about any comments within. The behaviour is unspecified in the LRM, so this is just a usability change.

[nickbattle]

Change now available in ncb/development.

[nlmave]

You better check this as I thought that in the iso standard nested comments are explicitly forbidden and in fact it is also from to point of useability very bad (coding) practice.....Op 5 feb. 2021 11:52 schreef Nick Battle <[email protected]>: This was recently raised on VDMJ (via VDM VSCode). It is quite useful to correctly parse nested /* ... */ style block comments because it means you can comment out large blocks of code without worrying about any comments within. The behaviour is unspecified in the LRM, so this is just a usability change. —You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or unsubscribe.

[nickbattle]

The ISO standard only refers to inline -- style comments, so nesting is not an issue. Block comments were introduced at some point in VDMJ/Overture for convenience.

The "bad practice" point is debatable. If you were using them deliberately, then I would agree. But the original request here was regarding the ability to comment out large sections of a specification which may contain block comments already. In that case, nesting makes this much easier.

[nlmave]

Indeed, it is very debatable:https://softwareengineering.stackexchange.com/questions/81072/why-do-most-programming-languages-not-nest-block-commentshttps://futhark-lang.org/blog/2017-10-10-block-comments-are-a-bad-idea.htmlSo I'm not convinced this is a good idea.Op 5 feb. 2021 16:47 schreef Nick Battle <[email protected]>: The ISO standard only refers to inline -- style comments, so nesting is not an issue. Block comments were introduced at some point in VDMJ/Overture for convenience. The "bad practice" point is debatable. If you were using them deliberately, then I would agree. But the original request here was regarding the ability to comment out large sections of a specification which may contain block comments already. In that case, nesting makes this much easier. —You are receiving this because you commented.Reply to this email directly, view it on GitHub, or unsubscribe.

[nickbattle]

We can run it past the Language Board, I suppose. It didn't strike me as particularly controversial (mostly invisible), so I didn't consider raising an RM. The link you provided does mention that a handful of languages already support this, so it's not unheard of (Haskell, Frege, Scala, Rexx, Modula-2, Modula-3, Oberon).

[nlmave]

I think it would be a good idea to treat it as a LB issue. I will have a look at the coding standards that we use, I seem to recall that block comments are only allowed for embedding documentation (doxygen like) and only single line comments are allowed inside top-level definitions (functions, operations). I do not recall a single coding standard that allows nested block statements. Hence my reservations to support this, in particular in a specification language.Op 5 feb. 2021 17:23 schreef Nick Battle <[email protected]>: We can run it past the Language Board, I suppose. It didn't strike me as particularly controversial (mostly invisible), so I didn't consider raising an RM. The link you provided does mention that a handful of languages already support this, so it's not unheard of (Haskell, Frege, Scala, Rexx, Modula-2, Modula-3, Oberon). —You are receiving this because you commented.Reply to this email directly, view it on GitHub, or unsubscribe.

[nickbattle]

I'll remove the Mergable tag on this until the LB has had a chance to comment.

[nickbattle]

After discussions in the LB, the parser will be changed to use the current behaviour by default/-strict, but to allow a setting to choose nested comments to be warned, errored, or parsed via a configurable tool setting.

This parser and property change is now available in ncb/development. But note that #775 is also required before the configurable feature is usable.