Hell: 셸 스크립팅용 Haskell 방언

Hell은 내가 셸 스크립팅 용도로 직접 만든, 아주 작은 Haskell 방언의 셸 스크립팅 언어다. 2월부터는 Hakyll 대신 Hell을 사용해 이 블로그를 생성하고 있다.1

업데이트: 2024년 10월 3일 기준, Terraform과 여러 API와 함께 업무에서 2천 줄 규모의 다양한 큰 스크립트들에 사용하고 있다.

#!/usr/bin/env hell
main = do
  Text.putStrLn "Please enter your name and hit ENTER:"
  name <- Text.getLine
  Text.putStrLn "Thanks, your name is: "
  Text.putStrLn name

2024년 새해 목표는 자동화를 위해 셸 스크립트를 더 많이 쓰는 것이었다. 나는 늘 bash의 단점들 때문에 이것을 피해 왔다. 그리고 다른 문제들도 있다.

bash, zsh, fish 등에는 문제가 있다:

• 도무지 이해할 수 없는 횡설수설이다.
• 인용(예: x=$(ls -1) ..)을 사용해 실수하기 쉽다.
• 기본적인 일을 하는 데 하위 프로세스에 지나치게 의존한다.
• 그 결과 동등성, 산술, 순서 같은 것들이 전혀 원칙이 없다. 함정투성이이다.23

하지만 bash에도 장점이 있다. 안정적이고 단순하며, 모든 머신에서 동일하게 동작한다. bash 스크립트를 한 번 써 두면 코드를 전혀 바꾸지 않고도 수년 동안 돌릴 수 있다. 작년에 쓴 코드는 내년에도 그대로일 것이다. 이는 대부분의 인기 있는 프로그래밍 언어에 대해 사실이 아니다. Haskell만 봐도 그렇다.

그래서 내가 쓰고 싶은 언어를 정의한다는 관점에서, 셸 스크립팅 언어의 골격을 논해 보자:

• 매우 기본적이어야 한다.
• 즉시 실행되어야 한다(눈에 보이는 컴파일 단계 없음).
• 모듈 시스템이 없어야 한다.
• 패키지 시스템이 없어야 한다.4
• 추상화 능력(클래스, 화려한 데이터 타입, 다형적 함수 등)이 없어야 한다.
• 하위 호환을 깨는 방식으로 변하지 않아야 한다.5

왜 모듈이나 패키지 시스템이 없나? 시스템이 “완료” 상태가 되기 어렵게 만들기 때문이다. 항상 할 수 있는 다른 통합이 있고, 추가할 다른 기능이 있다. 나는 Hell이 냉혈 소프트웨어이길 선호한다. 완성된 소프트웨어에는 아름다움이 있다.

위에 근거해 나는 _스크립팅 임계값_을 정의할 수 있다. 즉, 모듈 시스템이나 패키지 시스템, 추상화 능력에 손이 가거나, 표준 라이브러리에 있는 것보다 더 많은 것을 원한다면, 아마 일반 목적 프로그래밍 언어를 써야 할 때일 것이다.

이를 감안하여, 나는 다음 이유들로 Haskell 방언6을 만들기로 했다:

• 나는 Haskell을 잘 안다.
• 내가 늘 쓰는 도구다.
• 동등성, 순서 등에 관해 좋은 이야기를 가지고 있다.
• 동시성을 손쉽게 수행할 수 있는 좋은 런타임이 있다.
• 가비지 컬렉션이 된다.
• 바이트와 텍스트를 제대로 구분한다.
• 정적 링크된 Linux x86 바이너리로 컴파일할 수 있다.
• 성능이 좋다.
• 정적 타입이다!

언어를 설계하며 다음과 같은 결정을 내렸다:

• 충실한 Haskell 문법 파서를 사용한다.
• 그게 더 낫다. 재사용이 가능하니까.
• import/모듈/패키지가 없다.
• 재귀 정의를 지원하지 않지만, 이를 위해 fix를 사용할 수 있다.
• 기본 타입클래스(Eq, Ord, Show, Monad)는 지원한다. 이는 예컨대 List.lookup과 익숙한 동등성 관련 기능에 필요하다.
• 다형 타입은 지원하지 않는다. 그것도 일종의 추상화이므로 필요 없다.
• Haskell에서 이미 쓰이는 이름들(List.lookup, Monad.forM, Async.race 등)을 그대로 사용해 직관을 재사용한다.

릴리스 페이지에서 정적 링크된 Linux 바이너리를 다운로드할 수 있다. 구현 내부에 대한 설명은 내가 회사에서 Hell을 발표하려고 만든 슬라이드 모음인 Tour of Hell을 참고하라.

---

1. 이런 문제들에 진절머리가 났다.↩︎

2. ShellCheck의 린트 이슈 목록만 봐도 방대하다.↩︎

3. 코드 실행에 관한 이 블로그 글을 보라.↩︎

4. 믿기 어렵게도 nodejs 생태계 위에 올라간 zx 같은 스크립팅 언어는 제외한다.↩︎

5. 참고: Escaping the Hamster Wheel of Backwards Incompatibility↩︎

6. 그리고 다른 대안 셸 스크립팅 언어나 Elixir를 쓰는 것, 혹은 Oil을 쓰지 않은 이유다.↩︎