10장: 적용 가능 펑터(Applicative Functor)

Applicative 적용하기

applicative functor라는 이름은 기능적 기원을 고려할 때 매우 설명적입니다. 함수형 프로그래머들은 mappend이나 liftA4 같은 이름을 만들어내는 것으로 악명이 높은데, 이러한 이름들은 수학 실험실에서는 완벽하게 자연스럽게 보이지만 다른 맥락에서는 결정을 내리지 못하는 다스 베이더가 드라이브스루(차량 주문 창구)에서 주문하는 것만큼 명확성이 떨어집니다.

어쨌든 이 인터페이스가 제공하는 기능은 명확합니다: 펑터들을 서로 적용(apply)할 수 있는 능력입니다.

그렇다면 평범한 합리적인 개발자가 왜 이런 기능을 원할까요? 한 펑터를 다른 펑터에 적용한다는 것은 무슨 의미일까요?

이 질문에 답하기 위해 함수형 프로그래밍 여정에서 이미 접했을 상황부터 시작해보겠습니다. 동일한 타입의 두 펑터가 있고, 두 값의 인수를 사용하여 함수를 호출하려 한다고 가정해봅시다. 두 Container의 값을 더하는 것처럼 간단한 작업을 예로 들어보죠.

// We can't do this because the numbers are bottled up.
add(Container.of(2), Container.of(3));
// NaN

// Let's use our trusty map
const containerOfAdd2 = map(add, Container.of(2));
// Container(add(2))

여기 부분 적용된 함수가 내부에 있는 Container가 있습니다. 더 정확히 말하면 Container(add(2))가 있고, 여기서 add(2)를 Container(3) 내부의 3에 적용하려 합니다. 즉, 한 펑터를 다른 펑터에 적용하고자 하는 것입니다.

다행히도 이미 이 작업을 수행할 도구를 가지고 있습니다. 다음과 같이 부분 적용된 add(2)를 chain하고 map할 수 있습니다:

Container.of(2).chain(two => Container.of(3).map(add(two)));

여기서 문제는 모나드의 순차적 세계에 갇혀 있다는 점입니다. 이전 모나드가 작업을 완료할 때까지 아무것도 평가되지 않습니다. 두 개의 강력하고 독립적인 값을 가지고 있는데, 모나드의 순차적 요구를 충족시키기 위해 Container(3) 생성이 지연될 필요는 없습니다.

사실 이런 상황에서 불필요한 함수와 변수 없이 한 펑터의 내용을 다른 펑터의 값에 간결하게 적용할 수 있다면 좋을 것입니다.

병 속의 배

ap은 한 펑터의 함수 내용을 다른 펑터의 값 내용에 적용할 수 있는 함수입니다. 이 문장을 빠르게 다섯 번 말해보세요.

Container.of(add(2)).ap(Container.of(3));
// Container(5)

// all together now

Container.of(2).map(add).ap(Container.of(3));
// Container(5)

깔끔하게 해결되었습니다. 중첩된 모나딕 함수의 감옥에서 해방된 Container(3)에게 좋은 소식입니다. 이 경우 add가 첫 번째 map 중에 부분 적용되므로 커링된 add에서만 작동한다는 점을 다시 강조할 가치가 있습니다.

ap을 다음과 같이 정의할 수 있습니다:

Container.prototype.ap = function (otherContainer) {
  return otherContainer.map(this.$value);
};

기억하세요. this.$value는 함수일 것이며 다른 펑터를 받아들이므로 map만 하면 됩니다. 이렇게 해서 인터페이스 정의를 완성했습니다:

*적용 가능 펑터(applicative functor)*는 ap 메서드를 가진 포인티드 펑터입니다

포인티드(pointed) 인터페이스의 중요성에 주목하세요. 다음 예제를 통해 알 수 있듯이 여기서 핵심적입니다.

이제 여러분의 회의론(혹은 혼란과 공포)을 느끼지만, 열린 마음을 유지하세요. 이 ap은 유용함이 입증될 것입니다. 본격적으로 들어가기 전에 멋진 속성을 살펴보겠습니다.

F.of(x).map(f) === F.of(f).ap(F.of(x));

적절한 영어 표현으로, f를 매핑하는 것은 f의 펑터를 ap하는 것과 동일합니다. 또는 더 정확히 말하면, x를 컨테이너에 넣고 f를 매핑하거나 f와 x를 모두 컨테이너에 들어 올려 ap할 수 있습니다. 이를 통해 왼쪽에서 오른쪽으로 코드를 작성할 수 있습니다:

Maybe.of(add).ap(Maybe.of(2)).ap(Maybe.of(3));
// Maybe(5)

Task.of(add).ap(Task.of(2)).ap(Task.of(3));
// Task(5)

