Just a question of interest: Does anyone know why there's no block comment capability in VB .NET? (Unless there really is - but I've never yet come across it.)
It is a side-effect of the Visual Basic syntax, a new-line terminates a statement. That makes a multi-line comment pretty incompatible with the basic way the compiler parses the language. Not an issue in the curly brace languages, new-lines are just white space.
It has never been a real problem, Visual Basic has had strong IDE support for a very long time. Commenting out multiple lines is an IDE feature, Edit + Advanced + Comment Selection.
Totally abusing compiler directives here... but:
#If False Then
Comments
go
here
#End If
You don't get the benefits of proper code coloration (it doesn't show in green when using the default color scheme) and the implicit line-continuation system automatically indents lines in a paragraph starting at the second line. But the compiler will ignore the text.
As can be read in “Comments in Code“ there isn't any other way:
If your comment requires more than one line, use the comment symbol on each line, as the following example illustrates.
' This comment is too long to fit on a single line, so we break
' it into two lines. Some comments might need three or more lines.
Similarly, the help on the REM statement states:
Note:
You cannot continue a REM statement by using a line-continuation sequence (_). Once a comment begins, the compiler does not examine the characters for special meaning. For a multiple-line comment, use another REM statement or a comment symbol (') on each line.
Depending on how many lines are to be ignored, one can use compiler directives instead. It may not be technically equivalent to comments (you don't get the syntax coloring of comments, for example), but it gets the job done without commenting many lines individually. So you just add 3 more lines of code.
#Const COMMENT = "C"
'basically a false statement
#If COMMENT = "Y" Then
'code to be commented goes between #If and #End If
MsgBox('Commenting failed!')
#End If
This is assuming the purpose is for ignoring blocks of code instead of adding documentation (what "comments" are actually used for, but I also wouldn't mind using compiler directives for that).
The effort required however, makes this method inconvenient when there are just around 10 lines to comment.
Reference: http://msdn.microsoft.com/en-us/library/tx6yas69.aspx
Related
I am tasked to parse (and transform) a code of a computer language, that has a slight quirk in its rules, at least I see it this way. To be exact, the compiler treats new lines (as well as semicolons) as statement separators, but other than that (e.g. inside the statement) it treats them as spacers (whitespace).
As an example, this code:
try
local x = 5 / 0
catch (i)
print(i + "\n")
is proved to be equivalent to this:
try local x = 5 / 0 catch (i) print(i + "\n")
I don't see how I can express such a rule in EBNF, or specifically in Lark EBNF dialect. I mean in a sensible way. I probably could define all possible newline positions inside all statements, but it would be cumbersome and error-prone.
I wish to find a way to treat newlines contextually. Is there a proven method for this, preferably within Python/Lark domain? If I have to modify the parser for that purpose, then where should I start?
Or if I misunderstood something in this language in particular or in machine language parsing in general, or my statement of the problem is wrong, I'd also be happy to get educated.
(As you may guess, the language in question has a well proven implementation, but no officially defined grammar. Also, it is Squirrel, for all that it matters.)
The relevant quote from the "specification" is this:
A squirrel program is a simple sequence of statements.:
stats := stat [';'|'\n'] stats
[...] Statements can be separated with a new line or ‘;’ (or with the keywords case or default if inside a switch/case statement), both symbols are not required if the statement is followed by ‘}’.
These are relatively complex rules and in their totality not context free if newlines can also be ignored everywhere else. Note however that in my understanding the text implies that ; or \n are required when no of the other cases apply. That would make your example illegal. That probably means that the BNF as written is correct, e.g. both ; and \n are optionally everywhere. In that case you can (for lark) just put an %ignore "\n" statement and it should work fine.
Also, lark should not complain if you both ignore the \n and use it in a rule: Where useful it will match it in a rule, otherwise it will just ignore it. Note however that this breaks if you use a Terminal that includes the \n (e.g. WS or /\s/). Just have \n as an extra case.
(For the future: You will probably get faster response for lark questions if you ask over on gitter or at least put a link to SO there.)
In Perl 5, it's best to use
use strict;
use warnings;
to ask the compiler to complain about missing semicolons, undeclared variables, etc.
I have been informed by citizens of the Perl community here on SO that Perl 6 uses strict by default, and this seems after testing to be the case.
Semicolons aren't required for the last statement in a block, but if I extend the block later, I'll be chagrinned when my code doesn't work because it's the same block (and also I want semicolons everywhere because it's, like, consistent and stuff).
My assumption is that Perl 6 doesn't even look at semicolons for the last statement in a block, but I'm still curious: is there a way to make it stricter yet?
Rather than enforce the extra semi-colon, Rakudo does try to give you a good error/hint if you do add to your block and forget to separate statements.
Typically I get "Two terms in a row across lines (missing semicolon or comma?)" when this happens.
Probably quite a niche question, but I believe in the power of a big community: Is it possible to set up jEdit in way, that it automatically inserts a comment character (//, #, ... depending on the edit mode) at the beginning of a new line, if the line before the wrap was a comment?
Sample:
# This is a comment spanning multiple lines. If I continue to type here, it
# wraps around automatically, but I have to manually add a `#` to each line.
If I continue to type after the . the third line should start with the # automatically. I searched in the plugin repository but could not find anything related.
Background: jEdit has the concepct of soft and hard wrap. While soft wrap only breaks lines visually at a character limit, it does not insert line breaks in the file. Hard wrap on the other hand inserts \n into the file at the desired character count.
This is not exactly what you want: I use the macros Enter_with_Prefix.bsh to automatically insert the prefix (e.g., #, //) at the beginning of the new line.
Description copied from Enter_with_Prefix.bsh:
Enter_with_Prefix.bsh - a Beanshell macro for jEdit
that starts a new line continuing any recognized
sequence that started the previous. For example,
if the previous line beings with "1." the next will
be prefixed with "2.". It supports alpha lists (a., b., etc...),
bullet lists (+, =, *, etc..), comments, Javadocs,
Java import statements, e-mail replies (>, |, :),
and is easy to extend with new sequence types. Suggested
shortcut for this macro is S+ENTER (SHIFT+ENTER).
I know there are a lot of resources with regex for it. But I could not find the one I want.
My problem is:
I want to remove one line comments (//) from obj-c sources, but I don't want to break the code in it. For instance, with this regex: #"//.*" I can remove all comments, but it also corrupts string literal:
#"bsdv//sdfsdf"
I played with non-capturing parentheses (?:(\"*\")*+), but without success.
Also I found this expression for Python:
r'(\".*?\"|\'.*?\')|(/\*.*?\*/|//[^\r\n]*$)'
It should cover my case, but I've not figure out how to make it work with obj-c.
Please, help me to build proper regex.
UPDATE: Yeah, that's a tough one, I know there're a lot of caveats, other than the one I described. I would appreciate if someone post regex that only fix my issue. Anyway, I gonna post my solution, without regex soon, I hope it will be helpful for anyone who struggling with such problem too.
Try this regex:
(?:^|.*;(?!.*")|#(?:define|endif|ifn?def|import|undef|...).*)\s*(//[^\r\n]+$)
Demo
http://regex101.com/r/jT4xC8
Description
Discussion
Besides all the warnings expressed in the comments, I assume that a single line can appear in two distinct cases:
Case 1: Alone on its line preceded or not by blank chars
Case 2: Not Alone on its line preceded or not by blank chars, and other chars.
In the first case, we match the beginning of the line (^ with /m flag). Then we search zero or more blank chars (\s*) and finally the single line comment: //[$\r\n]+$.
In the second case, if there are other chars on the line, they form statements. Any statement is ended by a semicolon ;. So we search the last statement and its corresponding semicolon .*;(?!.*"). Then we search the single line comment. Those other chars can be also preprocessor statements. In this case, they are introduced by a sharp #.
One important keypoint is that I assume the code passed to the regex is a code that compiles.
There is more
Don't forget also to add some other pre-processor directives that may apply in your case. Check this SO answer: https://stackoverflow.com/a/18014883/363573
I'm unable to comment-out and compile the following line of code with /* */, within the XCode editor. I distilled this example down from a more complex string used in an XPath query:
the string itself seems fine:
NSString* s = #"//*//";
won't compile for me:
/*
NSString* s = #"//*//";
*/
XCode 4.4. I'll file a radar if anyone can confirm I'm not being stupid.
EDIT: nice to see that the SO syntax highlighter also exhibits an issue with this...
EDIT: okay, I filed a bug report with Apple. Thanks.
EDIT: Per Rob's answer below, this is NOT a bug :) Thanks for explaining it, Rob; totally makes sense now.
This is not a compiler bug. The double-quote character " has no special meaning inside a comment, so the preprocessor doesn't pay any attention to it. The preprocessor just ends the comment as soon as it sees the */ characters.
The best way to comment out a section of code is to put // at the beginning of each line. A // comment ends at the next newline. Xcode has a menu command (shortcut: ⌘/) that will comment or uncomment your selected lines by inserting or removing // at the start of each line.
It detects and end comment in #"//*//"; I don't know of any editor that allows nesting of block comments (I know that's not what you're doing, but same issue). Notice how even the syntax highlighter on SO screws up.