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에도 유용합니다:

Monad 인스턴스는 ExceptT에 대해서도 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의 것과 매우 유사합니다. 유일한 차이점은 입력 상태와 출력 상태가 순수 코드로 전달되는 것이 아니라, 기반 모나드에서 전달되고 반환된다는 것입니다:

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

set st' 대신 set st를 작성하는 실수를 저지르기가 매우 쉬울 것입니다. 대규모 프로그램에서는 이런 종류의 실수가 진단하기 어려운 버그로 이어질 수 있습니다.

get 호출에 중첩 액션을 사용하면 이 문제를 해결할 수 있겠지만, 그런 모든 문제를 해결할 수는 없습니다. 예를 들어, 어떤 함수는 다른 두 필드의 값을 기반으로 구조체의 한 필드를 업데이트할 수 있습니다. 이렇게 하려면 get에 대한 중첩 액션 호출을 두 번 별도로 수행해야 합니다. Lean 컴파일러에는 어떤 값에 대한 참조가 하나뿐일 때만 효과를 발휘하는 최적화가 포함되어 있으므로, 상태에 대한 참조를 복제하면 코드가 상당히 느려질 수 있습니다. 잠재적인 성능 문제와 잠재적인 버그는 모두 상태를 함수를 사용해 변환하는 modify를 사용함으로써 해결할 수 있습니다:

이 타입 클래스는 modify와 유사한 modifyGet이라는 함수를 포함하는데, 이 함수를 사용하면 반환값을 계산하는 동시에 이전 상태를 변환하는 작업을 한 단계로 수행할 수 있습니다. 이 함수는 첫 번째 요소가 반환값이고 두 번째 요소가 새로운 상태인 쌍을 반환합니다. modify는 modifyGet에서 사용된 쌍에 Unit의 생성자를 추가한 것일 뿐입니다:

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

PUnit은 Type 대신 Type u에 있을 수 있도록 유니버스 다형성을 갖춘 Unit 타입의 버전입니다. 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은 어떤 인스턴스를 선택할지 결정할 때 상태 타입이 있을 경우 이를 고려하게 되므로, 하나의 모나드가 여러 종류의 상태를 제공할 수 있습니다. 이 방식의 단점은 상태 타입이 충분히 명시적으로 지정되지 않았을 때 그 결과로 생성되는 인스턴스가 의도한 것과 다를 수 있다는 점이며, 이는 혼란스러운 오류 메시지로 이어질 수 있습니다.

마찬가지로, 추가 정보의 타입을 암시적 인자가 아니라 explicit(명시적) 인자로 받는 버전의 타입 클래스 메서드도 있습니다. 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.