| Type | Wish | Status | submitted | Date | 26-Feb-2013 08:30 |
|---|---|---|---|---|---|
| Version | r3 master | Category | Parse | Submitted by | fork |
| Platform | All | Severity | minor | Priority | normal |
| 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 to | n/a | Fixed in | - | Last Update | 9-Mar-2014 23:26 |
|---|
| Comments | |
|---|---|
|
(0003506)
Ladislav 26-Feb-2013 11:49 |
Well, I am OK having the ability to write:
parse "ab" [ "a" ; No serious problem to use a comment "b" ] |
|
(0003516)
BrianH 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]. |
|
(0003521)
BrianH 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. |
|
(0004364)
abolka 9-Mar-2014 23:26 |
Related Red issue: https://github.com/red/red/issues/724 |
| 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 | - |