There's a very narrow semantic difference between the two, and I find myself wondering why both options exist. Are they in any way different functionally, or is one likely just an alias of the other?
There is no difference at all. They are, in fact, the very same method.
To the compiler,
myQueue.async(execute: { foo() })
is exactly the same as
myQueue.async {
foo()
}
When the last argument of any function or method is a function, you can pass that argument as a trailing closure instead of passing it inside the argument list. This is done in order to make higher-order functions such as DispatchQueue.async feel more like part of the language, reduce syntactic overhead and ease the creation of domain-specific languages.
There's documentation on trailing closure syntax here.
And by the way, the idiomatic way to write my first example would be:
myQueue.async(execute: foo)
What you're referring to is called trailing closure syntax. It's a syntactic sugar for making closures easier to work with.
There are many other kinds of syntactic sugar features that pertain to closures, which I cover in my answer here.
As always, I highly recommend the Swift Language guide, which does a great job at explaining the basics like this.
Related
In thinking about blocks, I've always wondered why the
thingers.each { |thing|
example is actually interesting (since there's another, built-in way to do it). In most modern languages there's a way to iterate through a collection and apply some inline code to it. But then I thought that maybe the for (Thing thing : things) { syntax is really a type of block, even in languages like Java-sans-Groovy where there are none.
So the question is: Is a for-each loop a type of block, albeit with a fixed syntax?
Edit: This question is confusing but yet got some attention so I can't delete it. Anyway... by Blocks I mean "closures" and not just code blocks. As far as why I tagged this as language agnostic is that I'm not interested in how a for-each is implemented under-the-hood. I'm more interested in whether, from a programmer's perspective, a for-each could be considered a freebie closure in languages that doesn't have them, like Java.
This is most definitely not language agnostic (as it is tagged).
For example, in Ruby, you are passing a closure or block to the .each method. The semantics are defined by the language.
In C#, foreach compiles to a call to IEnumerable.GetEnumerator and the use of the IEnumerator.MoveNext method. It just depends on the language.
EDIT:
Edit: This question is confusing but yet got some attention so I can't delete it. Anyway... by Blocks I mean "closures" and not just code blocks. As far as why I tagged this as language agnostic is that I'm not interested in how a for-each is implemented under-the-hood. I'm more interested in whether, from a programmer's perspective, a for-each could be considered a freebie closure in languages that doesn't have them, like Java.
No, you are thinking only of one use case for a closure. You can't pass a control structure to a method as you can a closure in some languages. A control structure is not a first class first class data type like a closure is in some languages. In the case of "run this code on each object in a collection" yes, they are semantically similar. However, that it only one example of what you can do with a closure.
You say that you w
As Swangren says, this question is not language agnostic as tagged. Not unless there's some general "IT theory" definition of a "block" that I'm not aware of.
In Java, a "block" is a series of statements enclosed in { }. So a FOR statement normally operates on a block. The purpose of a block is to delimit what is included within certain language constructs, like IF statements and loops.
I believe C and C++ have similar definitions of a "block".
Most languages have a similar concept.
Not sure if this helps.
foreach ($foo as $bar) {
$baz = 'Hello, World!';
}
echo $baz; // 'Hello, World!', "leaked" from the "closure"
Nope, sorry, foreach loops are not lambdas, closures or functions in languages where they aren't explicitly such.
Please elaborate. My definition of a "block" is a section of code that's grouped together. In this case there's a lot of stuff in Java can be a "block"
If you are talking about ruby-style blocks, which are really closures, then Java doesn't support them (not in any sane fashion anyways). foreach is a control structure, and behaves differently from closures.
On your updated question: It's easy to use closures as control structures, but the other way around is harder, if not impossible. A closure is a first class function, which allows you to do some pretty cool stuff with it - not just iterating through elements.
Seems like it's inconsistent in the lists module. For example, split has the number as the first argument and the list as the second, but sublists has the list as the first argument and the len as the second argument.
OK, a little history as I remember it and some principles behind my style.
As Christian has said the libraries evolved and tended to get the argument order and feel from the impulses we were getting just then. So for example the reason why element/setelement have the argument order they do is because it matches the arg/3 predicate in Prolog; logical then but not now. Often we would have the thing being worked on first, but unfortunately not always. This is often a good choice as it allows "optional" arguments to be conveniently added to the end; for example string:substr/2/3. Functions with the thing as the last argument were often influenced by functional languages with currying, for example Haskell, where it is very easy to use currying and partial evaluation to build specific functions which can then be applied to the thing. This is very noticeable in the higher order functions in lists.
The only influence we didn't have was from the OO world. :-)
Usually we at least managed to be consistent within a module, but not always. See lists again. We did try to have some consistency, so the argument order in the higher order functions in dict/sets match those of the corresponding functions in lists.
The problem was also aggravated by the fact that we, especially me, had a rather cavalier attitude to libraries. I just did not see them as a selling point for the language, so I wasn't that worried about it. "If you want a library which does something then you just write it" was my motto. This meant that my libraries were structured, just not always with the same structure. :-) That was how many of the initial libraries came about.
This, of course, creates unnecessary confusion and breaks the law of least astonishment, but we have not been able to do anything about it. Any suggestions of revising the modules have always been met with a resounding "no".
My own personal style is a usually structured, though I don't know if it conforms to any written guidelines or standards.
I generally have the thing or things I am working on as the first arguments, or at least very close to the beginning; the order depends on what feels best. If there is a global state which is chained through the whole module, which there usually is, it is placed as the last argument and given a very descriptive name like St0, St1, ... (I belong to the church of short variable names). Arguments which are chained through functions (both input and output) I try to keep the same argument order as return order. This makes it much easier to see the structure of the code. Apart from that I try to group together arguments which belong together. Also, where possible, I try to preserve the same argument order throughout a whole module.
None of this is very revolutionary, but I find if you keep a consistent style then it is one less thing to worry about and it makes your code feel better and generally be more readable. Also I will actually rewrite code if the argument order feels wrong.
A small example which may help:
fubar({f,A0,B0}, Arg2, Ch0, Arg4, St0) ->
{A1,Ch1,St1} = foo(A0, Arg2, Ch0, St0),
{B1,Ch2,St2} = bar(B0, Arg4, Ch1, St1),
Res = baz(A1, B1),
{Res,Ch2,St2}.
Here Ch is a local chained through variable while St is a more global state. Check out the code on github for LFE, especially the compiler, if you want a longer example.
This became much longer than it should have been, sorry.
P.S. I used the word thing instead of object to avoid confusion about what I was talking.
No, there is no consistently-used idiom in the sense that you mean.
However, there are some useful relevant hints that apply especially when you're going to be making deeply recursive calls. For instance, keeping whichever arguments will remain unchanged during tail calls in the same order/position in the argument list allows the virtual machine to make some very nice optimizations.
I have this code
def errorMap = validateParams(params)
if (errorMap) {
flash.errorMap = errorMap
return
}
My question is this: Can I combine the assignment in line #1 and evaluation of the condition in line#2 to make a one liner like the following:
if (flash.errorMap = validateParams(params)) {
return
}
Is it a bad practice to do this?
Thanks
Vijay Kumar
We are indoctrinated in C-like languages that single-equals "=" should look like a typo in an if statement. Using a syntax where the single-equals is doing what you mean makes it harder to spot the typo cases.
Although you certainly can do this, my own two cents is that it's usually a bad practice. It's terse, but your if statement is now relying on the evaluation of the assignment, which may not be immediately obvious when you come back and revisit this code months later.
In my opinion it's a very good practice. Calling the function and testing its return value should be thought of together, and putting them together in the source code helps to do that. If you do this habitually, it becomes essentially impossible to accidentally call the function but leave out the code check whether it succeeded.
If this is C++ or C# code, you can combine assignment and evaluation of condition. Just be absolutely certain to avoid using assignment (=) instead of comparison (==). You can waste hours figuring it out.
Also, be careful about using conditions that modify their parameters.
For example,
if (x++ > 100) doStuff()
vs
if (x+1 > 100) doStuff()
While the code in isolation looks precise and elegant, an assignment operator (=) inside the if-clause is more likely to be overlooked as the more prevalent comparison operator (==), which will then cause you more problems.
I wouldn't use it in practice. It could make a good multiple-choice question though.
i am kinda confused reading the definition between the two. Can they actually intersect in terms of definition? or am i completely lost? Thanks.
Closures, as the word tends to be used, are just functions (or blocks of code, if you like) that you can treat like a piece of data and pass to other functions, etc. (the "closed" bit is that wherever you eventually call it, it behaves just as it would if you called it where it was originally defined). A monad is (roughly) more like a context in which functions can be chained together sequentially, and controls how data is passed from one function to the next.
They're quite different, although monads will often use closures to capture logic.
Personally I would try to get solid on the definition of closures (essentially a piece of logic which also captures its environment, i.e. local variables etc) before worrying about monads. They can come later :)
There are various questions about closures on Stack Overflow - the best one to help you will depend on what platform you're working on. For instance, there's:
What are closures in .NET?
Function pointers, closures and lambda
Personally I'm only just beginning to "grok" monads (thanks to the book I'm helping out on). One day I'll get round to writing an article about them, when I feel I understand them well enough :)
A "closure" is an object comprising 1) a function, and 2) the values of its free variables where it's constructed.
A "monad" is a class of functions that can be composed in a certain way, i.e. by using associated bind and return higher-order function operators, to produce other functions.
I think monads are a little more complicated than closures because closures are just blocks of code that remember something from the point of their definitions and monads are a construct for "twisting" the usual function composition operation.
I've read through some of the post on here about closures and currying but I feel like I didn't find the answer. So what's the differences and possibly the similarities of closures and currying? Thanks for the help :)
Currying is really a mathematical concept first and foremost. It's the just observation that for any n-ary function f: S0×...Sn → R, you can define a new function fprime (just found a markdown bug!) with n-1 parameters where that first parameter is replaced by a constant. So, if you have a function add(a,b), you can define a new function add1(b) as
add1(b) ::= add(1, b)
...reading "::=" as "is defined to be."
A closure is more of a programming concept. (Of course, everything in programming is a mathematical concept as well, but closures became interesting because of programming.) When you construct a closure, you bind one or more variables; you're creating a chunk of code that has some variables tied to it.
The relationship is that you can use a closure in order to implement currying: you could build your add1 function above by making a closure in which that first parameter is bound to 1.