In the following code that skips comments, what's meaning of BEGIN(INITIAL) ?
%x C_COMMENT
"/*" { BEGIN(C_COMMENT); }
"*/" { BEGIN(INITIAL); }
. { }
INITIAL is a state which is implicitly declared in all lex programs. (C_COMMENT is also a state, but it is not built-in into lex, so it is declared explicitly.)
BEGIN(statename) just means enter the state statename. So what this lex snippet does is the following: If an "/*" is read it enters the state C_COMMENT, when it sees a "*/" it goes back to the default state.
You could now add rules which ignore all input (except "*/" of course) when in the C_COMMENT state, while doing other things with the input when you are not (or when you are in the INITIAL state).
Related
I am trying to migrate some modules to DML 1.4 and I face some problems during bank content iteration. Specifically, I originally have the snippet below:
select reg in ($signals.unmapped_registers) where (reg.signal_number == signal) {
// some statements here
} else {
log "unimplemented", 1: "Power/Board: Signal %d is unimplemented", signal;
return;
}
However, unmapped_registers is not valid in DML 1.4, thus leading to an unknown identifier compiler error.
How am I supposed to iterate over all the unmapped registers of a specific bank in DML 1.4 and select the one I want based on some specific criteria (i.e. the signal_number parameter)?
I've already tried swapping the select statement with foreach without success.
I've also tried to iterate over all bank registers that instantiate a specific template, but still without success.
You need to foreach over a template that has signal_number as type member.
When you iterate using foreach, the iteration variable is a run-time template reference, which means that not all declarations of the template can be accessed: Only parameters with a declared explicit type belong to the template type (together with all method declarations annotated with shared, and most session and saved declarations). So in your case, your problem is likely that signal_number does not have a declared type.
If you add a parameter type like this:
template register_with_signal is register {
param signal_number : int;
// default assignment must be a separate declaration
param signal_number default -1;
...
}
then you can implement your loop like this:
method handle_signal(int signal) {
foreach reg in (each register_with_signal in (this)) {
if (reg.signal_number == signal) {
// some statements here
return;
}
}
log unimpl: "signal %d is unimplemented", signal;
}
What is the reason for wrapping all this code in a UI: do { } block and where can I get clear instructions about it?
UI: do {
backgroundButton.setImage(UIImage.init(named: "search"), for: .normal)
backgroundButton.backgroundColor = Colors.backgroundButtonBackgroundColor
backgroundButton.tintColor = Colors.backgroundButtonTintColor
}
Other than labels being used to break loops (change control flow), in your particular example it's probably being used to organize the code.
So, in:
UI: do {
//...
}
UI: is a Labelled Statement where UI is a user defined label name that should be descriptive enough to indicate or hint to the reader of it's purpose
Labeled Statement
You can prefix a loop statement, an if statement, a switch statement,
or a do statement with a statement label, which consists of the name
of the label followed immediately by a colon (:). Use statement labels
with break and continue statements to be explicit about how you want
to change control flow in a loop statement or a switch statement
Ref: https://docs.swift.org/swift-book/ReferenceManual/Statements.html#ID439
do { } is a Do Statement
Do Statement
The do statement is used to introduce a new scope and can optionally
contain one or more catch clauses, which contain patterns that match
against defined error conditions. Variables and constants declared in
the scope of a do statement can be accessed only within that scope.
Ref: https://docs.swift.org/swift-book/ReferenceManual/Statements.html#ID533
//... is all the code within the scope of do
Usage Example:
In a monolithic function, in order to improve code readability and segregate the internal logics, a labeled do statement can be used.
So, if this is a monolithic function:
func update() {
var hasUpdatedDatasource = false
print("setting datasource")
//N lines of code related to datasource
let strings = ["update", "Datasource"]
print(strings.joined())
hasUpdatedDatasource = strings.count > 2
print("setting something")
//N lines of code related to something
if hasUpdatedDatasource {
print("setting some more stuff")
//N lines of code related to something more
}
print("setting UI")
//N lines of code related to UI
}
Here we see multiple lines of code in which you may be creating/modifying variables. Basically alot of soup code that would make it hard to figure out which set of code lines is handling which feature or part of the function.
Using a labeled do statement, as in your case, will make the code a bit more readable like so:
func update() {
var hasUpdatedDatasource = false
updateDatasource: do {
//do datasource related modification
//N lines of code go here
let datasource = ["update", "Datasource"]
print(datasource.joined())
hasUpdatedDatasource = strings.count > 2
}
doSomething: do {
print("doSomething")
//N lines of code go here
guard hasUpdatedDatasource else { break doSomething }
print("doSomething: More")
//N lines of code go here
}
updateUI: do {
print("updateUI")
//N lines of code go here
}
}
This allows you to make a set of code lines into block of codes with a descriptive label name and shows the logic flow more clearly.
You can access and modify variables from above it's do scope, and since it has it's own scope, variables created inside are only accessible here.
This can prevent variables from lingering unnecessarily till the end of the function.
NOTES:
updateDatasource created a local variable datasource which won't be available outside it's scope, AND... modified a variable hasUpdatedDatasource which is local to the entire function
doSomething has a break statement that can break itself anytime by referring to it's label name
It does make the code more readable but not necessarily more maintainable as it's statefull.
Personally, I prefer splitting large functions into smaller or nested functions. But this does not mean that labeled do statements don't have their place.
If it makes your code better, go for it.
It's a labeled statement:
A labeled statement is indicated by placing a label on the same line
as the statement’s introducer keyword, followed by a colon.
and it can be used to break away from outsider scopes. An illustrative example is given here.
The UI in your code is a labeled statement which is useful in cases where you want to escape from an outer scope(or block) while you're inside an inner scope(or block)
Consider an example where you want to break out of the outer loop when a certain condition arises while you're inside another loop(or, innerLoop in our case)
outerLoop: for outerCount in 1...5 {
innerLoop: for innerCount in 1...5 {
// Condition for breaking out of outer loop
if outerCount == 3 {
break outerLoop
}
print("Outer Count: \(outerCount) Inner Count: \(innerCount)")
}
}
If we had used break instead of break outerLoop in above case, we
would just be able to break innerLoop and would still be inside
outerLoop scope
The do clause in your case , as #Rob suggested , can also be used to simply encapsulate a series of statements within their own scope . What it does is, it provides a scope for some variables that are initialised inside do and will be deallocated once the do scope ends
Consider the following case for do scope which will automatically deinit the object as soon as the do scope ends
class Demo {
init() {
print("Instance initialised")
}
deinit {
print("Instance Deinitalised")
}
}
do {
let demoObject = Demo()
}
Output of above code will be
Instance initialised
Instance Deinitalised
Have anybody extended comment-dwim to automagically insert a multi-line comment like
/** ...
*/
void foo
{
}
if the cursor is currently in front of a function/variable definition/declaration?
I realize that the challenge here is context detection; could a call to end-of-defun() followed by a call to beginning-of-defun() be used here?
I am looking over an Xcode project I downloaded and am seeing code syntax that I am unfamiliar with:
The braces don't belong to a method signature, or any other conditional statement, they are just floating there. What is the point of this? Purely for code segregation/readability purposes?
This is just block scope; and is the same in C and C++. Any variables declared within the block are inaccessible outside of it. I commonly use it in switch statements:
switch(x) {
case 1: {
const char *s = "hi";
}
break;
case 2: {
const char *s = "ho";
}
break;
// etc.
}
Note that there are two variables called s, neither of which interfere with the other as they are within their own scope.
The declarations within the scope enclosed by the braces will be confined to that scope, so label, icon, and button will not be visible outside of it. As such it provides locality which is generally considered to be good.
Legacy code needed { } in order to do declarations at all
In C89, you couldn't just do int i; anywhere; declarations were only valid at the beginning of blocks.
check this for more explanation
Why enclose blocks of C code in curly braces?
I'm trying to write a class for a scala project and I get this error in multiple places with keywords such as class, def, while.
It happens in places like this:
var continue = true
while (continue) {
[..]
}
And I'm sure the error is not there since when I isolate that code in another class it doesn't give me any error.
Could you please give me a rule of thumb for such errors? Where should I find them? are there some common syntactic errors elsewhere when this happens?
It sounds like you're using reserved keywords as variable names. "Continue", for instance, is a Java keyword.
You probably don't have parentheses or braces matched somewhere, and the compiler can't tell until it hits a structure that looks like the one you showed.
The other possibility is that Scala sometimes has trouble distinguishing between the end of a statement with a new one on the next line, and a multi-line statement. In that case, just drop the ; at the end of the first line and see if the compiler's happy. (This doesn't seem like it fits your case, as Scala should be able to tell that nothing should come after true, and that you're done assigning a variable.)
Can you let us know what this code is inside? Scala expects "expressions" i.e. things that resolve to a particular value/type. In the case of "var continue = true", this does not evaluate to a value, so it cannot be at the end of an expression (i.e. inside an if-expression or match-expression or function block).
i.e.
def foo() = {
var continue = true
while (continue) {
[..]
}
}
This is a problem, as the function block is an expression and needs to have an (ignored?) return value, i.e.
def foo() = {
var continue = true
while (continue) {
[..]
}
()
}
() => a value representing the "Unit" type.
I get this error when I forget to put an = sign after a function definition:
def function(val: String):Boolean {
// Some stuff
}