6.2.1. OptionT를 이용한 실패🔗

Option 모나드로 표현되는 실패와 Except 모나드로 표현되는 예외에는 모두 그에 대응하는 트랜스포머가 있습니다. Option의 경우, 모나드가 원래 α 타입의 값을 담았을 자리에 Option α 타입의 값을 담게 하면 그 모나드에 실패를 추가할 수 있습니다. 예를 들어, IO (Option α)는 α 타입의 값을 항상 반환하지는 않는 IO 액션을 나타냅니다. 이로부터 모나드 트랜스포머 OptionT의 정의를 다음과 같이 떠올릴 수 있습니다:

OptionT가 실제로 쓰이는 예로, 사용자에게 질문을 하는 프로그램을 생각해 봅시다. getSomeInput 함수는 입력을 한 줄 요청한 뒤 양쪽 끝의 공백을 제거합니다. 공백을 제거한 입력이 비어 있지 않으면 그 입력을 반환하지만, 공백이 아닌 문자가 하나도 없으면 함수는 실패합니다.

이 애플리케이션은 사용자의 이름과 가장 좋아하는 딱정벌레 종을 함께 기록합니다:

사용자에게 입력을 요청하는 코드도 IO만 사용하는 함수보다 더 장황하지 않습니다.

하지만 이 함수는 단순히 IO가 아니라 OptionT IO 컨텍스트에서 실행되므로, getSomeInput의 첫 번째 호출이 실패하면 getUserInfo 전체가 실패하며, 제어 흐름은 딱정벌레에 관한 질문에 결코 도달하지 않습니다. 메인 함수인 interact는 순수한 IO 컨텍스트에서 getUserInfo를 호출하므로, 내부의 Option에 대해 매칭하여 호출이 성공했는지 실패했는지 확인할 수 있습니다:

Application type mismatch: The argument
  some x
has type
  Option α✝
but is expected to have type
  α✝
in the application
  pure (some x)

6.2.2. 예외🔗

Except의 모나드 트랜스포머 버전은 Option의 모나드 트랜스포머 버전과 매우 비슷합니다. m α 타입의 모나드 액션에 ε 타입의 예외를 추가하려면 α에 예외를 추가하면 되며, 그 결과 m (Except ε α) 타입이 됩니다:

OptionT는 타입 검사기가 올바른 Monad 인스턴스를 찾도록 이끄는 OptionT.mk 함수와 OptionT.run 함수를 제공합니다. 이 기법은 ExceptT에도 유용합니다:

ExceptT의 Monad 인스턴스도 OptionT의 인스턴스와 매우 비슷합니다. 유일한 차이점은 none 대신 특정 오류 값을 전파한다는 것입니다:

ExceptT.mk와 ExceptT.run의 타입 시그니처에는 미묘한 세부 사항이 있습니다. 바로 α와 ε의 유니버스 레벨을 명시적으로 표기한다는 점입니다. 이를 명시적으로 표기하지 않으면 Lean은 이 둘이 서로 다른 다형적 유니버스 변수를 갖는 더 일반적인 타입 시그니처를 생성합니다. 그러나 ExceptT의 정의는 이 둘이 같은 유니버스에 있을 것을 요구하는데, 둘 다 m의 인자로 주어질 수 있기 때문입니다. 이로 인해 Monad 인스턴스에서 유니버스 레벨 해결기가 올바른 해를 찾지 못하는 문제가 발생할 수 있습니다:

stuck at solving universe constraint
  max ?u.26 ?u.27 =?= u
while trying to unify
  ExceptT ε m β✝ : Type v
with
  ExceptT.{max ?u.27 ?u.26, v} ε m β✝ : Type v

이런 종류의 오류 메시지는 대개 제약이 부족한 유니버스 변수 때문에 발생합니다. 원인을 진단하기는 까다로울 수 있지만, 어떤 정의에서는 재사용되면서 다른 정의에서는 재사용되지 않는 유니버스 변수를 찾아보는 것이 좋은 첫 단계입니다.

