REBOL3 tracker
  0.9.12 beta
Ticket #0001966 User: anonymous


Short URL:
TypeWish Statussubmitted Date26-Feb-2013 08:30
Versionr3 master CategoryParse Submitted byfork
PlatformAll Severityminor Prioritynormal

Summary Allow COMMENT to behave as a no-op in PARSE, like in DO
Description I was rediscovering the pleasantries of COMMENT in the DO dialect. I'd sort of forgotten about it, but then geeked out about how nifty it is in evaluative circumstances to have such a thing available. (Most languages don't have it, and I think it might be an undersold bonus. Rebol sometimes undersells nifty abilities like this).

Anyway, it made me wonder if PARSE had adopted it as well. So I tried and found out that it didn't. Unless I'm missing something obvious, this should be fairly uncontroversial to add and easy to implement. The general issue of educating users that within the interpeter these symbols are *still there* does remain, but I think that education is enlightening in and of itself and it is a valuable tool if understood.

Obviously this would remove the ability to have a user-variable called COMMENT in the parse dialect. Which given that parse can be used to parse languages, this is not necessarily trivial... because you might want the rule for a comment in that language to be called comment. But if you called your rule that you were messing with Rebol's comment when you did the assignment. So maybe you should call it MYLANG-COMMENT instead. :-)
Example code
Current behavior:

>> parse "ab" ["a" comment {Shouldn't parse support comment, too?} "b"]
** Script error: PARSE - invalid rule or usage of rule: comment
** Where: parse
** Near: parse "ab" ["a" comment "Shouldn't parse support comment, to...

Desired behavior:

>> parse "ab" ["a" comment {Shouldn't parse support comment, too?} "b"]
== true

Assigned ton/a Fixed in- Last Update9-Mar-2014 23:26

26-Feb-2013 11:49

Well, I am OK having the ability to write:

parse "ab" [
"a" ; No serious problem to use a comment
26-Feb-2013 21:28

The advantage to line comments is that they are dropped at runtime, and thus take no memory or other runtime overhead. That is also their disadvantage, in case you want those comments showing up when you use SOURCE or other reflection functions, or if you want the comments to survive LOAD-based source transformations. However, those same criticisms apply to the DO dialect COMMENT function, and we still use that. This seems to be as justified as the COMMENT function, and would be used for the same purposes.

If we decide to do this, a PARSE COMMENT operation should have the same effect as PARSE's NONE operation, and PARSE should not at all process any value that immediately follows in the dialect. It shouldn't affect a subsequent full rule with modifiers (AND, OPT, integers, SOME, ...), just the next value only (like DO's COMMENT). If you want to comment out a full rule, put it in a block like COMMENT [your rule].
27-Feb-2013 00:40

In SO chat someone pointed out this transform.

This: [comment "This is a comment!"]
becomes: [("This is a comment!")]

This: [comment [rule you don't want executed]]
becomes: [([rule you don't want executed])]

This approach would have more overhead, but it's doable in a pinch.
9-Mar-2014 23:26

Related Red issue:

Date User Field Action Change
9-Mar-2014 23:26 abolka Comment : 0004364 Added -
27-Feb-2013 00:40 BrianH Comment : 0003521 Added -
26-Feb-2013 21:28 BrianH Comment : 0003516 Added -
26-Feb-2013 11:50 Ladislav Comment : 0003506 Modified -
26-Feb-2013 11:49 Ladislav Comment : 0003506 Added -
26-Feb-2013 08:33 Fork Description Modified -
26-Feb-2013 08:32 Fork Description Modified -
26-Feb-2013 08:32 Fork Code Modified -
26-Feb-2013 08:30 Fork Ticket Added -