언제 필요한가요?
먼저 평범한 if와 cond, 프로시저를 써 보세요. call/cc는 깊이 중첩된 계산에서 위쪽으로 한 번 빠져나가야 할 때만 꺼내세요. 그 탈출을 진입과 정리로 감싸야 한다면 dynamic-wind를 더하세요.
실행으로 확인하기
LISPEX
(call/cc (lambda (escape) (escape 'done) 'unreachable))관측 결과
OUTPUT
done예제 읽기
call/cc가 탈출 프로시저를 람다에 넘깁니다. 이 프로시저를 done으로 부르면 그 값이 곧바로 바깥의 call/cc로 전달됩니다. 뒤에 있는 심볼 unreachable은 평가되지 않습니다. 이 전송과 함께 탈출 연속은 소비됩니다.
이 순서로 생각하세요
- 첫 호출은 전이가 일어나기 전에 연속을 원자적으로 소비합니다. 그 뒤의 호출은 모두 E340입니다.
dynamic-wind는before,thunk,after를 이 순서로 실행합니다. 풀려 나갈 때는 대기 중인after를 안쪽부터 실행합니다.afterthunk에서 새 오류나 탈출이 나면 이미 진행 중이던 신호를 대체합니다.
빠르게 고르기
| 필요한 것 | 우선 선택 | 이유 |
|---|---|---|
| 일반적인 선택 | if 또는 cond | 로컬 제어 흐름이 눈에 보임 |
| 도우미 결과 반환 | 평범한 프로시저 결과 | 비로컬 전송이 없음 |
| 중첩 호출 여러 겹을 한 번 벗어나기 | call/cc 탈출 | 명시적 위쪽 출구 하나 |
| 탈출 전후 정리 | dynamic-wind | 풀릴 때 after 실행 |
| 같은 지점을 여러 번 재개 | 흐름 재설계 | 연속은 일회용이며 재진입 불가 |
흔한 오해
다회 연속 재사용과 동적 컨텍스트 재진입은 보류되어 있습니다.
현재 경계
- 호스트 예외와 호스트 연속은 게스트 전이를 구현하지 않습니다.
다음으로
일반적인 제어 흐름은 조건식에서 다룹니다. 오류가 명시적 평가기 신호 경로와 어떻게 맞물리는지는 진단에서 설명합니다.