Elixir에서 Forth의 Loop REPL | Pipeline

엘릭서에서 포스 인터프리터를 위한 최적화된 REPL 설계

엘릭서로 포스 인터프리터를 구현할 때, REPL 루프를 구성하는 두 가지 주요 방식이 있습니다: 최적화된(또는 파이프라인) 방식—입력 데이터가 렉서 → 인터프리터 → 실행기로 일방향으로 흐르는 구조—와 양방향 방식—각 단계 후 중간 결과를 다시 REPL로 되돌려주는 구조입니다. 최적화된 방식은 엘릭서의 파이프 연산자 |>를 활용해 임시 변수 없이 함수 호출을 연결함으로써, 순수한 함수형 흐름과 조합성을 유지합니다.

전통적인 REPL 모델은 다음을 전제로 합니다:

• 렉서가 원시 입력을 토큰으로 변환합니다.
• 인터프리터가 토큰을 실행 가능한 코드로 변환합니다.
• 실행기가 해당 코드를 현재 머신 상태에 대해 평가합니다.

양방향 방식에서는 각 단계 사이에 결과가 REPL로 다시 전달되므로, 변수 재할당, 추가 함수 호출, 그리고 개발자의 인지 부담이 증가합니다.

최적화된 패턴으로의 전환

여러 포스 엔진을 연동해 프로토타이핑하면서, 교과서 속 REPL 다이어그램과 실제 구현 간 격차를 발견했습니다. 일반적인 원형 흐름도는 중첩된 함수 호출이 실제로 어떻게 작동하는지 무시합니다—중간 값은 REPL 루프로 다시 순환되지 않고, 호출 스택을 따라 위로 반환됩니다.

순수한 최적화 아키텍처라면 렉서, 인터프리터, 실행기를 별도의 GenServer 프로세스로 만들고 메시지로 통신하게 할 수 있습니다. 그러나 이 경우 얼랑 VM 내 메시지 전달 지연으로 인해 측정 가능한 성능 저하가 발생합니다.

해결책은? |> 연산자를 사용하세요—컴파일 시 중첩 함수 호출로 직접 변환되므로, 런타임 메시징 없이 스트림 의미론을 효율적으로 흉내 낼 수 있습니다.

코드 예시: 최적화된 구현

핵심 REPL 루프는 깔끔한 파이프라인으로 압축됩니다:

new_state = IO.gets("~Words $ ") |> String.trim() |> parse() |> interpret(state) |> evaluate()
IO.write(" ok\n")
loop(new_state)

여기서 |>는 각 단계의 출력을 다음 단계의 첫 번째 인자로 전달합니다: 입력 → 공백 제거 → 구문 분석 → 해석 → 평가. 꼬리 재귀(loop)는 스택 증가 없이 무한 실행을 보장합니다.

이는 양방향 구현에서 흔히 보이는 임시 변수를 완전히 제거합니다.

추가 최적화 사항

오류 처리 전반을 현대화했습니다:

• 예외는 렉서·인터프리터·실행기 등 개별 단계 내부에서 발생시킵니다.
• 모든 오류는 최상위 REPL 계층에서 한 번에 캡처합니다.
• 오류 분류 및 보고는 모듈 간 산재하지 않고, 중앙 집중식으로 관리됩니다.

구문 분석기는 특화된 개선을 받았습니다: 조건문(if/else/then) 처리를 분기 인지 최적화로 완전히 재설계했습니다. 출력 렌더링은 이제 부작용(side effect)으로 처리되며, REPL로 어떤 값도 반환하지 않아, 데이터 흐름을 엄격히 하향으로 유지합니다.

데이터 흐름은 명확한 패턴을 따릅니다: 하향 분기는 데이터(토큰 → 코드)를 전달하고, 상향 분기는 제어 신호(오류, 종료 요청, 프롬프트)를 담당합니다.

핵심 요약

• 최적화된 패턴은 엘릭서 기반 포스 인터프리터에 완전히 적용 가능하며, 성능 저하 없이 전체 기능을 제공합니다.
• |> 파이프라인은 프로세스 간 메시징을 대체하면서도 가독성과 효율성을 모두 확보합니다.
• 오류 처리는 REPL 최상위에 단일 try/catch 블록으로 통합됩니다.
• 구문 분석기는 중첩 조건문 같은 복잡한 구문을 분기 최적화로 정확히 처리합니다.
• 이 패턴은 엘릭서의 다른 명령어 처리 파이프라인에도 자연스럽게 확장됩니다.

스타일 비교

| 항목 | 양방향 방식 | 최적화된 방식 |

|------|-------------|----------------|

| 데이터 흐름 | 왕복 전송 및 라운드트립 | 일방향 파이프라인 |

| 변수 사용 | 임시 중간 변수 필수 | 불필요 |

| 성능 | 느림—반복적인 디스패치 및 상태 전달 오버헤드 | 빠름—컴파일러 최적화된 중첩 호출 |

| 가독성 | 중첩된 들여쓰기 또는 지역 변수 사용 | 선형적이고 선언적인 |> 체인 |

C++ 개발자라면 operator<< 체인과 유사함을 느낄 수 있지만, 엘릭서의 |>는 C++과 달리 메시지 의미론을 전혀 포함하지 않으며, 순수한 조합을 위한 문법적 설탕(syntactic sugar)일 뿐입니다.

— Editorial Team