Option과 달리 Except 데이터 타입은 보통 자료 구조로 사용되지 않습니다. 이 타입은 항상 Monad 인스턴스와 함께 제어 구조로 사용됩니다. 따라서 기반 모나드 m의 액션뿐만 아니라 Except ε 액션도 ExceptT ε m으로 리프트하는 것이 합리적입니다. Except 액션을 ExceptT 액션으로 리프트하는 것은 해당 액션을 m의 pure로 감싸서 이루어집니다. 예외 효과만 가진 액션은 모나드 m의 효과를 전혀 가질 수 없기 때문입니다:

m의 액션에는 예외가 전혀 들어 있지 않으므로, 그 값은 Except.ok로 감싸야 합니다. 이는 Functor가 Monad의 상위 클래스라는 사실을 이용하여 해결할 수 있습니다. 즉, 어떤 모나드 계산이든 그 결과에 함수를 적용하는 일은 Functor.map으로 할 수 있습니다:

6.2.3. 상태🔗

모나드 액션이 시작 상태를 인자로 받고 결과와 함께 최종 상태를 반환하도록 하면 모나드에 가변 상태의 시뮬레이션을 추가할 수 있습니다. 상태 모나드의 바인드 연산자는 한 액션의 최종 상태를 다음 액션의 인자로 넘겨, 상태를 프로그램 전체에 걸쳐 이어 나갑니다. 이 패턴은 모나드 트랜스포머로도 표현할 수 있습니다:

이번에도 모나드 인스턴스는 State의 인스턴스와 매우 비슷합니다. 유일한 차이점은 입력 상태와 출력 상태를 순수한 코드로 다루지 않고, 기반 모나드 안에서 전달하고 반환한다는 것입니다:

이에 대응하는 타입 클래스에는 get 메서드와 set 메서드가 있습니다. get과 set의 한 가지 단점은 상태를 갱신할 때 잘못된 상태를 set하기가 너무 쉬워진다는 점입니다. 이는 상태를 가져와 갱신한 뒤 갱신된 상태를 저장하는 것이 일부 프로그램을 작성하는 자연스러운 방식이기 때문입니다. 예를 들어, 다음 프로그램은 문자열에서 발음 구별 기호가 없는 영어 모음과 자음의 개수를 셉니다:

set st' 대신 set st라고 잘못 쓰기가 매우 쉽습니다. 큰 프로그램에서는 이런 종류의 실수가 원인을 진단하기 어려운 버그로 이어질 수 있습니다.

get 호출에 중첩된 액션을 사용하면 이 문제는 해결할 수 있지만, 이런 종류의 문제를 모두 해결할 수는 없습니다. 예를 들어, 어떤 함수는 구조체의 다른 두 필드 값을 바탕으로 한 필드를 갱신할 수 있습니다. 이 경우에는 get을 중첩된 액션으로 두 번 따로 호출해야 합니다. Lean 컴파일러에는 값에 대한 참조가 하나뿐일 때만 효과를 발휘하는 최적화가 들어 있으므로, 상태에 대한 참조를 중복시키면 코드가 상당히 느려질 수 있습니다. 잠재적인 성능 문제와 잠재적인 버그는 모두 함수를 사용해 상태를 변환하는 modify를 사용하면 피할 수 있습니다:

이 타입 클래스에는 modify와 비슷한 modifyGet이라는 함수가 있습니다. 이 함수를 사용하면 반환값을 계산하는 일과 이전 상태를 변환하는 일을 한 단계에서 함께 처리할 수 있습니다. 이 함수는 첫 번째 요소가 반환값이고 두 번째 요소가 새 상태인 쌍을 반환합니다. modify는 modifyGet에서 사용하는 쌍에 Unit의 생성자를 추가할 뿐입니다:

MonadState의 정의는 다음과 같습니다.

PUnit은 Unit 타입의 유니버스 다형적 버전으로, Type 대신 Type u에 속할 수 있습니다. get과 set을 이용해 modifyGet의 기본 구현을 제공할 수는 있지만, 그렇게 하면 애초에 modifyGet을 유용하게 만드는 최적화를 적용할 수 없으므로 이 메서드는 쓸모가 없어집니다.

6.2.4. Of 클래스와 The 함수🔗

