Gleam에서 Continuation을 사용하여 동기, 오류, 비동기 효과(Effects)를 일반화하는 방법을 설명함.
Monad 패턴(Result, Promise)을 일반화하는 도구로 Continuation을 제시하며, 비즈니스 로직과 Fetching 효과를 분리함.
커뮤니티에서는 Continuation과 대수적 효과(Algebraic Effects)의 유사성을 논하며, 언어 지원 및 구현 방식에 대한 논의가 있음.
본문은 Gleam에서 Continuation을 사용하여 다양한 컴퓨팅 효과(Fetching)를 추상화하는 방법을 제시합니다. Result나 Promise와 같은 Monad를 일반화하여, 비즈니스 로직은 그대로 유지하면서 데이터 소스(Data Source)의 동기/비동기, 오류 처리 여부에 따라 다른 Fetch 구현을 적용할 수 있음을 보여줍니다. 이는 로직과 부수 효과(Side Effects)의 명확한 분리(Separation of Concerns)를 가능하게 합니다.
Lobsters 커뮤니티에서는 Continuation이 대수적 효과(Algebraic Effects)와 유사하다는 의견이 제기되었습니다. 특히 Scheme의 Prompt Handlers와 같은 동적 언어에서의 지원 방식이 언급되었습니다. 하지만 Gleam과 같이 컴파일 타임 타입 체크(Compile-time Type Checking)를 지원하는 언어에서는 확장 가능한 데이터 타입(Extensible Data Type) 부재로 인해 완전한 대수적 효과 구현에 제약이 있음을 지적합니다.
논의에서는 동적 언어의 동적 후속 처리(Dynamic Delimited Continuations)와 정적 언어의 컴파일 타임 타입 체크(Compile-time Type Checking) 기반 효과 처리 방식의 차이가 강조됩니다. Gleam의 Continuation 구현은 언어 자체의 제약 속에서 대수적 효과(Algebraic Effects)에 최대한 근접하려는 시도로 해석됩니다. 이는 런타임 유연성(Runtime Flexibility)과 컴파일 타임 안정성(Compile-time Safety) 사이의 트레이드오프(Trade-off)를 보여줍니다.
Continuation 기반의 로직은 최종 값에 접근하기 위해 Runner 또는 Interpreter라는 콜백 함수를 필요로 합니다. 이 Runner는 Fetch 함수의 구체적인 구현(Concrete Implementation)에 따라 동기(Synchronous), 오류 처리(Fallible), 비동기(Asynchronous) 등 다양한 방식으로 동작합니다. 이는 효과(Effect)의 실행 방식을 외부에서 결정하게 함으로써, 비즈니스 로직의 재사용성을 극대화하는 핵심 메커니즘입니다.