눈을 반쯤 감고 보면 일반 함수 호출의 모습을 어렵지 않게 알아볼 수 있습니다. 이 장의 후반에 포인트 프리 버전을 살펴보겠지만, 지금은 이러한 코드를 작성하는 선호되는 방법입니다. of를 사용하면 각 값이 컨테이너의 마법 같은 세계로 이동하며, 이 평행 우주에서는 각 애플리케이션이 비동기적이거나 널일 수 있고 ap은 이 환상적인 공간 내에서 함수를 적용합니다. 병 속에 모형 배를 조립하는 것과 같습니다.

예제에서 Task를 사용한 것을 보셨나요? 이것은 적용 가능 펑터가 본래의 힘을 발휘하는 주요 상황입니다. 더 깊이 있는 예제를 살펴보겠습니다.

동기화 동기부여

여행 사이트를 구축 중이고 관광 명소 목록과 지역 이벤트를 모두 검색하려 한다고 가정해봅시다. 이 각각은 별개의 독립적인 API 호출입니다.

// Http.get :: String -> Task Error HTML

const renderPage = curry((destinations, events) => { /* render page */ });

Task.of(renderPage).ap(Http.get('/destinations')).ap(Http.get('/events'));
// Task("<div>some page with dest and events</div>")

두 Http 호출은 즉시 발생하며 두 호출이 모두 해결되면 renderPage가 호출됩니다. 한 Task가 다음 작업을 시작하기 전에 완료해야 하는 모나딕 버전과 대조됩니다. 이벤트를 검색하기 위해 목적지가 필요하지 않으므로 순차적 평가로부터 자유롭습니다.

이 결과를 달성하기 위해 부분 적용을 사용하고 있으므로 renderPage가 커링되어 있어야 하며 그렇지 않으면 두 Task가 완료될 때까지 기다리지 않을 것입니다. 덧붙여 말하자면, 수동으로 이런 작업을 해본 적이 있다면 이 인터페이스의 놀라운 단순함을 높이 평가할 것입니다. 이것은 우리를 특이점에 한 걸음 더 가까이 다가가게 하는 아름다운 코드입니다.

다른 예제를 살펴보겠습니다.

// $ :: String -> IO DOM
const $ = selector => new IO(() => document.querySelector(selector));

// getVal :: String -> IO String
const getVal = compose(map(prop('value')), $);

// signIn :: String -> String -> Bool -> User
const signIn = curry((username, password, rememberMe) => { /* signing in */ });

IO.of(signIn).ap(getVal('#email')).ap(getVal('#password')).ap(IO.of(false));
// IO({ id: 3, email: 'gg@allin.com' })

signIn은 3개의 인수를 가진 커링 함수이므로 그에 따라 ap해야 합니다. 각 ap마다 signIn은 하나의 인수를 더 받아 완성되고 실행됩니다. 필요한 만큼의 인수로 이 패턴을 계속할 수 있습니다. 또 다른 주목할 점은 두 인수가 자연스럽게 IO에 있게 되는 반면 마지막 인수는 ap이 함수와 모든 인수를 동일한 타입으로 들어 올리기를 기대하므로 of의 도움을 약간 받아 IO로 들어 올려야 합니다.

형제, 리프트 할 줄 아는가?

이러한 적용 가능 호출을 포인트 프리 방식으로 작성하는 방법을 살펴보겠습니다. map이 of/ap와 동일하다는 것을 알고 있으므로 지정한 횟수만큼 ap을 수행하는 일반 함수를 작성할 수 있습니다:

const liftA2 = curry((g, f1, f2) => f1.map(g).ap(f2));

const liftA3 = curry((g, f1, f2, f3) => f1.map(g).ap(f2).ap(f3));

// liftA4, etc

liftA2는 이상한 이름입니다. 낡은 공장의 까다로운 화물 엘리베이터나 저렴한 리무진 회사의 허영심 가득한 번호판처럼 들립니다. 그러나 일단 깨닫고 나면 자명합니다: 이 조각들을 적용 가능 펑터 세계로 들어 올리는 것입니다.

처음 이 2-3-4 넌센스를 보았을 때 추악하고 불필요해 보였습니다. 결국 JavaScript에서 함수의 인자 수를 확인하고 동적으로 이를 구축할 수 있습니다. 그러나 부분적으로 liftA(N) 자체를 적용하는 것이 유용한 경우가 많으므로 인수 길이가 달라질 수 없습니다.

사용 예시를 살펴보겠습니다:

// checkEmail :: User -> Either String Email
// checkName :: User -> Either String String

const user = {
  name: 'John Doe',
  email: 'blurp_blurp',
};

//  createUser :: Email -> String -> IO User
const createUser = curry((email, name) => { /* creating... */ });

