sure, it's fine to do that in the interest of abstraction, but then don't complain about "performance issues" 
Remember that the anonymous function is created new every time you call the block (because it's assigned to a temporary variable), rather than just once when you define it as a permanent block. This makes it very inefficient in situations that rely on rapid successions of running the block inside an animation loop.
I think there's a classic teachable moment here about the tradeoff between expressive elegance and execution efficiency. Expressive abstraction is wonderful, because it dramatically speeds up development turnaround. You get much more done in a shorter time. Or, as my favorite LISP song says "God had a deadline, so he wrote it all in Lisp" (Eternal Flame - GNU Project - Free Software Foundation).
Code that runs fast is often full of optimizations that are hard to understand, repetitive, and terrible to maintain. To make something run fast the secret is to literally make it "do less". Often that involves more code that ends up doing less than elegant code. For example, using a variable to remember the result of a function, so you can just reuse what you've already computed before instead of calling the function again is the secret of all caching. This gets to be very complicated very quickly, because you're introducing state to what used to be "pure", and you'll need to write more code that figures out when to invalidate the cache. Suddenly there are a lot more places where things can (and will!) go wrong, that have side effects you didn't consider and bugs that have nothing to do with the feature you're working on. And - worst of all - you'll have all the mathematician hotshots snickering at your oafish, clumsy code. But when it's all working it'll be super fast, albeit very hard for others and your later self to build upon.
Hardcore "game" devs will likewise snicker at the highlevel programming languages, claiming that their allegedly "simple" imperative ones are much more efficient and "faster" than those highfalutin' scripting ones. Their code will be full of things like a giant "game loop" in which they'll explicitly poll for the state of individual keys instead of listening to events. They'll use lots of global variables to cache state that different parts of what looks like spaghetti code all access, and you're going to have a hard time dissecting where in code which feature is defined, because it'll all be intermingled into one big mesh.
This is, btw, one of the reasons why I'm not all that convinced that "making games" is the ultimate motivational activity for budding programmers anymore. Making good games that are fun to play almost always encourages, if not requires, a specialized programming style geared towards less abstraction and special-cased optimizations. But I'm digressing...
