My one-line script:
Shift::Send ^{Space}
Is it necessary to add a return statement like the following?
Shift::Send ^{Space}
return
In the case of a subroutine with a label like you show above, the subroutine will be called and will continue until it gets to either return or exit.
So in this example, return isn't necessary
With functions, return is actually assumed in ahk so you don't necessarily need to include it unless your passing it with an expression.
In either case though, you might want to include it just to make things more readable.
Quote an example from the return documentation to demonstrate what it does:
The first Return separates the hotkey from the subroutine below. If it were not present, pressing the hotkey would cause Sleep 1000 to be executed twice.
#z::
MsgBox The Win-Z hotkey was pressed.
Gosub MySubroutine
return
MySubroutine:
Sleep 1000
return
Also, quote from Hotkeys Introduction and Simple Examples:
If a hotkey needs to execute only a single line, that line can be listed to the right of the double-colon. In other words, the return is implicit:
#n::Run Notepad
As a side note, if binding multiple hotkeys to the same action, we can write:
#a::
#b::MsgBox
Related
I'm doing a simple assignment where I have to go over test case coverage(statement coverage, path coverage, etc) of a function.
I've tried endlessly to add code here and StackOverflow won't accept it no matter how I format it, so I'll just explain a very simple example.
Let's say you get to an if statement that has a return statement inside it. In the line below the return line is the if's closing bracket '}'
My professor and our textbook have been pretty vague about what a statement is, but my understanding is that for a line of code to be a statement it has to perform some type of function such as assigning a value to a variable or being a conditional statement like an if or while loop.
So my questions are:
Does the closing bracket count as a statement? Or do they only count as a line?
When the computer is reading the code and hits the return statement, does it jump to the correct number of closing brackets before leaving the function and returning a value?
Closing brackets are not traditionally counted as statements.
Even if they follow a return (or any other kind of unconditional control transfer, e.g. goto to raise exception.).
A more interesting case is:
if (...) {
return;
x=1;
}
The x=1; statement can't get control. Test coverage should tell you it is uncovered because it never gets executed.
This example is exactly the same code, slightly reformatted:
if (...) {
return; x=1; }
Many test coverage tools will show you covered lines rather than covered code, so would mark the return line as covered. That's wrong; x=1; is still uncovered and the coverage display tool should make that clear.
This is especially important if you have a long source line which exits (e.g., by exception) in the middle:
x=foo().bar().baz();
If bar() throws an exception, then foo(). is covered, x=... is not, and baz() is not. This shows why line coverage, while common, can be very misleading.
Now consider this case:
if (a) {
...
if (b)
return;
}
c;
If a and b are true, the return statement executes. Control doesn't flow past the if (b) statement. If a is true and b is false... the return isn't executed and control flows past the if (b) to statement c;. In this case you can argue the } is "covered" even though it isn't a statement. A good coverage tool should show } c; as covered.
Emacs Lisp has a facility for adapting documentation to the user's current key bindings, by referencing the command name in the docstring and letting Emacs dynamically insert the current key binding for that command when the user requests the documention. However, when I use this in a docstring that mentions many key bindings, it completely messes up the line wrapping. Take this example from my package:
(substitute-command-keys
"Fix ido behavior when `require-match' is non-nil.
Standard ido will allow
\\<ido-common-completion-map>\\[ido-select-text] to exit with an
incomplete completion even when `require-match' is non-nil.
Ordinary completion does not allow this. In ordinary completion,
\\[ido-exit-minibuffer] on an incomplete match is equivalent to
\\[ido-complete], and \\[ido-select-text] selects the first
match. Since \\[ido-exit-minibuffer] in ido already selects the
first match, this advice sets up \\[ido-select-text] to be
equivalent to \\[ido-complete] in the same situation.
This advice only activates if the current ido completion was
called through ido-cr+.")
With the standard bindings, the docstring displayed to the user looks like this:
Fix ido behavior when ‘require-match’ is non-nil.
Standard ido will allow
C-j to exit with an
incomplete completion even when ‘require-match’ is non-nil.
Ordinary completion does not allow this. In ordinary completion,
RET on an incomplete match is equivalent to
TAB, and C-j selects the first
match. Since RET in ido already selects the
first match, this advice sets up C-j to be
equivalent to TAB in the same situation.
This advice only activates if the current ido completion was
called through ido-cr+.
which looks atrocious and borderline unreadable due to the random variations in line length in the middle paragraph. Here's what it should actually look like:
Fix ido behavior when ‘require-match’ is non-nil.
Standard ido will allow C-j to exit with an incomplete completion
even when ‘require-match’ is non-nil. Ordinary completion does
not allow this. In ordinary completion, RET on an incomplete
match is equivalent to TAB, and C-j selects the first match.
Since RET in ido already selects the first match, this advice
sets up C-j to be equivalent to TAB in the same situation.
This advice only activates if the current ido completion was
called through ido-cr+.
Obviously, the problem is that the special sequences recognized by substitute-command-keys are not the same length as the strings that replace them, which throws off the line wrapping in my source code. Is there some way to force emacs to re-compute the paragraph wrapping in my docstring after running substitute-command-keys and before displaying it to the user?
You could use visual-line-mode together with adaptive-wrap. This way you can continue logical lines and don't split them yourself.
Is there some way to force emacs to re-compute the paragraph wrapping in my docstring after running substitute-command-keys and before displaying it to the user?
I don't believe so (and in general it would undoubtedly be problematic), but if you expect the short keybindings to be displayed (rather than M-x name-of-command) then you can use longer lines and trust they will be rendered as shorter lines. If the assumption is wrong, then you'll render lines which are longer than you wanted (rather than the current situation of lines which are shorter than you wanted).
Note that you don't need to exceed your regular fill column in your source code to do this -- you can break lines in the docstring source with an "escaped newline" (backslash+newline), as the reader omits these sequences from the string (refer to C-hig (elisp)Syntax for Strings).
E.g.:
(substitute-command-keys
"Fix ido behavior when `require-match' is non-nil.
Standard ido will allow \\<ido-common-completion-map>\
\\[ido-select-text] to exit with an incomplete completion
even when `require-match' is non-nil. Ordinary completion does
not allow this. In ordinary completion, \\[ido-exit-minibuffer]\
on an incomplete match
is equivalent to \\[ido-complete], and \\[ido-select-text]\
selects the first match. Since \\[ido-exit-minibuffer]
in ido already selects the first match, this advice sets up\
\\[ido-select-text] to
be equivalent to \\[ido-complete] in the same situation.
This advice only activates if the current ido completion was
called through ido-cr+.")
renders:
"Fix ido behavior when `require-match' is non-nil.
Standard ido will allow C-j to exit with an incomplete completion
even when `require-match' is non-nil. Ordinary completion does
not allow this. In ordinary completion, RET on an incomplete match
is equivalent to TAB, and C-j selects the first match. Since RET
in ido already selects the first match, this advice sets up C-j to
be equivalent to TAB in the same situation.
This advice only activates if the current ido completion was
called through ido-cr+."
The problem here is that I do not understand well the difference between statements and blocks in control flow.
Looking the ternary operator I can use it to assign a variable. But this is an operator, so it is like applying a function--isn't it?
> my $variable = True ?? 34 !! 42;
34
since in the raku documentation says:
if documentation
if
To conditionally run a block of code, use an if followed by a
condition. The condition, an expression, will be evaluated immediately
after the statement before the if finishes. The block attached to the
condition will only be evaluated if the condition means True when
coerced to Bool. Unlike some languages the condition does not have to
be parenthesized, instead the { and } around the block are mandatory:
do documentation
do
The simplest way to run a block where it cannot be a stand-alone statement is by writing do before it:
so this should work in both cases:
> my $variable = do {34};
34
> my $variable = if True {34;} else {43;}
===SORRY!===
Word 'if' interpreted as a listop; please use 'do if' to introduce the statement control word
------> my $variable = if⏏ True {34;} else {43;}
Unexpected block in infix position (two terms in a row)
------> my $variable = if True⏏ {34;} else {43;}
as said in the error I need to add the do:
> my $variable = do if True {34;} else {43;}
34
So the if really does not run the block...or what is the real problem here?
TL;DR: The actual difference is between statement and expression, not statement and block. do is a statement prefix that creates expressions.
if actually creates a statement (anything that is run in Raku is), however, what it's not is an expression. do is a statement prefix, and what it does is turn statements into expressions.
However, if is not really a first-class function that you can assign to a variable or handle around. Whenever you find pieces of syntax such as that one (or for, for instance), you need to prefix them with do to "expressionify" them.
say &say.^name;# OUTPUT: «Sub» say &do.^name; # OUTPUT: «===SORRY!=== Error while compiling <tmp>Undeclared routine:...
say &if.^name; # OUTPUT: «===SORRY!=== Error while compiling <tmp>Undeclared routine: if used at line 1»
So if, by itself, does not create a block, it does not create an expression, it simply creates a statement. You need to precede it with do if you want it to actually turn it into a expression. It does run the block that's behind it, however.
Let's go back to the original question, statements and blocks. Blocks are objects, first-class citizens. You can use them, apply them, pass them around.
my &ifs = { if $_ {34} else {43}};
ifs(True).say; # OUTPUT: «34»
Statements are throwaway blocks you simply run. In some cases, they are also expressions: they yield a result which, then, you can assign.
my &ifs = { if $_ {34} else {43}};
my $result = ifs(True).say; # OUTPUT: «34»
say $result; # OUTPUT: «True»
The ifs(True).say statement prints to output, it also produces a result that can be assigned. All three lines are also statements, and as a matter of fact, expressions too.
Some control structures, however, do not create expressions.
Some others do; for creates a expression; while does not.
if is an example of this. They don't produce a result. You use them for the side effects: running a statement (if true) or another (if not). You might turn them into a block, as above, and pass them around. Or you can just precede them with do and make them produce a throwaway result, which you can then use.
So it will very much depend on your actual use case. You can surround the if statement with curly braces and create a block; or you can simply use the result creating an expression. Or you might want to use it just for the side effects, doing nothing.
I have a question related to a transition in my statechart (see image above). I have a variable called palletInUse which is a boolean-type and changes between true and false. For one transition in my statechart I want it to change when the variable palletInUse has the value true. I have tried it with for example:
palletInUse == true;
and also tried different code like, equals and contentEquals etc. but nothing seems to work. Do you have a solution for this, seemingly simple problem?
Thanks in advance
The condition is not monitored constantly, only when something is changed in the agent. When you assign a new value to variable with common "=" Java operator, it is not caught by the AnyLogic engine. You need to call onChange() function after that. Then, the transition should be executed.
There are other ways to trigger the condition check without explicit onChange() call. You may find them in AnyLogic Help article.
BTW, you may specify just boolean variable as the condition, it is not required to compare it with true or false:
palletInUse
The condition is not evaluated if nothing is happening, for that reason you have to make something happen constantly to have your condition evaluated. A typical way of doing is as you see in the following pictures:
I've used for a long time single-return style (as structural programming style). I've started reading Fowler's "Refactoring" and found "Removing control flag" and "Replace Nested Conditional with Guard Clauses" where he writes, that single return should be avoided.
As for me, there are a lot of benefits using single return, and only some more difficults for reading. So what are the profit using multiple return?
Benefits:
Single return allows easily put breakpoint to return statement
It's easy to add Assert for result value if there are single return
Single return makes code more readable
Even with multiple returns there is one function exit point. It is the closing curly bracket. Just place a breakpoint on it and set a conditional to check rAX (if IA32e).
int f()
{
if (condition)
return 1;
return 0;
} // Place here. Would break at epilog just before return.