Talk:Strip block comments: Difference between revisions
→Definition of delimiters?: block comment in Rexx
Walterpachl (talk | contribs) (→Definition of delimiters?: block comment in Rexx) |
|||
| (5 intermediate revisions by 3 users not shown) | |||
Line 4:
: We could bump it back to draft. Do you have a better definition? --[[User:Short Circuit|Michael Mol]] 18:40, 2 November 2010 (UTC)
::I believe the intent here is to emulate the treatment of comments in existing languages. Note also that no example treatment is given for cases like <code>/*/*/*/*/*/</code> though presumably that sequence is equivalent to a single asterisk?
::: That depends if the language allows nested comments. The REXX language treats it as an open comment (i.e., not closed) and therefore a syntax error. Allowing nested comments allows the programmer to comment out a large section of code (which, of course, would contain comments). -- [[User:Gerard Schildberger|Gerard Schildberger]] 10:14, 1 April 2012 (UTC)
::In any event, I think that the specification should reflect the rigid character of the desired end. I would eliminate the requirement that the comment delimiters be passed as parameters (or expand the definition of those parameters to include their aspects which have been implicitly specified... but I can not see a good way to do that). I would also include explicit examples for the treatment of character sequences which look like delimiters but are not delimiters because of their position.
::If my interpretation is acceptable, I could tackle re-writing the task specification. --[[User:Rdm|Rdm]] 18:47, 2 November 2010 (UTC)
Line 19 ⟶ 22:
Do we have a (constant) definition of the delimiters to use or are they parameters to the stripping function? This is important because it leads to quite different solutions… –[[User:Dkf|Donal Fellows]] 09:56, 3 November 2010 (UTC)
Also, we don't have a definition of how (some) languages handle comments.
<br>For instance:
<br>say 66/*yuppers*/77
<br>in the REXX language, <tt> 6677 </tt> is displayed to the screen.
<br>Some languages assume the comments acts like white space. -- [[User:Gerard Schildberger|Gerard Schildberger]] 10:24, 1 April 2012 (UTC)
: same with
<pre>
say 66/* an enormous block comment
*/77
</pre>
: yet to be analyzed: can any /* ... */ sequence be REMOVED? --[[User:Walterpachl|Walterpachl]] ([[User talk:Walterpachl|talk]]) 05:08, 14 July 2013 (UTC)
== J draft ==
Line 54 ⟶ 70:
::: Sure you can, and you can do so without any knowledge of string syntax. Though this task does not do that. For example, you can specify that comments extend to the end of the line and that on any line with a comment, the comment is the shortest string that matches the comment pattern. This mechanism would be similar to the concept of escape characters. It also bears resemblance to most any comment syntax which does not allow for nested comments. --[[User:Rdm|Rdm]] 11:25, 12 August 2011 (UTC)
:::: You lost me. So you can just strip from # to end of line in the example <code>print("# not comment")</code>? --[[User:Ledrug|Ledrug]] 19:38, 12 August 2011 (UTC)
::::: That would be syntactically invalid. But you could fix it: <code>print("# not comment")#</code> --[[User:Rdm|Rdm]] 19:58, 12 August 2011 (UTC)
:::::: Ok consider this: <code>/* printf("/* is comment") */</code>. I guess you'll call it "nested comment", which is not: as I said above, I was talking about where comment delimiters can be part of literal strings, but I guess your rules won't really allow that because now real comment markers would have to pair up with fake markers that are part of a string (which makes no sense). For a real example, just see what happens if you use the C code on task page and try to strip its own source code. --[[User:Ledrug|Ledrug]] 20:07, 12 August 2011 (UTC)
| |||