TheDet (49) [Avatar] Offline
Hello Josh,

when I recently came to the paragraph titled "using several potential unitialized variables to construct another variable" (D'oh, what a headline!), I got the impression that "lifting" is a too important topic/term to be hidden so deep in the "advanced option techniques" chapter.

The term should be more prominent, perhaps as part of the headline, so that it will be better findable on one hand, resp. sticking better in the reader's memory on the other.

For someone not grown up in FP -and esp. non native english readers- it is often not so easy to determine if a vocabulary is only some lesser known term or if it states a basic concept of the domain. I think "lifting" is the latter in FP, and you can implicitly communicate that to the reader by presenting the word in a more prominent way.

Hope I could make clear what I mean.

joshua.suereth (60) [Avatar] Offline
Re: Ch 2.4.1 Adv. Option tech. / p46 : Lifting
Great pickup on lifting!

It actually receives it's own section in Chapter 11 that refers back to Chapter 2. In fact, a lot of those 'advanced option techniques' are really fundamental FP 'patterns' in disguise (combinators, lifting, monads, etc.) smilie.

I'll try to call more attention to it in Chapter 2, as well as probably having a reference to more information in Chapter 11.
joshua.suereth (60) [Avatar] Offline
Re: Ch 2.4.1 Adv. Option tech. / p46 : Lifting
As another aside, you should check out Scalaz's Applicative builder ( the |@| operator).

You can define the following:

def connection(url: Option[String], user: Option[String], pw: Option[String]) =
(url |@| user |@| pw)(DriverManager.getConnection)

This is known as the 'applicative style'. Again, it's a great way to delineate functions that are 'pure' and make 'walls' of defense (Monads) and lift the pure functions to work with the Monads.