Either.of(createUser).ap(checkEmail(user)).ap(checkName(user));
// Left('invalid email')

liftA2(createUser, checkEmail(user), checkName(user));
// Left('invalid email')

createUser는 두 개의 인수를 받으므로 해당하는 liftA2를 사용합니다. 두 문장은 동일하지만 liftA2 버전에는 Either에 대한 언급이 없습니다. 특정 타입에 고정되지 않으므로 더 일반적이고 유연합니다.

이전 예제를 이 방식으로 작성해 보겠습니다:

liftA2(add, Maybe.of(2), Maybe.of(3));
// Maybe(5)

liftA2(renderPage, Http.get('/destinations'), Http.get('/events'));
// Task('<div>some page with dest and events</div>')

liftA3(signIn, getVal('#email'), getVal('#password'), IO.of(false));
// IO({ id: 3, email: 'gg@allin.com' })

연산자

Haskell, Scala, PureScript 및 Swift와 같이 사용자 정의 중위 연산자를 생성할 수 있는 언어에서는 다음과 같은 구문을 볼 수 있습니다:

-- Haskell / PureScript
add <$> Right 2 <*> Right 3

// JavaScript
map(add, Right(2)).ap(Right(3));

<$>는 map(일명 fmap)이고 <*>는 단순히 ap입니다. 이는 보다 자연스러운 함수 적용 스타일을 가능하게 하며 일부 괄호를 제거하는 데 도움이 됩니다.

공짜 캔 오프너

파생 함수에 대해 많이 이야기하지 않았습니다. 이 모든 인터페이스가 서로 구축되고 일련의 법칙을 준수하기 때문에 더 강력한 인터페이스 측면에서 약한 인터페이스를 정의할 수 있습니다.

예를 들어 적용 가능 펑터는 먼저 펑터이므로 적용 가능 인스턴스가 있으면 해당 타입에 대한 펑터를 확실히 정의할 수 있습니다.

우리가 수학적 프레임워크 내에서 작업하고 있기 때문에 이러한 완벽한 계산적 조화가 가능합니다. 모차르트도 어렸을 때 Ableton을 불법 다운로드했다 해도 이것보다 나은 것을 만들 수 없었을 것입니다.

이전에 of/ap이 map과 동일하다고 언급했습니다. 이 지식을 사용하여 map을 공짜로 정의할 수 있습니다:

// map derived from of/ap
X.prototype.map = function map(f) {
  return this.constructor.of(f).ap(this);
};

말하자면 모나드는 먹이사슬의 최상위에 있으므로 chain이 있으면 펑터와 적용 가능을 공짜로 얻습니다:

// map derived from chain
X.prototype.map = function map(f) {
  return this.chain(a => this.constructor.of(f(a)));
};

// ap derived from chain/map
X.prototype.ap = function ap(other) {
  return this.chain(f => other.map(f));
};

모나드를 정의할 수 있으면 적용 가능과 펑터 인터페이스를 모두 정의할 수 있습니다. 이 모든 캔 오프너를 공짜로 얻을 수 있다는 것은 매우 놀라운 일입니다. 심지어 타입을 검사하고 이 프로세스를 자동화할 수도 있습니다.

ap의 매력 중 일부는 작업을 동시에 실행할 수 있는 능력이므로 chain을 통해 이를 정의하면 해당 최적화가 누락됩니다. 그럼에도 불구하고 최상의 구현을 찾는 동안 즉시 작동하는 인터페이스를 갖는 것이 좋습니다.

왜 모나드만 사용하고 끝내지 않겠냐고 물을 수 있습니다. 필요한 수준의 힘으로 작업하는 것이 좋은 방법입니다. 이는 가능한 기능을 배제함으로써 인지 부하를 최소화합니다. 이러한 이유로 모나드보다 적용 가능을 선호하는 것이 좋습니다.

모나드는 아래로 중첩된 구조 덕분에 계산을 순차적으로 실행하고 변수를 할당하며 추가 실행을 중지하는 독특한 능력을 가지고 있습니다. 적용 가능이 사용될 때는 이러한 사항을 염려할 필요가 없습니다.

이제 법적 문제로 넘어가겠습니다...

법칙

우리가 탐구한 다른 수학적 구조와 마찬가지로 적용 가능 펑터는 일상적인 코드에서 의존할 수 있는 유용한 속성을 가지고 있습니다. 먼저 적용 가능은 '합성에 닫혀 있다'는 의미에서 ap이 컨테이너 타입을 변경하지 않습니다(모나드보다 선호하는 또 다른 이유). 여러 다른 효과를 가질 수 없다는 것은 아닙니다. 전체 애플리케이션 기간 동안 동일하게 유지될 것임을 알면서 타입을 쌓을 수 있습니다.

