On 03/09/17 03:56, William Dunlap via R-help wrote:> Is the reason you want a block comment containing code (as opposed to > arbitrary text) that you want to be able to easily run the commented out > code? If so the 'if()' construct has the advantage that you only need to > change code at the start of the comment, not at both ends. > > The if(FALSE) could be if(isTRUE(getOption("DEBUG_ISSUE_XYZ"))) so you > would not even have to change code to re-enable the debugging code, just > call options(DEBUG_ISSUE_XYX=TRUE)).(a) The foregoing is getting too subtle for my feeble brain. (b) A fundamental problem with the if(FALSE) { ... } paradigm is that the enclosed code must be syntactically valid, and there are certainly situations in which one might wish to comment out sections of code that are *not* syntactically valid. E.g. one might wish to comment out *part* of a piece of syntactically valid code for the purpose of experimenting with an alternative approach. cheers, Rolf -- Technical Editor ANZJS Department of Statistics University of Auckland Phone: +64-9-373-7599 ext. 88276> On Sat, Sep 2, 2017 at 7:54 AM, Suzen, Mehmet <msuzen at gmail.com> wrote: > >> AFAIK block comment is not possible >> it needs to be implemented in R interpreter and defined in the >> parser.'If' solution is not elegant. >> >> On 2 September 2017 at 14:09, Uwe Ligges >> <ligges at statistik.tu-dortmund.de> wrote: >>> >>> >>> On 02.09.2017 11:40, Christian wrote: >>>> >>>> I consider it quite worth while to introduce into R syntax a nestable >>>> block comment like >>>> >>>> #{ >>>> <block of code> >>>> }# >>> >>> >>> if(FALSE){ >>> <block of code> >>> } >>> >>> Best, >>> Uwe Ligges >>> >>> >>>> It would make documentation more easily manageable and lucid. >>>> Is there considerable need for this. >>>> >>>> Please, comment on this. >>>> How about R core? >>>> >>>> Christian >>> >>> >>> ______________________________________________ >>> R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see >>> https://stat.ethz.ch/mailman/listinfo/r-help >>> PLEASE do read the posting guide http://www.R-project.org/ >> posting-guide.html >>> and provide commented, minimal, self-contained, reproducible code. >> >> ______________________________________________ >> R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see >> https://stat.ethz.ch/mailman/listinfo/r-help >> PLEASE do read the posting guide http://www.R-project.org/ >> posting-guide.html >> and provide commented, minimal, self-contained, reproducible code. >> > > [[alternative HTML version deleted]] > > ______________________________________________ > R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. >
On 02/09/2017 6:57 PM, Rolf Turner wrote:> On 03/09/17 03:56, William Dunlap via R-help wrote: >> Is the reason you want a block comment containing code (as opposed to >> arbitrary text) that you want to be able to easily run the commented out >> code? If so the 'if()' construct has the advantage that you only need to >> change code at the start of the comment, not at both ends. >> >> The if(FALSE) could be if(isTRUE(getOption("DEBUG_ISSUE_XYZ"))) so you >> would not even have to change code to re-enable the debugging code, just >> call options(DEBUG_ISSUE_XYX=TRUE)). > > > (a) The foregoing is getting too subtle for my feeble brain. > > (b) A fundamental problem with the > > if(FALSE) { > ... > } > > paradigm is that the enclosed code must be syntactically valid, and > there are certainly situations in which one might wish to comment out > sections of code that are *not* syntactically valid. E.g. one might > wish to comment out *part* of a piece of syntactically valid code for > the purpose of experimenting with an alternative approach.If the code is not syntactically valid, why would you expect the block comment to be syntactically valid? The proposal at the start of this thread was that #{ would open the block and would be matched by }# to close the block. What if the closing sequence occurred within the block unintentionally? Then the poor feeble programmer would be even more confused. I like the current rule: any line starting with # is a comment. (Actually the rule is a bit more subtle than that, but it's close.) If I want to comment out a block, I can spend a long time typing # at the start of every line, or I can ask my editor to do it. I don't need to worry if something in the block unintentionally closes it, because that's impossible. If the first line is a comment, all the rest are too. Duncan Murdoch
On 03/09/17 12:29, Duncan Murdoch wrote:> On 02/09/2017 6:57 PM, Rolf Turner wrote: >> On 03/09/17 03:56, William Dunlap via R-help wrote: >>> Is the reason you want a block comment containing code (as opposed to >>> arbitrary text) that you want to be able to easily run the commented out >>> code? If so the 'if()' construct has the advantage that you only >>> need to >>> change code at the start of the comment, not at both ends. >>> >>> The if(FALSE) could be if(isTRUE(getOption("DEBUG_ISSUE_XYZ"))) so you >>> would not even have to change code to re-enable the debugging code, just >>> call options(DEBUG_ISSUE_XYX=TRUE)). >> >> >> (a) The foregoing is getting too subtle for my feeble brain. >> >> (b) A fundamental problem with the >> >> if(FALSE) { >> ... >> } >> >> paradigm is that the enclosed code must be syntactically valid, and >> there are certainly situations in which one might wish to comment out >> sections of code that are *not* syntactically valid. E.g. one might >> wish to comment out *part* of a piece of syntactically valid code for >> the purpose of experimenting with an alternative approach. > > If the code is not syntactically valid, why would you expect the block > comment to be syntactically valid?I thought I had made that clear. One might wish to comment out a *piece* of syntactically valid code (with a view to replacing it). The piece commented out might not be syntactically valid simply because it is *just a piece* and might thereby be incomplete.> The proposal at the start of this > thread was that #{ would open the block and would be matched by }# to > close the block. What if the closing sequence occurred within the block > unintentionally? Then the poor feeble programmer would be even more > confused.Do not the same considerations essentially apply to the well established /* .... */ convention used in C? Well maybe you simply *can't* get the "*/" string within a block of C code, but still .... If "#{....}#" runs this risk, then some other construction which doesn't run the risk could be used.> I like the current rule:De gustibus non disputandum.> any line starting with # is a comment. > (Actually the rule is a bit more subtle than that, but it's close.) > If I want to comment out a block, I can spend a long time typing # at > the start of every line, or I can ask my editor to do it. I don't need > to worry if something in the block unintentionally closes it, because > that's impossible. If the first line is a comment, all the rest are too.I don't follow the foregoing, but no matter. I'm slow. This issue is quite obviously No Big Deal. Block comments are a convenience that it would be nice to have, but obviously one can live without them and not suffer unduly. cheers, Rolf -- Technical Editor ANZJS Department of Statistics University of Auckland Phone: +64-9-373-7599 ext. 88276