지금까지 MonadExcept의 예외 타입이나 MonadState의 상태 타입처럼 추가 정보를 받는 모나드 타입 클래스는 모두 그 추가 정보의 타입을 출력 매개변수로 두었습니다. 간단한 프로그램에서는 이 방식이 대체로 편리합니다. StateT, ReaderT, ExceptT를 각각 한 번씩 조합한 모나드에는 상태 타입, 환경 타입, 예외 타입이 하나씩만 있기 때문입니다. 그러나 모나드가 복잡해지면 여러 상태 타입이나 여러 오류 타입이 관여할 수 있습니다. 이런 경우에 출력 매개변수를 사용하면 같은 do 블록 안에서 두 상태를 모두 대상으로 삼을 수 없습니다.

이러한 경우를 위해, 추가 정보가 출력 매개변수가 아닌 타입 클래스들이 별도로 존재합니다. 이러한 버전의 타입 클래스는 이름에 Of라는 단어를 사용합니다. 예를 들어, MonadStateOf는 MonadState와 비슷하지만 outParam 수식어가 없습니다.

이 클래스들은 각각의 상태, 환경, 예외 타입에 outParam 대신 semiOutParam을 사용합니다. outParam과 마찬가지로 semiOutParam도 Lean이 인스턴스 검색을 시작하기 전에 알려져 있을 필요가 없습니다. 하지만 중요한 차이가 있습니다. outParam은 인스턴스 검색 중에 무시되므로 진정한 의미의 출력입니다. 검색 전에 outParam이 이미 알려져 있다면, Lean은 검색 결과가 알려진 값과 같은지만 확인합니다. 반면에 검색을 시작하기 전에 알려진 semiOutParam은 입력 매개변수와 마찬가지로 후보를 좁히는 데 사용할 수 있습니다.

상태 모나드의 상태 타입이 outParam이면 각 모나드는 최대 한 가지 타입의 상태만 가질 수 있습니다. 이는 타입 추론을 개선하므로 편리합니다. 더 많은 상황에서 상태 타입을 추론할 수 있기 때문입니다. 하지만 이는 불편하기도 합니다. StateT를 여러 번 사용하여 만든 모나드는 유용한 MonadState 인스턴스를 제공할 수 없기 때문입니다. 반면 MonadStateOf를 사용하면 Lean은 어떤 인스턴스를 사용할지 선택할 때 상태 타입을 알 수 있으면 그 타입을 고려합니다. 따라서 하나의 모나드가 여러 타입의 상태를 제공할 수 있습니다. 이 방식의 단점은 상태 타입이 충분히 명시적으로 지정되지 않으면 선택된 인스턴스가 의도한 것과 다를 수 있다는 점이며, 이로 인해 이해하기 어려운 오류 메시지가 발생할 수 있습니다.

마찬가지로, 추가 정보의 타입을 암시적 인자가 아닌 명시적 인자로 받는 타입 클래스 메서드 버전도 있습니다. MonadStateOf의 경우, 다음과 같은 타입을 갖는 getThe가 있으며

그리고 다음 타입을 갖는 modifyThe

새 상태의 타입만으로도 바깥의 어떤 상태 모나드 트랜스포머를 사용할지 결정할 수 있으므로 setThe는 존재하지 않습니다.

Lean 표준 라이브러리에는 Of가 붙지 않은 버전의 클래스 인스턴스가 Of가 붙은 버전의 인스턴스를 바탕으로 정의되어 있습니다. 다시 말해, Of 버전을 구현하면 두 버전의 구현을 모두 얻을 수 있습니다. 일반적으로는 Of 버전을 구현한 다음 Of가 붙지 않은 버전의 클래스를 사용하여 프로그램을 작성하기 시작하고, 출력 매개변수가 불편해지면 Of 버전으로 전환하는 것이 좋습니다.

6.2.5. 트랜스포머와 Id🔗

항등 모나드 Id는 효과가 전혀 없는 모나드로, 어떤 이유로 모나드를 요구하지만 실제로는 모나드가 필요하지 않은 맥락에서 사용됩니다. Id의 또 다른 용도는 모나드 트랜스포머 스택의 맨 아래 역할을 하는 것입니다. 예를 들어, StateT σ Id는 State σ와 똑같이 동작합니다.

6.2.6. 연습 문제🔗

  Viewed 38 files in 5 directories.