partially applied function

How to use partially applied functions in Scala

Problem: You want to eliminate repetitively passing variables into a Scala function by (a) passing common variables into the function to (b) create a new function that’s pre-loaded with those values, and then (c) use the new function, passing it only the unique variables it needs.

Solution: The classic example of a partially applied function begins with a simple sum function:

This is a page from my book, Functional Programming, Simplified

Partially-Applied Functions (and Currying) in Scala


My motivations for writing this lesson are a little different than usual. Typically I think, “You’ll want to know this feature so you can use it like ___,” but the first motivation for this lesson goes like this: You’ll want to know about the concept of “currying” because experienced FP developers talk about it a lot, especially if they have Haskell programming experience. (I did mention that Haskell was named after Haskell Curry, didn’t I?)

How curried functions and partially-applied functions compile in Scala

Table of Contents1 - A curried function test class2 - Result: The bytecode is the same3 - Be careful looking at -Xprint output4 - Final decompiled source code5 - scalac Xprint parser phases6 - Summary

This morning I was curious about how Scala curried functions and partially-applied functions are really compiled at a bytecode level.

Prior to that, I wrote this post that Higher order functions are the Haskell experience — which is also implicitly about curried functions — and it got me thinking about Scala, in particular why we might use one function syntax versus another, i.e., why would I use this syntax:


(this space left blank for the ToC over there --> )

An anonymous class example in Scala

Sometimes I get away from writing Scala for a while, and when I come back to it I see a piece of code that looks like this following example and I wonder, “What is Foo, and how does this code work?”: