6.2.1. Failure with 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. Exceptions🔗

Except의 모나드 변환기 버전은 Option의 모나드 변환기 버전과 매우 비슷하다. m α 타입의 모나드 동작에 ε 타입의 예외를 추가하려면 α에 예외를 추가해 m (Except ε α) 타입으로 만들면 된다:

OptionT는 OptionT.mk와 OptionT.run 함수로 타입 검사기가 올바른 Monad 인스턴스를 선택하도록 이끈다. 이 기법은 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 인스턴스와 함께 제어 구조로 사용한다. 따라서 Except ε 동작을 ExceptT ε m으로, 기반 모나드 m의 동작도 함께 끌어 올리는 것이 합리적이다. Except 동작을 ExceptT 동작으로 끌어 올릴 때는 m의 pure로 감싼다. 예외 효과만 있는 동작은 m 모나드의 효과를 가질 수 없기 때문이다:

m의 동작에는 예외가 없으므로 그 값을 Except.ok으로 감싸야 한다. Functor가 Monad의 상위 클래스라는 사실을 이용하면 이를 수행할 수 있다. 즉 모든 모나드 계산의 결과에 함수를 적용할 때 Functor.map을 사용할 수 있다:

6.2.3. State🔗

가변 상태의 시뮬레이션은 모나드 동작이 시작 상태를 인수로 받아 결과와 함께 최종 상태를 반환하게 해 모나드에 추가한다. 상태 모나드의 bind 연산자는 한 동작의 최종 상태를 다음 동작의 인수로 제공해 프로그램 전체에 상태를 전달한다. 이 패턴은 모나드 변환기로도 표현할 수 있다:

다시 말해 모나드 인스턴스는 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 Classes and The Functions🔗

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

이런 경우를 위해 추가 정보가 출력 매개변수가 아닌 타입 클래스도 있다. 이 타입 클래스 버전들은 이름에 Of라는 단어를 사용한다. 예를 들어 MonadStateOf는 MonadState와 비슷하지만 outParam 수정자가 없다.

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

상태 모나드의 상태 타입이 outParam이면 각 모나드는 상태를 한 종류만 가질 수 있다. 이는 타입 추론을 개선해 더 많은 상황에서 상태 타입을 추론할 수 있다는 점에서 편리하다. 그러나 StateT를 여러 번 사용해 만든 모나드는 유용한 MonadState 인스턴스를 제공할 수 없다는 점에서 불편하다. 반면 MonadStateOf를 사용하면 Lean은 상태 타입을 알 수 있을 때 이를 고려해 사용할 인스턴스를 선택하므로, 하나의 모나드가 여러 상태 타입을 제공할 수 있다. 단점은 상태 타입이 충분히 명시되지 않았을 때 결과 인스턴스가 의도한 인스턴스가 아닐 수 있어 혼란스러운 오류 메시지가 발생한다는 것이다.

마찬가지로 추가 정보의 타입을 암시적 인자가 아니라 명시적(explicit) 인자로 받는 타입 클래스 메서드 버전도 있다. MonadStateOf에는 다음 타입의 getThe가 있다.

그리고 다음 타입의 modifyThe도 있다.

새 상태의 타입만으로 어떤 주변 상태 모나드 변환기를 사용할지 결정할 수 있으므로 setThe는 없다.

Lean 표준 라이브러리에는 Of가 없는 클래스 버전의 인스턴스가 Of가 있는 버전의 인스턴스로 정의되어 있다. 즉 Of 버전을 구현하면 두 버전의 구현을 모두 얻는다. 일반적으로 Of 버전을 구현한 다음 클래스의 Of가 없는 버전으로 프로그램을 작성하고, 출력 매개변수가 불편해지면 Of 버전으로 전환하는 것이 좋다.

6.2.5. Transformers and Id🔗

항등 모나드 Id는 어떤 이유로 모나드를 요구하지만 실제로는 모나드가 필요하지 않은 문맥에서 사용할 수 있는, 아무 효과도 없는 모나드다. Id의 또 다른 용도는 모나드 변환기 스택의 바닥 역할을 하는 것이다. 예를 들어 StateT σ Id는 State σ와 똑같이 작동한다.

6.2.6. Exercises🔗

  Viewed 38 files in 5 directories.