Allow nested block comments in parser #774

Activity

1. nickbattle

   added

   enhancementNot a bug, but nice to haveNot a bug, but nice to have

   languageIssues in parser, TC, interpreter, POG or CGIssues in parser, TC, interpreter, POG or CG

   on Feb 5, 2021
2. nickbattle

   self-assigned this

   on Feb 5, 2021
3. nickbattle

   added a commit that references this issue on Feb 5, 2021

   Allow nested block comments, fixes #774

   This issue will close once commit 100d48d is merged into the 'development' branch.

   100d48d
4. nickbattle

   added

   MergableA fix is available on a branch to merge for releaseA fix is available on a branch to merge for release

   on Feb 5, 2021
5. nickbattle commented on Feb 5, 2021

   

   nickbattle

   on Feb 5, 2021

   ContributorAuthor

   More actions

   Change now available in ncb/development.
6. nlmave commented on Feb 5, 2021

   

   nlmave

   on Feb 5, 2021 via email

   More actions

   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 <notifications@github.com>: 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.
7. nickbattle commented on Feb 5, 2021

   

   nickbattle

   on Feb 5, 2021

   ContributorAuthor

   More actions

   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.

   👍React with 👍1Reacted by Peter W. V. Tran-Jørgensen
8. nlmave commented on Feb 5, 2021

   

   nlmave

   on Feb 5, 2021 via email

   More actions

   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 <notifications@github.com>: 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.
9. nickbattle commented on Feb 5, 2021

   

   nickbattle

   on Feb 5, 2021

   ContributorAuthor

   More actions

   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).
10. nlmave commented on Feb 5, 2021

    

    nlmave

    on Feb 5, 2021 via email

    More actions

    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 <notifications@github.com>: 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.
11. nickbattle

    removed

    MergableA fix is available on a branch to merge for releaseA fix is available on a branch to merge for release

    on Feb 9, 2021
12. nickbattle commented on Feb 9, 2021

    

    nickbattle

    on Feb 9, 2021

    ContributorAuthor

    More actions

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

    added

    MergableA fix is available on a branch to merge for releaseA fix is available on a branch to merge for release

    on May 3, 2021
14. nickbattle commented on May 3, 2021

    

    nickbattle

    on May 3, 2021

    ContributorAuthor

    More actions

    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.