The language guide says:
Swift doesn’t require you to write a semicolon (;) after each statement in your code, although you can do so if you wish. However, semicolons are required if you want to write multiple separate statements on a single line.
This implies that Swift uses newlines as statement terminators. Does every statement need to fit on a single line? Or is it possible to insert a newline within a single statement - and if so, what are the rules that determine whether or not a newline terminates a statement?
Swift can have newlines in statements. It is so common in complex commands like this:
var query = HouseholdInfoTable.table
.select(HouseholdInfoTable.uuid.distinct, HouseholdInfoTable.table[*])
.join(PersonInfoTable.table, on: PersonInfoTable.householdUuid == HouseholdInfoTable.uuid)
.filter(HouseholdInfoTable.houseNumber == houseNumber)
.order(HouseholdInfoTable.sortName)
But you can have simple statements broken up, like this:
let a = 1
+ 2
let b = 1 +
2
Generally you can split the line across operands or punctuation
You can do multiline comments with line feeds in them like this:
let bigComment = """
anythingYou want can go here
asdlkasdkljfad
askjf
"""
Swift's style guide has more in-depth information:
https://google.github.io/swift/#line-wrapping
Playgrounds are a good place to see what the compiler handles.
Related
I'll start with my code:
macro example(args...)
local s = __source__
println(s) # This part works, showing macro is called on line 9
quote
println(s) # Julia tells me this variable "s" is not defined
println(__source__) # Likewise, "__source__" is not defined here either
end
end
#example 42 # Line 9 of my file
In my macro above I want to record the line number that is calling the macro and use it within my quote block. Both capturing it in a variable outside the quote block and using it within, or using it directly in the quote block don't work. My understanding is the code outside the quote block runs at parse-time, and the expression returned from the quote block is evaluated at run-time.
I feel like there must be a way to capture that variable and inject it right into the expression that will be evaluated later, but I haven't figured out how to do that. Any help here is appreciated. If there is a better way to do this let me know.
I ended up finding out an answer on my own. In the second line if I changed __source__ to __source__.line or __source__.file it worked fine as long as I then used $ to interpolate the result into the expression the macro returned. I'm still not sure why __source__ on its own didn't work, but using either .line or .file methods is working for me now.
I'm experiencing a similar problem trying to use __source__.
I think I can offer insight into why source.line, etc worked though.
The value of source.line is an integer. The value of source.fike is a string. Numbers and strings evaluate to themselves.
A symbol, on the other hand, evaluates to whatever value it has in the environment.
A string have data with semicolons now i want to remove all the data within the 2 semicolons and leave the rest as it is. I am using perl regex to remove the unwanted data from the string:
String :
$val="Data;test is here ;&data=1dffvdviofv;&dt&;&data=343";
Now we want to remove all the data between each semicolons ,throughout the string :
$val=~s/(.*)(\;.*\;)(.*)$/$1$3/g;
But this is not working for me. Final out should be like below :
Data &data=1dffvdviofv&data=343
One of the problems is that .* is greedy, that is, it will consume as much as it can. You can make it non-greedy by writing .*?, but that alone won't fix your regex since you've anchored it to the end of the string with $. Personally I don't think there is a need for the capture groups, you can just write
$val =~ s/;.*?;//g;
I'm assuming that the extra space in your expected output (Data &data...) is a typo.
You might also want to consider using a proper parser for whatever data format this is.
I believe this is my first post here. I am teaching myself Swift and have come across some odd behavior involving the mysterious appearance of a leading " " in a print statement. I was exploring print formatting and this code is producing a leading " " in the first dashedLine printed.
Code:
var dashedLine = "-------------------------------------------------------------------"
print("a bunch of text\n", dashedLine)
print(dashedLine)
Output:
a bunch of text
-------------------------------------------------------------------
-------------------------------------------------------------------
Why the leading space before the first dashed line?
I've read the Swift 4 documentation. (In playing with "terminator" syntax at the end of a print list, I get unanticipated results, including suppression of output, depending.) I am curious as to the appearance of the leading space as my primary question.
By default, a print statement with multiple arguments prints those out with a space in between.
You can find more in Apple's documentation here.
Following on to #bajracharyas353’s answer, a solution if you’re needing to avoid this would be to combine strings using any of the methods Swift allows, like "a" + "b" or String.append, or print(String1, String2, separator: "").
As for suppression of output, I think I’ve run into the same thing with JWTs. There seems to be a pretty modest limit on output, but I could be wrong there.
Problem
The Swift.print(_ items: Any...) function prints multiple arguments separated by a space.
Solution
Use print("a bunch of text\n", dashedLine, separator: "") instead
I'm looking to create a macro in P6 which converts its argument to a string.
Here's my macro:
macro tfilter($expr) {
quasi {
my $str = Q ({{{$expr}}});
filter-sub $str;
};
}
And here is how I call it:
my #some = tfilter(age < 50);
However, when I run the program, I obtain the error:
Unable to parse expression in quote words; couldn't find final '>'
How do I fix this?
Your use case, converting some code to a string via a macro, is very reasonable. There isn't an established API for this yet (even in my head), although I have come across and thought about the same use case. It would be nice in cases such as:
assert a ** 2 + b ** 2 == c ** 2;
This assert statement macro could evaluate its expression, and if it fails, it could print it out. Printing it out requires stringifying it. (In fact, in this case, having file-and-line information would be a nice touch also.)
(Edit: 007 is a language laboratory to flesh out macros in Perl 6.)
Right now in 007 if you stringify a Q object (an AST), you get a condensed object representation of the AST itself, not the code it represents:
$ bin/007 -e='say(~quasi { 2 + 2 })'
Q::Infix::Addition {
identifier: Q::Identifier "infix:+",
lhs: Q::Literal::Int 2,
rhs: Q::Literal::Int 2
}
This is potentially more meaningful and immediate than outputting source code. Consider also the fact that it's possible to build ASTs that were never source code in the first place. (And people are expected to do this. And to mix such "synthetic Qtrees" with natural ones from programs.)
So maybe what we're looking at is a property on Q nodes called .source or something. Then we'd be able to do this:
$ bin/007 -e='say((quasi { 2 + 2 }).source)'
2 + 2
(Note: doesn't work yet.)
It's an interesting question what .source ought to output for synthetic Qtrees. Should it throw an exception? Or just output <black box source>? Or do a best-effort attempt to turn itself into stringified source?
Coming back to your original code, this line fascinates me:
my $str = Q ({{{$expr}}});
It's actually a really cogent attempt to express what you want to do (turn an AST into its string representation). But I doubt it'll ever work as-is. In the end, it's still kind of based on a source-code-as-strings kind of thinking à la C. The fundamental issue with it is that the place where you put your {{{$expr}}} (inside of a string quote environment) is not a place where an expression AST is able to go. From an AST node type perspective, it doesn't typecheck because expressions are not a subtype of quote environments.
Hope that helps!
(PS: Taking a step back, I think you're doing yourself a disservice by making filter-sub accept a string argument. What will you do with the string inside of this function? Parse it for information? In that case you'd be better off analyzing the AST, not the string.)
(PPS: Moritz++ on #perl6 points out that there's an unrelated syntax error in age < 50 that needs to be addressed. Perl 6 is picky about things being defined before they are used; macros do not change this equation much. Therefore, the Perl 6 parser is going to assume that age is a function you haven't declared yet. Then it's going to consider the < an opening quote character. Eventually it'll be disappointed that there's no >. Again, macros don't rescue you from needing to declare your variables up-front. (Though see #159 for further discussion.))
I am working on some old qbasic code. It's a mess with all the Goto statements. Am I correct that the following line will always return?
IF FLAG = 0 THEN TARGET = X: GOSUB 55000: TEMP = XI - TEMP2: RETURN
So if I understand this correctly the colon separates statements on the same line. The if only pertains to TARGET = X. The GOSUB, TEMP =, and RETURN will always execute. Correct?
Part of my confusion is because the very next line reads
IF FLAG = 1 THEN STEP = X: GOSUB 115000
And since the label to the second statement is never used in a GOTO I can't see that it would ever get executed.
Yes, I believe your assessment is correct. The colon is a statement separator that lets you have multiple statements on the same line. Assuming your subroutine at 55000 returns, this line should return as well.
I was wrong. Running this program:
if 1=2 then print "Never printed" : print "how about this?"
print "End of program"
on qb64.net prints only End of program. I assume that its grammar details are the same as Qbasic's, although it is a reverse-engineered effort.
As an aside, this code is written in a pre-QBasic style (e.g. using GOSUB and line numbers). There is a script that often came with QBasic (remline.bas, I believe it was called) that is supposed to help translate these kinds of programs to a newer style. I have never used it myself, though.