예시로 다음을 살펴보세요:

const tOfM = compose(Task.of, Maybe.of);

liftA2(liftA2(concat), tOfM('Rainy Days and Mondays'), tOfM(' always get me down'));
// Task(Maybe(Rainy Days and Mondays always get me down))

여기서는 다른 타입이 혼합되는 것에 대해 걱정할 필요가 없습니다.

이제 우리가 좋아하는 범주 법칙인 *동일성(identity)*을 살펴볼 시간입니다:

동일성

// identity
A.of(id).ap(v) === v;

펑터 내부에서 id를 적용해도 v의 값은 변경되지 않아야 합니다. 예를 들어:

const v = Identity.of('Pillow Pets');
Identity.of(id).ap(v) === v;

Identity.of(id)는 그 무의미함에 웃음이 나옵니다. 어쨌든 흥미로운 점은 이미 확립한 것처럼 of/ap이 map과 동일하므로 이 법칙은 펑터 동일성에서 직접적으로 이어집니다: map(id) === id.

이러한 법칙을 사용함으로써 얻는 아름다움은 군대식 유치원 체육 교사처럼 모든 인터페이스가 잘 협력하도록 강제한다는 점입니다.

동형사상

// homomorphism
A.of(f).ap(A.of(x)) === A.of(f(x));

*동형사상(homomorphism)*은 단순히 구조를 보존하는 사상입니다. 실제로 펑터는 사상에 따라 원래 범주의 구조를 보존하므로 범주 간 동형사상입니다.

우리는 단지 일반 함수와 값을 컨테이너에 넣고 거기서 계산을 실행하고 있으므로 전체를 컨테이너 내부에 적용하든(방정식의 왼쪽) 외부에 적용한 다음 거기에 배치하든(오른쪽) 동일한 결과를 얻게 될 것임은 놀랄 일이 아닙니다.

간단한 예시:

Either.of(toUpperCase).ap(Either.of('oreos')) === Either.of(toUpperCase('oreos'));

교환법칙

*교환법칙(interchange)*은 함수를 ap의 왼쪽 또는 오른쪽으로 들어 올리는 것이 중요하지 않다는 것을 나타냅니다.

// interchange
v.ap(A.of(x)) === A.of(f => f(x)).ap(v);

예시입니다:

const v = Task.of(reverse);
const x = 'Sparklehorse';

v.ap(Task.of(x)) === Task.of(f => f(x)).ap(v);

합성

마지막으로 합성(composition)은 컨테이너 내부에서 적용할 때 표준 함수 합성이 유지되는지 확인하는 방법일 뿐입니다.

// composition
A.of(compose).ap(u).ap(v).ap(w) === u.ap(v.ap(w));

const u = IO.of(toUpperCase);
const v = IO.of(concat('& beyond'));
const w = IO.of('blood bath ');

IO.of(compose).ap(u).ap(v).ap(w) === u.ap(v.ap(w));

요약

적용 가능의 좋은 사용 사례는 여러 펑터 인수가 있을 때입니다. 이들은 펑터 세계 내에서 함수를 인수에 적용할 수 있는 능력을 제공합니다. 모나드로도 할 수 있지만 모나드 특유의 기능이 필요하지 않을 때는 적용 가능 펑터를 선호해야 합니다.

컨테이너 API에 대한 설명을 거의 마쳤습니다. map, chain, 그리고 이제 ap 함수를 사용하는 방법을 배웠습니다. 다음 장에서는 여러 펑터를 더 잘 작업하고 구조적인 방식으로 분해하는 방법을 배우겠습니다.

11장: 자연스럽게 다시 변환하기

연습문제

연습해 보세요!

Maybe와 ap을 사용하여 두 개의 null 가능성이 있는 숫자를 더하는 함수를 작성하세요. // safeAdd :: Maybe Number -> Maybe Number -> Maybe Number const safeAdd = undefined;

---

연습해 보세요!

ap 대신 liftA2를 사용하도록 exercise_b의 safeAdd를 재작성하세요. // safeAdd :: Maybe Number -> Maybe Number -> Maybe Number const safeAdd = undefined;

---

다음 연습문제를 위해 다음 도우미 함수를 고려하세요:

const localStorage = {  
  player1: { id:1, name: 'Albert' },  
  player2: { id:2, name: 'Theresa' },  
};  
  
// getFromCache :: String -> IO User  
const getFromCache = x => new IO(() => localStorage[x]);  
  
// game :: User -> User -> String  
const game = curry((p1, p2) => `${p1.name} vs ${p2.name}`);

연습해 보세요!

캐시에서 player1과 player2를 가져와 게임을 시작하는 IO를 작성하세요. // startGame :: IO String const startGame = undefined;