
나는 지난 며칠 간 밤에 [토이 Lisp 인터프리터를 확장](https://www.pacokwon.org/posts/20230702-haskell-lisp-extensions)시키며 그 과정을 전부 녹화하고, 원본 그대로 유튜브에 업로드했다. 녹화한 계기는 간단했는데, 아무래도 요새는 취미로 프로그래밍하는 경우가 많으니 옆에 침착맨 틀어놓고 여유롭게 즐기는 것도 좋지만, 코딩에만 집중하며 그 과정을 말로 풀어보는 것도 좋은 경험이 될 것 같아 시도해봤다.

나는 한번도 이런 걸 시도해본 적이 없었는데 막상 시작해보니..역시 처음이라 장애물이 많았다. 그런 어려움을 겪으며 배운 것들, 그리고 좋았던 부분들에 대해 적어보고 싶다.

### 노트북 사양

최근에 전역을 했지만 다시 떠나는 신세라 나에게는 컴퓨터가 없다 (모종의 이유로 대학교에서 쓰던 맥북이 내 손을 떠났다). 그래서 가정에 유기된 2014년 발매 [삼성 아티브 모델](https://www.samsung.com/hk_en/computers/notebook/notebook-9-i5-8gb-128gb-np900x3g-k03hk/)을 주워 리눅스를 설치해 쓰고 있는데, 이 노트북에 대해 말하자면 우선 CPU는 인텔 4세대 i5-4210U 모델이다. 참고로 현재 i5는 13세대까지 출시되었다. 힘의 차이가 숫자만 봐도 느껴지지 않는가??. 램은 4GB인 데다가(내가 군대에서 쓰던 컴퓨터도 램이 8GB였다), 배터리는 충전기 없이 1시간을 못가는 상태여서 직접 배터리를 사서 교체했다. 이젠 4시간 간다.

이렇게 사양이 빈약한 노트북에서 OBS를 돌릴 수 있을까 걱정을 했는데, 실제로 해보니 생각보다 괜찮았다. 평소에는 없던 팬 소음이 녹화를 할때는 생기는게 당황스럽긴 하지만 그렇게 큰 문제는 아니었다. OBS가 꽤 최적화가 잘 되어 있다고 느꼈다.

### 오디오 버그

내 노트북에는 3.5mm AUX 단자가 있다. 녹화를 할 때 음성도 같이 녹음하고 싶어서 헤드폰, 마이크가 같이 있는 헤드폰을 썼었다. 음성 녹음이 잘 돼서 초반 몇 번까지는 작동을 잘 하나 싶었는데, 나중에 그걸 들어보니 나는 컴퓨터에게 속고 있었다는 걸 알았다. 사실은 *노트북 내장 마이크*로 음성 녹음이 되고 있던 것이다. 헤드폰을 뽑고 다시 녹음을 시도했는데, 그때는 또 녹음이 안되기 시작했다. 내장 마이크가 작동은 하는데, AUX 단자에 뭔가를 꽂아야 작동하는 이상한 현상이 발생하는 것이었다.

그냥 내장 마이크를 쓸까 생각을 해봤는데, 마이크 옆에 팬이 있어서 녹화를 할 때 노이즈가 너무 많이 들어가는 바람에 필터로도 구제가 힘든 수준이었다. 어떻게든 이 문제를 고쳐야만 했다.

이 문제를 해결하기 위해 이틀 동안은 무한검색을 했다. OS가 리눅스인 것도 한몫했다. 아치 리눅스는 오디오 패키지를 따로 설치해야 컴퓨터에서 소리가 난다(여담이지만 볼륨 조절 키도 [사용자가 직접 설정](https://github.com/pacokwon/dotfiles/blob/52f6f2e4fec463a3193ef118f5666b922232cff1/.config/i3/config#L125-L127)해야 한다). 나는 [pipewire](https://wiki.archlinux.org/title/PipeWire)를 사용하고 있었는데 뭐가 문제일지 모르니 오디오 패키지도 바꿔보고, 마이크도 바꿔보고, 레딧에서 자비로운 한 고수 유저의 많은 도움을 받았음에도 끝내 원인을 찾지 못했다.

그 이후에는 하드웨어 문제를 의심하기 시작했다. 노트북 모델로 검색을 재개하니 [실제로 있는 하드웨어 버그]([900x3g Microphone](https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1316518))라는 걸 알았다. 버그 리포트 날짜는 노트북 모델이 출시된 2014년인데, 아직도 해결이 안되어 있었다. 그래서 그 시점에서 외장 마이크 연결은 깔끔하게 포기해버렸다.

### 영상 편집

대안은 휴대폰이나 태블릿에 음성을 녹음한 뒤, OBS에서 녹화한 영상과 합치는 것이었는데 이것 또한 여러가지 이유로 문제가 있었다. 가장 큰 이유는 내가 직접 영상 편집을 해야하기 때문이다.

10년 전에 윈도우 무비 메이커로 학교 UCC를 만든 이후로 나는 영상편집을 한 적이 없다. 그때는 순수 배짱으로 했으나 많은 것을 듣고 보게 된 지금은, 실제로는 그렇게 복잡한 작업을 하지 않더라도 프리미어나 파이널 컷을 쓸 줄 모르면 영상 편집은 할 수 없을 것이라는 심리적인 장벽이 있었다. 장비의 한계도 있었다. 난 리눅스를 쓰고 있다.

하지만 여느 상용 프로그램과 같이 영상 편집 프로그램도 FOSS 버전이 (여러 개) 존재했다. 나는 [`kdenlive`](https://github.com/KDE/kdenlive)를 사용하기로 했고, 간단한 편집 방법들을 익히고 나니 생각보다 괜찮다는 생각을 했다. 오디오 동기화와 노이즈 억제 필터, 맨 뒤에 사진 넣는 정도만 알면 됐었기 때문이다.

가장 큰 어려움은 역시 사양의 한계였다. 렌더링을 시작하면 기본적으로 컴퓨터에서 다른 일은 할 수 없고, 내가 할 수 있는 전부는 어느 때보다 열심히 일하는 CPU와 팬을 응원하는 것이다.

### 말솜씨

영상 편집을 하며 내 모습을 화면에서 쳐다보고 있자니 너무 어색했다. 영상 자체는 거의 날것으로 올리니 그걸 다 볼 일은 없었지만, 조금만 봐도 내 부자연스러운 표정이나 특유의 느리고 질질 끄는 말투가 상당히 거슬렸다. 평소에 남과 대화를 할 때도 이렇다 생각하니 갑자기 미안한 마음이 몰려온다. 영어 실력도 끌어올리고 싶어서 영어로도 설명을 해봤는데 난 영어가 부족한 것도 있지만 그냥 언어 무관하게 말을 못하는 거다..라는 생각이 들었다. 그래도 영상을 보고 이 사실을 자각할 수 있게 된 것에는 매우 긍정적이다.

### 긍정적인 효과

위 항목들 외에 녹화를 계속 해봐도 좋을 것 같다고 생각한 이유가 여러 가지 있었다.

우선 코딩을 하는 시간에 집중을 제대로 할 수 있었다. 카메라가 날 쳐다보고 있다고 생각하니 딴짓을 잘 안하게 된다. 난 딴짓을 자주 하는 편이라 잘 집중하다가도 침대로 뛰어드는 경우가 종종 발생하는데, 그런 것들을 많이 줄일 수 있었다.

내 스스로의 모습에 더 떳떳하게 되는 것도 있다. 난 남에게 비치는 나의 모습을 알게 모르게 많이 신경쓴다. 영상을 편집하지 않는 이유는 분량 때문에 엄두가 안 나는 것도 있지만, 그냥 내 모습에 체념하고 눈치보는 데에 에너지를 덜 쓰고 싶었다. 지인 말고는 영상을 볼 일이 없는 것을 알지만, 아무도 보지 않는다 생각해도 의외로 효과가 있더라.

기록으로 남는다는 측면에서도 긍정적이었다. 가족에게 방해가 될까봐 녹화는 밤에 자주 했는데 나중에 낮에 녹화 없이 코딩을 하려니 처음부터 찍었던 게 좀 아까웠던 적이 있었다. 다른 프로젝트는 마음대로 한다고 해도 지금껏 녹화하면서 짠 프로젝트를 녹화 없이 하려니 기록이 안 남아 아쉬웠던 것이다. 침착맨이 자택과 야외를 가리지 않고 방송을 켜는 것이 그런 이유일까? 유튜브에 올려두니 블로그에 링크를 걸 수도 있고, 몇 년이 지나 Lisp 코드로 고생하고 있는 나를 다시 볼 수 있다고 생각하면 재밌을 것 같다.

미래에 경제적, 시간적 여유가 생겼을 때, 흔히 볼 수 없지만 재밌는 취미 프로젝트를 만드는 과정을 대중에게 스트리밍하는 재야의 프로그래머가 되어보고 싶다는 소망이 생겼다. 그 날은 언제쯤 올까!


코딩하고 있는 내 모습을 보았다


하스켈로 LISP 만들기의 [첫 번째](20230616-haskell-lisp-parsing)와 [두 번째](20230618-lisp-eval) 포스트에서는 Lisp S-Expression의 파싱, 평가 방식을 간단하게 알아보았다. 너무도 간단해서 사실상 할 수 있는 것은 표현식 평가가 전부였다.

그 이후로 다양한 기능들을 추가해 토이 인터프리터를 확장해보았다. 아래 코드는 확장한 Lisp의 기능을 활용하여 작성할 수 있는 프로그램이다.

```lisp
(define (is-prime-helper n x)
  (if (< n (* x x))
      true
      (if (= 0 (% n x))
          false
          (is-prime-helper n (+ 1 x)))))

(define (is-prime n)
  (if (< n 2)
      false
      (is-prime-helper n 2)))

(is-prime 479001599)
```

이 포스트에서는 이전 포스트들처럼 언어를 확장하는 과정을 처음부터 끝까지 소개하기보다는, 어떤 기능들이 추가되었는지, 구현하며 내부적으로 어떤 부분이 흥미로웠는지 소개하겠다.

## 파일 단위 실행

[2부 - 평가](20230618-lisp-eval) 포스트에서 코드를 직접 실행할 수 있는 REPL을 만들어 인터프리터의 엔트리포인트로 만들었었다. 확장한 이후에는 `python`처럼 REPL을 실행할수도, 파일을 실행할수도 있다.

이와 같은 `test.lisp` 파일이 있다고 가정했을 때:

```lisp
(+ 1 2 3)
(* 2 4 6)
```

이 파일을 인자로 인터프리터에 넘기면 각각의 평가된 값이 출력된다.

```bash
$ stack run whisper-exe test.lisp
6
48
```

파일명 이전에 `-i` 플래그를 넘기면, 파일을 실행한 이후의 상태를 그대로 물려받은 REPL을 실행할 수 있다.

이번에는 이와 같은 `test.lisp`가 있을 때:

```lisp
(define (add-two a b) (+ a b))
```

`-i` 플래그를 넘겨 실행해보면, `add-two` 함수가 그대로 접근 가능하다.

```bash
$ stack run whisper-exe -- -i examples/def.lisp

>> (add-two 1 2)
3
>> add-two
<function>
```

이 기능은 Lisp 코드를 수정하지 않고 여러 값을 넣어 함수 호출을 해보고 싶을 때 유용하다.

## `Boolean`과 조건 표현식

`if` 함수를 이용해 조건 분기를 할 수 있다. 이를 위해 `boolean`타입의 값과 표현식을 추가했다.

```bash
>> true
true
>> false
false
>> (if true 3 5)
3
>> (if false 3 5)
5
```

## 다양한 네이티브 함수

기존에 있던 산술연산자 외에 비교연산자와 논리연산자를 구현했다.

```bash
>> (< 3 5)
True
>> (= 3 5)
False
>> (~ true)
False
>> (|| true true false)
True
>> (&& false false true)
False
>> (% 5 3)
2
>> (/ 5 3)
1
>> (if (< 3 5) 3 5)
3
```

## `define`을 이용한 전역변수 및 사용자 정의 함수 선언

`define` 함수를 이용하면 다음과 같이 변수를 사용할 수 있다.

```lisp
(define global 3)

global            ; 3
(+ global global) ; 6
```

첫번째 인자가 괄호에 감싸져 있다면 함수가 된다.

```lisp
(define (add-two a b) (+ a b))

(add-two 42 3)    ; 45
```

## 재귀함수 지원

이 언어에는 반복문이 없다.

하지만 괜찮다. 진정한 상남자 프로그래머는 반복문을 사용하지 않는다. 재귀를 사용한다!

```lisp
(define (add-range-helper start end acc)
        (if (< end start)
            acc
            (add-range-helper (+ 1 start) end (+ start acc))))

(define (add-range start end)
  (add-range-helper start end 0))

(add-range 1 10) ; 55
```

## Functions as Values

네이티브 함수와 사용자 정의 함수는 값으로 취급되어 다음과 같이 다른 함수의 인자에 전달할 수도 있다.

```lisp
(define (apply-f-to-x f x) (f x))

(define (times-two x) (* x 2))
(define (add-two x) (+ x 2))

(apply-f-to-x times-two 3) ; 6
(apply-f-to-x add-two 3)   ; 5
```

## `StateT`와 `Either` 타입을 이용한 환경 조작 및 에러 처리

이번 프로젝트를 하며 가장 큰 의의는 모나드 트랜스포머(monad transformer)를 실제로 사용해봤다는 것이다. 기존에는 환경(Environment)를 `State` 모나드로 처리하고 있었다. 표현식을 평가하는 함수라면 항상 환경을 필요로 할 것이었고, 새로운 바인딩이 추가되면 환경을 수정해야 했기 때문이었다.

이를 `StateT`로 바꿔야겠다고 생각했던 이유는 에러처리 때문이었다. 기존에는 에러처리를 하스켈의 `error` 함수로 했었다. 이 때문에 `error` 함수가 있는 경로로 코드가 실행되면 그냥 프로그램이 죽어버렸다. 이를 처리하기 위해 평가 결과 타입을 단순히 `Value`를 사용하기보다 `Either String Value`를 사용하면 되겠다고 생각을 했다. 그러려면 `State` 모나드의 타입이 대략 이렇게 생겨야 한다:

```haskell
newtype State s a = State { runState :: s -> Either String (a, s) }
```

참고로 원래 `State` 타입은 이렇게 생겼다.

```haskell
newtype State s a = State { runState :: s -> (a, s) }
```

근데 `s`, `a`를 적당히 조작하는 것으로는 위쪽에 있는 타입은 만들 수 없다. 여기서 [`StateT`](https://hackage.haskell.org/package/mtl-2.3.1/docs/Control-Monad-State-Lazy.html#t:StateT)가 등장한다.

```haskell
newtype StateT s (m :: Type -> Type) a = State { runState :: s -> m (a, s) }
```

이를 `StateT Env (Either String) a`와 같이 사용하면 필요했던 타입을 만들 수 있고, 모나드 조작도 간편하게 할 수 있다. 아래는 scope-local 변수를 제공하는 `let` 함수의 코어 부분을 구현하는 `applyLet` 함수의 모습이다.

```haskell
type ExecState = StateT Env (Either String)

applyLet :: [Sexpr] -> ExecState Value
applyLet [decls, expr] = do
  ogEnv <- get
  extendWithDecls decls
  val <- evalSexpr expr
  put ogEnv
  return val
applyLet _ = lift . Left $ "Let construct must include two elements. A declaration and an expression!"

extendWithDecls :: Sexpr -> ExecState ()
-- ...
```

구현부를 보면 일반 `State` 모나드처럼 `get`을 통해 상태를 접근하는 것을 확인할 수 있다. `Either String` 타입으로 감싸져 있지만 말이다. `ogEnv`와 `val`은 원래와 같이 각각 `Env`, `Value` 타입이다. 마지막에 `return`을 하면 `Right`에 감싸져서 돌려준다.

반면 유효하지 않은 인자들의 경우 에러를 발생시키고 싶을 것이다. `applyLet _`의 구현부는, `Left`를 이용해 만든 `Either String Value` 타입을 `StateT` 타입의 값으로 변환시켜준다. `lift`만 사용하면 자동으로 `StateT`의 값으로 승격되며, 이 개념은 어떤 transformer를 사용해도 동일하게 적용할 수 있다.

이걸 처음 도입하려고 하면서 꽤나 머릿속이 복잡했었는데, 그래도 조금씩 이해하며 그 가치를 느낄 수 있었다. 사실 아직은 조금 마법같다. 아래는 이에 대한 [하스켈 위키](https://wiki.haskell.org/Monad_Transformers_Explained)의 설명 중 하나다:

> Monad transformers are like onions. At first, they make you cry but then you learn to appreciate them. Like onions, they're also made of layers. Each layer is the functionality of a new monad, you lift monadic functions to get into the inner monads and you have transformerised functions to unwrap each layer.

모나드 트랜스포머를 처음 봐도 눈물을 터뜨리지 않도록 조심하자.

## 마무리

비교적 간단한 프로젝트였지만 꽤 의미있는 경험이었다. 하스켈 코드를 작성하면서 느낀 것이지만 컴파일러를 잘 달래주면 많은 양의 버그가 사라지는 것 같다. 기억에 남는 버그는 함수 호출 시 환경을 병합할 때 `Map.union t1 t2`의 암묵적인 우선순위를 인지하지 못하고 그냥 사용해버려서 인자가 제대로 안 넘어가는 경우였는데, 하스켈에서 `trace`, `traceM` 등 순수 함수 안에서도 로그를 찍을 수 있는 짱짱한 도구들이 있어 잘 해결할 수 있었다.

또 하스켈이 이론적인 기반이 탄탄하다 보니 다양한 패턴들에 대한 내장 함수들이 많은 듯했다. 나름 내 아이디어로 내가 알고 있는 함수들을 이렇게 저렇게 조합하고 나니, hls(haskell language server)가 처음 들어보는 내장함수를 내밀며 "이 함수 하나를 써서 네가 방금 쓴 엉망 코드를 리팩토링하지 않겠니?"라는 제안을 받아본 것이 꽤 여러번이다.

마지막으로, 나는 이 포스트에 있는 기능을 추가하는 모든 과정을 영상에 담았다. 편집을 안한 정말 날것이라 다시 돌려볼 가치는 크게 없겠으나 녹화를 하며 코딩을 하니 감회가 달랐다. 어디 내놓기 부끄럽지만 유튜브에 [플레이리스트](https://www.youtube.com/playlist?list=PLZlApiQaKgfRrWRgC7Vaqck1VW5x6zHWS)를 만들어 두었다. 지금은 부끄럽기 짝이 없지만 나중에 돌려보며 웃을 수 있는 영상이 되었으면 좋겠다.


하스켈로 간단한 Lisp 만들기 - 확장판


[1부](./20230616-haskell-lisp-parsing)에서는 S-Expression을 파싱하는 법에 대해 간단하게 알아보았다. 이번 포스트에서는 파싱한 결과물을 실행시켜볼 것이다.

먼저 `src/Eval.hs` 파일을 만들자. 거의 모든 작업을 이 파일에서 진행할 것이다. 이 글에서 최종 목표는 아래 두 함수를 완성시키는 것이다.

```haskell
eval :: Sexpr -> Value
repl :: IO ()
```

위 `eval` 함수부터 구현해보자. `eval`은 S-Expression 트리를 입력으로 받고 결과값을 돌려준다.

먼저 결과값인 `Value` 타입을 정의해보자. 일단 숫자는 결과로 나올 것이 당연해 보이니, 우선 `Value`의 종류는 `Int`하나로 정의하고 구현을 하며 점진적으로 그 종류를 늘려가자.

```haskell
data Value = NumV Int
```

이제 가능한 S-Expression을 형태별로 평가해볼 것이다.

### 숫자 평가

숫자 평가는 간단하다. 생성자에 들어있는 값을 꺼내기만 하면 된다.

```haskell
eval (Number n) = n
```

### 식별자 평가

식별자 평가는 애매하다. 아직 언어에 *변수가 없기 때문*이다. 때문에 현재 식별자가 이용될만한 곳은 리스트의 가장 앞쪽에 있는 경우, 즉 함수로 사용되는 경우이다. 아래와 같은 코드가 해당한다.

```lisp
(+ 1 2) ; 3

(max 30 42 7) ; 42
```

가장 앞에 있는 것이 식별자로 파싱이 된다.

근데 또 문제가 있다. 누가 `+`를 더하기 함수로, `max`를 최대값 함수로 정의하는 것일까? 저런 코드가 예상대로 작동하려면, 더하기를 수행하고 최대값을 구하는 로직을 누가 심어둬야 한다. 그것은 우리의 몫이다.

그러니 현재 우리가 할 수 있는 것은, 식별자를 봤을 때 기본 함수로 pre-defined된 식별자라면 함수를 돌려주고, 그렇지 않은 경우에는 에러를 발생시키는 것이다.

그러기 위해서는 우선 함수 값을 만들어야 한다. 아래와 같이 `Value`를 확장시켜보자.

```haskell
data Value = NumV Int
           | Func ([Value] -> Value)
```

Lisp는 꽤 다이나믹한 언어라 `+`와 같은 함수같은 경우에는 명시된 인자 개수가 없이 몇개가 들어와도 전부 더해서 돌려준다. 물론 인자의 개수가 고정되어야 하는 함수의 경우에는 개수가 맞지 않으면 에러를 발생시킨다. 이러한 use case를 모두 커버하기 위해 우리의 함수는 인자를 리스트로 받도록 만들었다.

`+` 함수를 구현해보자. 아래와 같이 짜볼 수 있을 것이다.

```haskell
eval (Ident "+") = Func func
    where
        func = NumV . sum . map mapping
        mapping (NumV n) = n
        mapping _ = error "\"+\" expects a number as argument"
```

하스켈의 `sum` 함수를 활용하니 꽤 간단하다!

`max`도 구현해보자. 마찬가지로 꽤 간단하다.

```haskell
eval (Ident "max") = Func func
    where
        func = NumV . maximum . map mapping
        mapping (NumV n) = n
        mapping _ = error "\"max\" expects a number as argument"
```

다른 식별자를 마주쳤을 때는 에러를 발생시키자. 또 위에 중복되는 `mapping` 함수를 밖으로 뽑아내었다.

```haskell
getNum :: Value -> Int
getNum (NumV n) = n
getNum x = error ("Value must be a NumV value. Got: " ++ show x)

eval :: Sexpr -> Value
eval (Number n) = NumV n
eval (Ident "+") = Func func
    where
        func = NumV . sum . map getNum
eval (Ident "max") = Func func
    where
        func = NumV . maximum . map getNum
eval (Ident x) = error $ "Unknown identifier " ++ x
```

### 리스트 평가

우리는 리스트에서 첫 번째 요소가 "함수"이기를 기대하고 있다. `(+ 1 2 3)` 에서 `+`처럼 말이다. 그 다음은 나머지 요소들을 함수에 넘기기만 하면 되는데, 그 전에 평가를 하고 넘기는 것이 중요하다. 우리 함수는 `Sexpr`이 아닌 `Value` 타입의 인자를 받는다는 것을 기억하자.

다음은 리스트 평가 코드이다.

```haskell
eval (Paren (x:xs)) = getFunc (eval x) (map eval xs)
    where
        getFunc (Func f) = f
        getFunc v = error $ "The first element in a list must be a function. Got: " ++ show v
eval (Paren []) = error "List must not be empty!"
```

비어있는 리스트의 경우 에러를 발생시키고 있다.

## 파서와 합치기

이번 포스트에서는 간단한 평가 로직까지 작성해 보았다. 1부에서 만든 파서와 합쳐서, 임의의 S-Expression을 받아 평가해주는 REPL을 만들어 보자.

### REPL

우선 REPL 코드를 짜보자. 하스켈은 다른 언어와 다르게 IO 처리가 특이해서 먼저 틀을 잡고 가는 것이 편할 것 같다.

가장 먼저 에코 REPL을 만들어볼 것이다. 에코 REPL은 사용자가 입력한 것을 똑같이 출력해주는 REPL이다.

```haskell
import System.IO (hFlush, stdout)

repl :: IO ()
repl = do
    putStr ">> "
    hFlush stdout
    input <- getLine
    putStrLn $ "You entered " ++ input
    repl
```

위 코드가 하는 일은 다음과 같다.

1.  `>> `를 먼저 출력한다. 이는 사용자가 REPL에 들어와 있음을 잘 명시해준다.
2.  `hFlush` 함수를 이용하여 현재 버퍼에 있는 내용을 `stdout`으로 보내버린다. 많은 언어들의 표준 라이브러리가 buffered IO를 사용하기 때문에 `stdout`으로 출력을 하더라도 버퍼에 쌓이기만 하여 나중에 출력 순서가 섞이는 경우가 있다.
3.  `getLine`을 통해 사용자에게서 문자열 입력을 받는다.
4.  입력으로 받은 문자열을 출력한다.
5.  `repl`을 다시 호출하여 `1`~`4`의 과정을 반복한다.

이제 사용자가 `exit`을 입력하면 루프를 종료하는 기능을 추가해보자.

```haskell
import System.IO (hFlush, stdout)

repl :: IO ()
repl = do
    putStr ">> "
    hFlush stdout
    input <- getLine
    if input == "exit" then
        putStrLn "Bye!"
    else do
        putStrLn $ "You entered " ++ input
        repl
```

위에서 하는 일은 간단하다. `input`이 `"exit"` 문자열인 경우에는 재귀호출을 하지 않으면 된다. 이렇게 REPL의 틀을 완성했다!

### 합치기

이제 진짜 합칠 때가 되었다.

사실 아직 안되었다. 유틸리티 함수를 하나만 더 만들겠다. 이건 1부에서 했어야 하는 일이었는데, 바로 사용하기 편리한 `parse` 함수를 만드는 것이다. 이전 포스트에서는 `parseTest`라는 `megaparsec`의 함수를 사용해서 우리의 파서를 편리하게 테스트할 수 있었다. 하지만 그것은 `stdout`에 출력을 가정하는, 말 그대로 테스트용 헬퍼 함수이기 때문에 실제로 결과값만 가져오고 싶은 경우에는 `runParser`를 사용해야 한다.

```haskell
runParser :: Parsec e s a-- Parser to run
    -> String -- Name of source file
    -> s -- Input for parser
    -> Either (ParseErrorBundle s e) a -- Parsed result
```

`runParser`의 시그니처는 위와 같은데, 그냥 사용하기 가장 불편한 이유는 에러 처리와 소스 파일명 인자가 있어서 그렇다. 우리가 어떤 파서를 실행시키고 싶은지(`sexpr`)는 꽤 명확하기도 하다. 이를 둘 다 처리해주는 유틸리티 함수를 `src/Parser.hs`에 아래와 같이 만들었다.

```haskell
parse :: Text -> Sexpr
parse input = case runParser sexpr "" input of
  Right s -> s
  Left e -> error . show $ e
```

이제 모든 조각이 완성되었으니, REPL 안에 합쳐보자.

```haskell
repl :: IO ()
repl = do
    putStr ">> "
    hFlush stdout
    input <- getLine
    if input == "exit" then
        putStrLn "Bye!"
    else do
        print . eval . parse $ input
        repl
```

이제 실행시켜보자!

```plaintext
$ stack exec whisper-exe
>> (+ 1 2)
3
>> (max 2 5 10)
10
>> (max 2 10 (+ 10 2))
12
>> (+ 5 (max 3 7 1))
12
>> exit
Bye!
```

이렇게 그럴듯한 REPL이 완성되었다! 아래는 이번 포스트에서 작업을 했던 `src/Eval.hs`의 전체 코드다.

```haskell
-- src/Eval.hs
module Eval (eval) where

import Parser (Sexpr (..))

data Value = NumV Int
           | Func ([Value] -> Value)

instance Show Value where
    show (NumV n) = show n
    show (Func _) = "<function>"

getNum :: Value -> Int
getNum (NumV n) = n
getNum x = error $ "Value must be a NumV value. Got: " ++ show x

eval :: Sexpr -> Value
eval (Number n) = NumV n
eval (Ident "+") = Func func
    where
        func = NumV . sum . map getNum
eval (Ident "max") = Func func
    where
        func = NumV . maximum . map getNum
eval (Ident x) = error $ "Unknown identifier " ++ x
eval (Paren (x:xs)) = getFunc (eval x) (map eval xs)
    where
        getFunc (Func f) = f
        getFunc v = error $ "The first element in a list must be a function. Got: " ++ show v
eval (Paren []) = error "List must not be empty!"
```

프로젝트의 전체 코드는 https://github.com/pacokwon/whisper 에서 확인할 수 있다.


하스켈로 간단한 Lisp 만들기 - 평가


이번 포스트와 다음 포스트에서는 간단한 Lisp 인터프리터를 만들어보겠다. 재미와 학습을 위한 것이니 간단하게 하겠다.

## 목차

- [Lisp와 목표](#lisp와-목표)
- [인터프리터 구조](#인터프리터-구조)
- [파싱](#파싱)
  - [AST 정의](#ast-정의)
  - [Parser Combinator](#parser-combinator)
  - [숫자 파싱](#숫자-파싱)
  - [식별자 파싱](#식별자-파싱)

나머지 부분들은 2부에서 다루겠다!

## Lisp와 목표

Lisp는 단순한 문법과 확장성으로 인해 매니아층이 있는 언어이다. 문법은 S-Expression이라는 표현을 사용하는데, 괄호가 많은 것으로 악명이 높다. 요새 Lisp는 그 자체로 언어라기보다 언어의 family를 나타내는 말로 쓰이는 것 같다. Racket, Common Lisp, Clojure 등등이 이 family에 속한다고 볼 수 있고, 심지어는 이맥스에서도 Emacs Lisp라는 언어를 이용해 내부 configuration을 구성할 수 있게 되어 있다. 언어들마다 제공하는 primitive가 각각 다른데, 이번에는 아래 기능들을 구현해보도록 하겠다.

- 표현식 평가
- 변수 선언 (local, global)
- 함수 선언 및 호출

사용할 언어는 하스켈이다. 이럴 때라도 써보도록 하겠다!

우선 프로젝트를 생성하자. 프로젝트 이름은 `whisper`이다. 여기서 사용하는 툴은 [stack](https://docs.haskellstack.org/en/stable/)이다.

```bash
$ stack new whisper new-template
```

다음과 같이 파일이 있을 것이다.

```plaintext
app           LICENSE       README.md  src         stack.yaml.lock  whisper.cabal
CHANGELOG.md  package.yaml  Setup.hs   stack.yaml  test
```

실제 프로젝트의 코드는 `app`, `src` 디렉토리에 있으며, `src`는 코어한 라이브러리 함수들이 있고, `app`에는 라이브러리 함수를 잘 조합하여 하나의 실행 파일로 동작하도록 하는 파일이 있다.

이 프로젝트에서는 `ghc 9.2.7`을 사용하겠다. `stack.yaml`에 이를 다음과 같이 명시해준다.

```yaml
#...
resolver: lts-20.24
#...
```

## 인터프리터 구조

우리의 인터프리터는 읽기 - 파싱 - 평가 - 출력의 단계로 동작하게 할 것이다. 이 중 코어한 부분이 파싱과 평가인데, 이 두 단계를 차례로 부딪혀 보도록 하자.

## 파싱

코드를 작성하기 전에 필요한 패키지를 설치해야 한다. 이 프로젝트에서 사용할 패키지는 [`megaparsec`](https://hackage.haskell.org/package/megaparsec)이라는 parser combinator 라이브러리와, 효율적인 텍스트 처리를 위한 [`text`](https://hackage.haskell.org/package/text) 패키지이다.

`stack.yaml`에 이를 명시해준다.

```yaml
extra-deps:
  - megaparsec-9.4.0
  - text-2.0.2
```

또 `package.yaml`의 `dependencies` 부분에 다음과 같이 추가한다.

```yaml
dependencies:
  - base >= 4.7 && < 5
  - megaparsec >= 9.4 # NEW
  - text >= 2.0 # NEW
```

이제 `src/Parser.hs`에 파싱 코드를 작성해보자.

NOTE: `megaparsec`과 같은 parser combinator 라이브러리를 처음 써봐서 [이 공식 문서](https://markkarpov.com/tutorial/megaparsec.html)를 많이 참고했다.

먼저 우리의 `Parser` 타입을 만들어야 한다. 앞으로 만들게 되는 파서들은 이 타입을 가지게 될 것이다.

```haskell
-- src/Parser.hs
module Parser where

import Data.Void (Void)
import Text.Megaparsec (Parsec)
import Data.Text (Text)

type Parser = Parsec Void Text
```

여기서 `Void`는 파싱 에러의 타입을 뜻하고, `Text`는 입력 소스의 타입을 의미한다. 개발 과정을 단순화하기 위해 에러 타입은 `Void`로 두었다.

### AST 정의

가장 먼저 Syntax 트리를 정의하겠다. Syntax 트리는 코드를 파싱한 결과물을 나타내는데, 우선 하나의 S-Expression을 나타내는 타입을 다음과 같이 정의해볼 수 있다.

```haskell
-- src/Parser.hs
data Sexpr = Paren [Sexpr]
           | Number Int
           | Ident String
	    deriving Show
```

Syntax 트리의 노드를 3가지로 간단하게 나타내 보았다. `Number Int`는 `3`과 같이 정수를 표현하고, `Ident String`은 `a`, `foo`와 같이 변수를 표현하며, 마지막으로 `Paren [Sexpr]`는 `(* a (+ 1 3))`와 같이 여러 개의 S-Expression을 괄호 사이에 담고 있는 형태를 나타낸다.

맨 밑줄에 있는 `deriving Show`는 자바로 치면 `toString` 메서드를 자동으로 만들어주는 것과 같다. 다음과 같이 `Sexpr` 타입의 variant를 직관적으로 출력하는 데 도움을 준다.

```haskell
main :: IO ()
main = do
    print $ Number 3 -- Output: Number 3
    print $ Ident "foo" -- Output: Ident "foo"
    print $ Paren [Ident "+", Number 1, Number 4] -- Output: Paren [Ident "+",Number 1,Number 4]
```

### Parser Combinator

[파서 콤비네이터](https://en.wikipedia.org/wiki/Parser_combinator)는 모나드를 응용하여 재귀하향 파서를 작성하는 방법의 일종이다. 이름이 나타내듯이, 작은 파서를 조합하여 하나의 커다란 파서를 만들기 용이하다.

예를 들어 `megaparsec`에서는 `char`이라는 기본 파서가 있는데 이는 인자로 제공된 문자를 파싱한다.

```haskell
-- Main.hs
{-# LANGUAGE OverloadedStrings #-}

import Text.Megaparsec
import Text.Megaparsec.Char
import Data.Void (Void)
import Data.Text (Text)

type Parser = Parsec Void Text

main :: IO ()
main = do
    parseTest (char 'a' :: Parser Char) "a" -- 'a'
    parseTest (char 'a' :: Parser Char) "b" -- ERROR: unexpected 'b', expecting 'a'
```

`string`이라는 파서도 있다. 이는 인자로 제공된 문자열을 파싱한다.

```haskell
-- Main.hs
{-# LANGUAGE OverloadedStrings #-}

import Text.Megaparsec
import Text.Megaparsec.Char
import Data.Void (Void)
import Data.Text (Text)

type Parser = Parsec Void Text

main :: IO ()
main = do
    parseTest (string "foo" :: Parser Text) "foo" -- "foo"
```

위 두 예시는 정규표현식으로도 표현이 가능한데, 균형 잡힌 괄호 문제와 같이 regex는 표현하지 못하는 것들도 파싱할 수 있다.

```haskell
data ParenExpr = Empty | Concat ParenExpr ParenExpr deriving Show

parenExprParser :: Parser ParenExpr
parenExprParser = between (char '(') (char ')') innerExpr <|> emptyExpr
  where
    innerExpr = do
      left <- parenExprParser
      right <- parenExprParser
      return $ Concat left right
    emptyExpr = return Empty

main :: IO ()
main = do
    parseTest parenExprParser "(())()" -- Concat (Concat Empty Empty) Empty "foo"
```

### 숫자 파싱

그럼 이제 `megaparsec`에서 제공해주는 기본 파서를 이용해 AST의 정수 부분을 파싱해보자.

```haskell
-- Main.hs
{-# LANGUAGE OverloadedStrings #-}

import Text.Megaparsec
import Data.Void (Void)
import Data.Text (Text)
import qualified Text.Megaparsec.Char.Lexer as L

type Parser = Parsec Void Text

main :: IO ()
main = parseTest (L.decimal :: Parser Int) "345" -- 345
```

보이는 것과 같이 `Text.Megaparsec.Char.Lexer`의 `decimal` 함수는 10진수 숫자를 파싱해준다. 이때 파싱한 결과는 `Parser Int` 타입인데, 우리가 원하는 것은 `Parser Sexpr` 이다.

어떻게 바꿀 수 있을까?

`Parser` 타입이 모나드라는 사실은 이럴 때 도움이 된다. 이미 모나드에 대해 알고 있는 것을 그대로 적용할 수 있기 때문이다. 모나드가 Functor라는 사실을 알고 있다면, `fmap` 함수를 이용해 내부의 타입을 다음과 같이 변환할 수 있다.

```haskell
parseTest (Number <$> L.decimal :: Parser Sexpr) "345"
```

따라서 우리의 `number` 함수는 다음과 같이 정의할 수 있다.

```haskell
-- src/Parser.hs

-- ...
number :: Parser Sexpr
number = Number <$> L.decimal
```

### 식별자 파싱

이제 조금 더 어려운 식별자를 파싱해보기 전에 식별자가 어떻게 생겼으면 좋겠는지 정의할 필요가 있다. PHP나 JS는 변수명이 `$`로 시작하는 것을 허용하지만, 파이썬은 허용하지 않는 것을 보았을 때, 식별자의 생김새는 정하기 나름이다.

Lisp 계열 언어는 식별자 명명에 꽤 관대한 편이다. 따라서 이렇게 규칙을 정하겠다.

1. 식별자는 알파벳, 숫자, 그리고 특정 특수기호로 이루어져 있다
2. 식별자의 길이는 1 이상이다.
3. 식별자는 숫자로 시작할 수 없다.

1번의 "특정 특수기호"는 ASCII 테이블 안의 특수기호 중 `!"#$%&'*+,-./:<=>?@^_~` 를 의미한다.

여기서 전략은 두 개의 작은 파서를 만드는 것이다. 파서 A는 첫번째 글자만을 위한 파서이다. 즉 알파벳과 기호를 인식하는 파서이다. 파서 B는 나머지 글자들을 위한 파서이다. 즉 알파벳, 기호, 숫자까지 인식할 수 있다. 그 뒤 파서 A와 B를 합치면 식별자 파서가 되는 것이다.

파서 A는 다음과 같이 만들 수 있다.

```haskell
import Text.Megaparsec ((<|>))
import Text.Megaparsec.Char (letterChar)

first :: Parser Char
first = letterChar <|> symbolChar
```

`<|>` 연산자의 사용을 볼 수 있는데, 이는 연산자 앞에 있는 파서가 실패하면 뒤에 있는 파서를 시도해보라는 뜻이다. 즉 `letterChar`이 인식하지 못하면, `symbolChar`이 시도를 해보는 것이다. 만약 `symbolChar` 까지 인식하지 못한다면 에러가 발생할 것이다.

`letterChar`은 `megaparsec`에서 가져왔으나, `symbolChar`은 없는 것을 볼 수 있는데, 이는 `megaparsec`에 있는 `symbolChar`이 위에서 정의한 기호들과 일치하지 않기 때문이다. 직접 `symbolChar`를 정의해보자.

```haskell
import Text.Megaparsec (satisfy)
import qualified Data.Set as Set

symbols :: Set.Set Char
symbols = Set.fromList "!\"#$%&'*+,-./:<=>?@^_~"

symbolChar :: Parser Char
symbolChar = satisfy (`Set.member` symbols)
```

위에선 `satisfy`라는 `megaparsec`의 함수를 사용했는데, 주어진 predicate 함수를 만족하는 문자만 인식하게 하는 것이다. 우리는 predicate로 연산자 집합에 있는 문자만 인식하는 함수를 건넸다.

이제 두 개의 작은 파서가 완성되었다. 이를 조합해 식별자 파서를 완성시켜보자.

```haskell
-- src/Parser.hs
import Text.Megaparsec ((<|>), many, satisfy)
import Text.Megaparsec.Char (letterChar, alphaNumChar)

symbols :: Set.Set Char
symbols = Set.fromList "!\"#$%&'*+,-./:<=>?@^_~"

symbolChar :: Parser Char
symbolChar = satisfy (`Set.member` symbols)

ident :: Parser Sexpr
ident = Ident <$> p
    where
        first = letterChar <|> symbolChar
        rest = many (alphaNumChar <|> symbolChar)
        p = (:) <$> first <*> rest
```

위 코드에서 눈여겨볼 점들은:

1. `many` 함수를 이용하여 "하나의 문자를 인식하는 파서"를 "0개 이상의 문자를 인식하는 파서"로 만들었다.
2. `(:)` 리스트 cons 연산자를 이용하기 위해 `fmap(<$>)`과 `<*>`를 사용했다. `fmap`은 모나드가 functor이기 때문에 가능하고, `<*>`은 모나드가 applicative이기도 하기 때문에 가능하다.

### 리스트 파싱

이제 마지막 variant인 `Paren`을 파싱해보자. 안에 여러 개의 S-Expression을 담고 있기 때문에 리스트라고 부르겠다. 리스트를 파싱하기 위해 그것의 특성을 먼저 살펴보자.

1. `(`으로 시작한다.
2. `)`으로 끝난다.
3. 사이에 1개 이상의 S-Expression이 공백으로 구분되어 있다

가장 어려운 부분은 3번이다. 우선 리스트 안에는 또다른 S-Expression이 있기 때문에 재귀호출이 필요해 보이고, 또 공백을 어떻게든 처리해야 한다. 방법은 다양하겠지만, **파싱이 끝난 이후에 발생하는 공백을 consume하고 무시하도록** 파서를 수정하도록 하자.

이를 돕도록 유틸리티 함수를 하나 만들겠다. 파서를 입력으로 받아, 해당 파서가 하는 일 + 뒤에 있는 공백을 무시하는 파서를 만들자.

```haskell
import Text.Megaparsec.Char (space)

lexeme :: Parser a -> Parser a
lexeme p = p <* space
```

이를 이용하여 기존 파서들을 수정하자. 위 함수를 사용하면 꽤 간단하다.

```haskell
number :: Parser Sexpr
number = Number <$> lexeme L.decimal

-- ...
ident :: Parser Sexpr
ident = Ident <$> lexeme p
    where
        first = letterChar <|> symbolChar
        rest = many (alphaNumChar <|> symbolChar)
        p = (:) <$> first <*> rest
```

이로써 이 파서들은 뒤에 있는 공백까지 무시하는 기능까지 추가되었다.

```haskell
main :: IO ()
main = do
    parseTest (liftA2 (,) number ident) "345 foobar" -- (Number 345,Ident "foobar")
```

두 파서를 연속으로 실행시켜도 공백을 무시하고 잘 파싱해준다.

이제 유용한 함수를 하나 더 소개하겠다. 바로 `many`와 `some`인데, `many p`는 파서 `p`를 0번 이상 실행시켜 그 결과를 돌려주고, `some p`는 파서 `p`를 1번 이상 실행시켜 그 결과를 돌려준다.

즉, `many number`는 공백으로 구분된 0개 이상의 연속된 숫자를 파싱할 수 있고, `some ident`는 공백으로 구분된 1개 이상의 연속된 식별자를 파싱할 수 있다.

리스트 안에는 1개 이상의 S-Expression이 필요하기 때문에 `some`을 쓰면 된다. 근데 어떤 파서를 1번 이상 실행하면 될까? 우선은 그것을 `sexpr`라 부르기로 하고 조금 이따 돌아와보자.

종합해 보아 `paren` 파서를 만들어 보자. `(`로 시작하고, `p`를 1번 이상 실행한 뒤, `)`로 끝나는 것이다.

```haskell
import Text.Megaparsec (some)
import Text.Megaparsec.Char (char)

paren :: Parser Sexpr
paren =
  lexeme
    ( do
        _ <- char '('
        ss <- some sexpr -- ERROR: Variable not in scope: sexpr
        _ <- char ')'
        return $ Paren ss
    )
```

에러가 날 것이지만 우선은 S-Expression을 종합적으로 파싱해주는 `sexpr`를 완성해보자. 이미 S-Expression의 variant는 모두 파싱할 수 있으니, 이를 조합만 하면 된다.

```haskell
sexpr :: Parser Sexpr
sexpr = paren <|> number <|> ident
```

잘 되는지 확인해보자!

```haskell
main :: IO ()
main = do
    parseTest sexpr "(+ 1 2 3)" -- Paren [Ident "+",Number 1,Number 2,Number 3]
    parseTest sexpr "(+ 1 (* foo spam) 4)" -- Paren [Ident "+",Number 1,Paren [Ident "*",Ident "foo",Ident "spam"],Number 4]
    parseTest sexpr "5" -- Number 5
    parseTest sexpr "foo" -- Ident "foo"
```

문제없이 잘 파싱이 된다면 지금까지 잘 따라온 것이다🎉🎉

NOTE: `paren`은 다음과 같이 간결하게 나타낼 수도 있다!

```haskell
paren :: Parser Sexpr
paren = Paren <$> lexeme (char '(' *> some sexpr <* char ')')
```

아래는 지금까지 작성한 파서 코드이다.

```haskell
-- src/Parser.hs
module Parser (Sexpr (..), number, ident, paren, sexpr) where

import Data.List.NonEmpty (NonEmpty (..))
import qualified Data.Set as Set
import Data.Text (Text)
import Data.Void (Void)
import Text.Megaparsec (ErrorItem (..), MonadParsec (token), Parsec, Stream (Token), many, satisfy, some, (<|>))
import Text.Megaparsec.Char (alphaNumChar, char, letterChar, space)
import qualified Text.Megaparsec.Char.Lexer as L

type Parser = Parsec Void Text

data Sexpr
  = Paren [Sexpr]
  | Number Int
  | Ident String
  deriving (Show)

lexeme :: Parser a -> Parser a
lexeme p = p <* space

number :: Parser Sexpr
number = Number <$> lexeme L.decimal

symbols :: Set.Set Char
symbols = Set.fromList "!\"#$%&'*+,-./:<=>?@^_~"

symbolChar :: Parser Char
symbolChar = satisfy (`Set.member` symbols)

ident :: Parser Sexpr
ident = Ident <$> lexeme p
  where
    first = letterChar <|> symbolChar
    rest = many (alphaNumChar <|> symbolChar)
    p = (:) <$> first <*> rest

paren :: Parser Sexpr
paren = Paren <$> lexeme (char '(' *> some sexpr <* char ')')

sexpr :: Parser Sexpr
sexpr = paren <|> number <|> ident
```

여기까지가 파싱이다. 다음 포스트에서는 평가 부분을 다루도록 하겠다.


하스켈로 간단한 Lisp 만들기 - 파싱


2023년 6월 4일, 오늘은 제 전역날입니다. 평소같이 아침에 부대 생활관에서 일어나고, 평소같이 점호를 받았지만 이젠 마지막이었습니다. 군생활하며 이미 후임보다는 친구, 형 동생과 같았던 수병들에게 과분한 축하를 받고 정문을 나왔습니다.

입대할 땐 이날이 언제 오나 싶었지만, 점점 다가올수록 오히려 불안한 심정을 느끼기도 했었습니다. 제가 전역하고 무엇을 할지, 2023년이 막 되었을 당시에도 제대로 결정하지 못했었습니다. 하지만 머지 않아, 결국 저는 선교사업을 하러 떠나기로 결정했습니다.

선교사업을 결심한 첫 번째 이유는, 저의 신앙을 강화하고 싶어서였습니다. 제가 영적으로 완전히 자립하지 않았다고 자주 느꼈었습니다. 시간이 많았던 군생활 말년에, 선교사업을 준비하여 주님의 말씀을 열심히 구했습니다. 저는 기도의 응답으로 가슴이 따뜻해지는 경험도 하고, 무엇보다 제가 스스로 중요하다고 생각했던 가치들이, 사실은 교회를 다니며 만들어진 가치들이라는 것을 알게 되었습니다. 선교사로서 다른 사람들에게도 같은 기회를 주고 싶다는 새로운 동기도 찾았습니다.

선교사로서 봉사하겠다는 신청을 하게 되면, 몇 개월 뒤 교회 본부에서는 언제부터, 어느 곳에서 봉사할지를 결정하여 부름장에 담아 회신합니다. 제가 전역하는 날에 부름장을 열어보게 될 줄은, 부름장이 도착한 전역하기 전날이 되어서야 알게 되었습니다. 집에 도착하여 가족과 함께 부름장을 열었고, 제가 **8월 7일부터 뉴욕 시티 선교부**에서 봉사하게 될 것을 알았습니다.

선교 활동을 하며 어떤 일이 벌어질지 전혀 모르겠습니다. 하지만 많은 사람들을 돕고, 그 과정에서 저 스스로도 많은 성장을 하게 될 것과, 그 시간이 헛되지 않을 것 또한 알고 있습니다. 가기 전까지 남은 짧은 시간동안 잘 준비하여 더 훌륭한 주님의 도구로서 봉사할 수 있도록 하겠습니다!

> 이에 이제 이렇게 되었나니 앨마와 그의 형제들 위에 지워진 짐이 가벼워졌고, 참으로 주께서 그들을 강하게 하사 그들로 쉽게 그들의 짐을 지게 하시매, 그들이 주의 모든 뜻에 즐거이 인내를 가지고 복종하였더라. (모사이야 24:16)


전역, 그리고 안녕

Simple but Powerful Pratt Parsing


2021년 9월 입대하기 직전에 블로그 하나는 갖고 싶다는 생각이 들어 부랴부랴 블로그를 만들었다. 그리고 해군 개발병에 대한 정보가 인터넷에 워낙 부족했어서 이를 조금이라도 해소하고 싶어 지원 후기를 작성했었다. 그 기억들이 아직 생생한데, 지금 전역을 앞두고 있는 나를 보니 군생활이 생각보다 빨리 지나간 것 같다. 이 글에는 **개발병으로서** 복무한 후기를 적어보겠다. 누군가에게 이 글이 도움이 됐으면 좋겠다.

## 실제로 개발을 하나요?

내가 가장 걱정했던 부분 중 하나이다. 많은 정보를 알지 못한 채 훈련소에 입대했었는데, 그 기수에는 개발병이 나 혼자였다(21\~22년 기준 평균 2기수당 1\~2명 입대). 그래서 훈련소 동기들은 물론, 훈련소에 있는 훈련 교관들도 개발병 직별에 대해 모른다. 밖이랑 단절된 채로 6주를 있으려니 자대는 어딘지, 진짜 개발은 하는지, 그냥 다른 전산병들이랑 같이 컴퓨터 정비를 하게 되진 않을지 고민하다 보면 별걸 다 상상하게 된다. 옆에 있는 훈련소 동기들에게, "진짜 개발 하겠어? 그냥 컴퓨터 좀 고치겠지"라는 말을 몇번 듣고 나면 꽤 불안해진다. 근데 알고보니 자대는 한 곳으로 정해져 있고(면접본 곳), 주 업무는 정말 개발이 맞았었다. 오히려 개발을 실컷 할 수 있다. 개발 가능한 인력이 병밖에 없기 때문이다.

## 개발 환경은 어떤가요?

사무실에서는 앱/웹에 올라가는 다양한 프로젝트를 진행한다. 때문에 프로젝트의 특성은 제각각이지만, 그 중 인트라넷 환경에 대해 이야기해보고 싶다.

군 부대는 보안 유지를 위해 인트라넷을 사용한다. 쉽게 말해 전국의 군 부대들이 사용하는 폐쇄망이 있다는 건데, 이는 인터넷이랑 연결되어있지 않다. 개발 또한 인트라넷 환경에서 하는데, 이로 인해 생기는 문제가 몇 가지 있다.

우선 패키지 다운로드에 제약이 생긴다. 요새 라이브러리 없이 개발하는 건 상상하기 힘들다. 특히 웹, 앱 개발은 정말 많은 라이브러리의 기능을 가져다 쓰는데, 인터넷 접속이 안된다는 것은 `npm`이나 `maven`의 접속이 안된다는 이야기다. 따라서 패키지를 외부에서 다운받아 보안절차를 거쳐 인트라넷으로 가져오는데, 보안절차가 사이에 있는 것이 개발생산성 측면에서 꽤 방해가 된다. 미리 설치해서 가져온다는 건 무엇을 쓸지 한번에 생각해서 전부 미리 받아온다는 것인데, 무엇을 쓸지 미리 생각한다는 것이 쉽지가 않다.

다음으로는 재사용 문제가 있다. 인터넷에서 인트라넷으로 패키지를 들고 와 사용한다고 이야기를 했는데, 슬프게도 힘들게 가져온 패키지를 다른 프로젝트에 재사용하기가 쉽지많은 않다. 어떤 패키지의 의존성을 수동으로 확인하기가 너무 어렵고, 의존성의 버전도 여러 가지가 있기 때문이다.

패키지뿐만이 아니다. 개발 툴들도 취향껏 쓰기가 어렵다. 이유는 앞과 동일한데, 그래서 기존에 인트라넷에 있는 툴들을 사용하는 데 어느정도 만족해야 한다. 이 부분은 라이브러리도 마찬가지다. 나는 리눅스 환경을 선호해서 WSL을 쓰고 싶었는데 그러지 못해서 아쉬웠다.

## 성장할 수 있었나요?

같이 한 사람들 모두가 동의할지는 모르겠으나, 개인적으로 많이 배울 수 있는 직별이라고 느낀다. 자대에 처음 갔을 때는, 물론 그만한 이유는 있었지만 개발자 입장에서는 상대적으로 열악한 환경에 실망했다. 하지만 오히려 환경에 조금 제약이 있으니 같은 문제여도 고민을 더 많이 하고, 환경을 개선하기 위해 직접 노력할 수 있는 부분이 있어 경험을 쌓을 수 있었다. 나는 자바에 대해 원래 악감정이 있었는데 가서 백엔드 개발을 자바와 스프링으로 해야 했었다. 덕분에 처음으로 스프링(부트 X. 레거시 O)을 배워볼 기회가 생겼고, 사용해보니 꽤 좋은 프레임워크라는 것을 느꼈다. 또한 비록 언어로서의 단점은 존재하는 자바지만, 언어를 둘러싼 생태계가 정말 탄탄하다는 것을 알게 되었다. 사실 자바는 언어로서도 이미 꽤 많이 발전했는데, 아직 많은 사용자들이 자바 1.8 / 11에 머무느라(현재 자바 20까지 출시됨) 그 기능들과 향상된 JVM을 사용하지 못하고 있다는 것은 슬픈 일이다.

병 1~2명이 한 프로젝트를 주도하기 때문에 직접 해결해야 하는 문제들도 많았다. 병으로 입대하는 사람이면 보통 나이가 20대 초중반인데, 나는 방학 때 인턴 몇 번 빼곤 학교만 다니다 갔고, 주변에 회사생활 몇 년 하고 온 사람들도 있지만 병들 실력이 많이 해봐야 주니어 정도다. 하지만 그곳에선 모든 개발을 해야 하니 이곳저곳에서 문제를 많이 만나기 마련이었다. 그래서 내가 만든 서비스를 쓰는 사용자들에게는 조금 미안하지만 오히려 나에게는 직접 경험을 쌓을 수 있는 시간이기도 했다.

여가시간도 충분했다. 근무시간에 개발을 하지 않았어도 여가시간을 잘 활용하면 개발 공부를 충분히 할 수 있는 시간이었다. 나는 여가시간에 폰하고 테니스를 많이 했다.

무엇보다 함께 지내는 선후임 병사들이 정말 좋은 사람들이었다. 어느정도 같은 분야를 공부하는 사람들끼리 다같이 있으니 평소에 개발 이야기도 할 수 있고, 좋은 개발 서적들도 주변에서 많이 추천해줘서 유익한 경험을 할 수 있었다.

## 총평

전체적으로 꽤 만족하는 편이다. 힘든 점이 있다면 당직근무가 꽤 자주 있었다는 점이지만, 준비를 좀 한다면 그보다 많은 편의를 자대에서 누릴 수 있는 직별이라고 생각한다. 또 이 글에서는 개발 이야기만 주로 했으나 부대 자체가 워낙 좋은 편이고, 주변 사람들도 좋아서 흔히 얘기하는 악성 선후임을 볼 일이 거의 없는 점도 큰 메리트이다.


해군 SW 개발병 복무 후기


링크 페이지를 개업하면서 오랜만에 블로그를 업데이트했다. 미디어 쿼리를 손본다거나 폰트 사이즈를 반응형으로 바꾼다거나 주로 모바일에서 더 볼만하게 하는 변화들이었다.

링크 페이지를 개업한 이유는 지극히 개인적이다. 난 유튜브나 레딧에서 개발 관련 영상이나 게시물이 자주 추천되는 편이다. 해당 자료들을 통해 조금씩 관련 분야 지식들을 쌓는 편인데, 문제가 하나 있다. 좋은 게시물이나 영상들은 보통 길이와 깊이가 꽤 된다는 점이다. 그래서 휴대폰에서 어떤 좋은 링크를 접하게 되었을 때 그걸 한 번 앉아서 끝까지 읽을 수가 없다. 보통 집중할 수 있는 환경도 아니고, 결심하고 읽어야 이해할 수 있을 것 같은 자료들도 꽤 많다. 특히나 휴대폰으로는 다른 딴짓을 하기 꽤 쉬워서 읽다가 탭을 닫고 잊어버리는 일도 자주 있다. 이러한 문제점으로 인해 내 관심사는 계속 바뀌는 데에 반해 조금이라도 알아보고 넘어가는 경우가 많이 없다는 것을 오랜 시간이 지난 뒤에야 알았다.

그래서 흥미로운 링크들을 한 곳에 모아둘 필요성을 느꼈고, 돌아보니 그렇게 하는 사람들을 꽤 많이 본 적이 있었다는 것이 기억났다. 링크 페이지를 블로그에 추가하기로 하였고 바로 페이지를 만들었다. 링크들은 [이 섹션](https://pacokwon.org/links)에서 확인할 수 있다.

이 링크들을 어떻게 관리할지 또한 문제였다. 흥미로운 링크를 마주칠 때 빠르게 쌓아둘 수 있는 구조여야 하고, 블로그에도 그 변경사항을 반영할 수 있어야한다. 근데 이 블로그는 정적으로 만들어져 있고, 링크를 추가하고 싶다고 코드를 직접 수정하는건 너무 접근성이 떨어지는 방법이었다. 서버 애플리케이션이 하나 필요하다는 것이 거의 당연해져서 간단한 프로젝트를 하나 만들기로했다. 당시에는 내가 [Elixir](https://elixir-lang.org)라는 언어에 관심이 높았을 때라 Elixir를 배워보는 김에 링크를 쉽게 등록할 수 있는 웹 기반 페이지를 작성했다. Elixir에는 [Phoenix Framework](https://www.phoenixframework.org/)라는 평가가 좋은 서버 프레임워크가 있는데, 너무 기능이 많은 것 같아서 Phoenix가 기반을 두고 있기도 한 [Plug](https://github.com/elixir-plug/plug)로 백엔드를 작성했다. 써보니 Plug는 정말 barebones여서 실제 프로젝트에는 쓰기 어려울 것 같았지만 이 링크 관리 페이지를 만드는 데에는 좋은 경험이었고, 특히 [이 발표](https://www.youtube.com/watch?v=Z0Z4wu4CPgQ&t=1364s)가 정말 유익했다.

결과적으로 링크 관리 페이지를 이용해 원할 때 블로그의 데이터를 수정해서 직접 Github에 push를 하여 자동 업데이트되도록 만들었고, 아직까지는 만족스럽게 동작하고 있다. 관리 페이지 구현체는 [이곳](https://github.com/pacokwon/linkwaiter)에 있다. 이를 적극 활용하여 흥미로운 것이 많을 때는 페이지에 잘 쌓아두고, 흥미로운 것이 떨어질 때는 페이지에서 잘 뽑아 공부해야겠다.


링크 페이지 개업


이 글에는 내가 주로 사용하는 neovim 에디터 환경설정, 그 중 플러그인에 대해 적어보려 한다 (한마디로 별 쓸데없음).

neovim이 `0.5.0` 업데이트 이후로 lua의 first class support를 추가하였고, 점점 쓰기 편하게 개발이 진행되고 있는 상태이다. 나는 vimscript와 lua 모두 아주 잘 알지는 않지만 그냥 궁금해서 환경설정 일부는 lua로 바꿔둔 상태이다. 물론 이렇게 하고 나니 그냥 vim 쓸 때는 호환이 안되는게 좀 불편해서 vim 용 설정은 따로 유지를 해야 하나 싶다...암튼 그래서 내 현재 neovim 설정은 일부가 lua로 적혀있을 뿐만 아니라 아주 많은 lua plugin을 사용하고 있다.

내 환경설정은 [여기](https://github.com/pacokwon/nvim-config)에서 관리하고 있다. 현재 설정 모습은 이렇다.

```plaintext
.
├── init.vim            # config root file
└── lua                 # configs written in lua
   ├── colors.lua       # theme
   ├── init.lua         # root file written in lua
   ├── mappings.lua     # keymappings
   ├── opts.lua         # editor options
   └── plugins          # plugin configuration
```

## Plugin Manager

나는 한동안 `vim-plug` 를 사용하다가 `packer.nvim` 으로 플러그인 매니저를 갈아탄 상태다. lua로 작성돼있다. 유저도 많고 굉장히 빠르다고 되어있길래 한 번 갈아타봤는데 실제로 빠른 것 같기도 하고 별 문제없이 작동하는 것 같아서 그냥 계속 사용하고 있는 중이다.

## Plugins

내가 주로 사용하는 플러그인 목록이다. 실제 사용하는건 나열한 것의 1.5 ~ 2배 정도 되지 않을까 싶다.

### [nvim-miniyank](https://github.com/bfredl/nvim-miniyank)

clipboard를 system clipboard로 연결해둔 상태일 때 neovim에서 Visual Block 붙여넣기가 잘 작동하지 않는 버그가 있다. 이유가 뭔지는 까먹었었는데 플러그인의 형태로 솔루션이 존재해서 사용하고 있다.

### [galaxyline.nvim](https://github.com/glepnir/galaxyline.nvim)

아주 미니멀하고 커스터마이징이 쉬운 statusline이다. 모든 걸 직접 설정해줘야 한다는 장벽이 있지만 한번 설정해놓으면 문제없다. 그래서 아주 심플한 statusline을 쓰고 있다. lua로 되어있다.

### [lspsaga.nvim](https://github.com/glepnir/lspsaga.nvim)

아주 필수적인 플러그인은 아니다. 나는 LSP diagnostics를 조금 더 꾸며진 floating window에서 보고 싶어서 설치해 두었다. LSP hover docs의 경우 요 플러그인에서 제공하는 함수를 사용하고 있었는데 lspconfig 플러그인에서 거의 같은 기능을 제공하고 있어서 갈아탔었다. diagnostic 쪽도 같은 기능을 lspconfig에서 제공하고 있으면 그냥 안 써도 무방할 것 같다.

### [nvim-compe](https://github.com/hrsh7th/nvim-compe)

LSP autocompletion을 completion list로 보여주는 플러그인이다. 이미 LSP가 있어도 이러한 플러그인이 있어야 LSP 자동완성을 편하게 사용할 수 있다.

아마 지금 글 쓰는 시점에서는 deprecated된 것으로 아는데 아무 문제 없어서 그냥 쓰고 있다ㅋㅋ듣기로는 같은 개발자의 `nvim-cmp` 라는 플러그인이 거의 같은 역할을 하는데 scalability를 염두에 두고 다시 작성한 것으로 알고 있다.

처음에 LSP 지원이 나왔을 때는 `nvim-completion` 인가? 라는 플러그인이 거의 유일했는데 이게 훨씬 나아서 나 포함해서 사람들이 요걸로 갈아탔었다.

### [fzf.vim](https://github.com/junegunn/fzf.vim)

`fzf` 라는 fuzzy finder를 vim에서 쉽게 사용할 수 있도록 한 wrapper이다. 놓칠 수 없는 플러그인들 중 하나다. 매우 빠르다는 것이 장점이고 Silver Searcher, ripgrep, fd 등 내부에서 사용하는 커맨드 또한 변경 가능해서 gitignore를 respect하게 하는 등의 기능 또한 가능하다.

### [gitsigns.nvim](https://github.com/lewis6991/gitsigns.nvim)

라인마다 깃 상태를 보여주는 플러그인이다. 특정 줄들이나 블록을 stage, unstage, reset하는 함수들을 제공한다. vscode의 gitlens에서 제공하는 라인별 blame 정보 보여주기나, 깃 상태가 바뀐 줄에 대하여 floating window에서 diff를 보여주는 기능 또한 매우 유용하다. lua로 작성되어 있으며 이전에는 gitgutter라는 vim 플러그인을 썼었다.

### [nvim-lspconfig](https://github.com/neovim/nvim-lspconfig)

LSP 설정을 위한 플러그인이다. LSP Client 기능 자체는 neovim에 내장되어 있지만, 설정을 간편하게 해주는 용도로 존재하는 플러그인이다. LSP가 없으면 안되는 것은 아니지만 사용하게 되면 삶의 질이 많이 올라가기 때문에 나는 되도록이면 쓰려고 한다. 근데 설정이 좀 어려운 경우도 있기는 하다.

### [nvim-treesitter](https://github.com/nvim-treesitter/nvim-treesitter)

Treesitter 설정을 위한 플러그인이다. 설정에서 어떤 언어들에 대하여 treesitter를 사용할지 선택할 수 있고, 그에 따른 treesitter syntax highlighting을 제공한다. 훨씬 일관적인 highlighting을 사용할 수 있다. 이 플러그인이 있으면 언어별로 추가적인 highlight group을 담고 있는 플러그인을 설치해서 사용할 필요가 없어진다.

### [pears.nvim](https://github.com/steelsojka/pears.nvim)

autopairs 플러그인이다. lua로 작성되어 있으며 내가 한창 lua로 작성된 플러그인들을 시도하던 와중 갈아탔었다. autopairs라는 것은 예를 들어 `(` 를 입력하면 그 옆에 `)` 가 자동으로 입력된다거나, `)` 바로 왼쪽에서 `)` 를 누르면 해당 문자를 한 번 더 적는 게 아니라 알아서 건너뛰는 기능을 이야기한다. 근데 이 플러그인의 경우 개발이 활발하지는 않아서 엄청 추천하지는 않는다. 오히려 기존에 사용하던 jiangmiao의 auto-pairs가 기능도 조금 더 많고 안정적인 것 같다. lua로 작성된 다른 autopairs 플러그인도 많다.

### [vim-commentary](https://github.com/tpope/vim-commentary)

주석 처리용 플러그인이다. 놓칠 수 없는 플러그인들 중 하나다. 설치를 하면 `gc` 라는 verb가 생긴다. verb라는 것은 `d`, `c`, `v` 같은 동작을 하는 키바인딩을 이야기한다. 예를 들어 `gcj` 를 입력하면 현재 줄과 아래 줄이 주석 처리된다. 매우 편리하고 사용하기도 자연스러워서 그냥 vim 코어에 통합돼도 아무 문제가 없을 것 같다.

### [vim-surround](https://github.com/tpope/vim-surround)

`(`, `{`, `[`, `'`, `"` 처럼 짝꿍이 있는 문자들을 위한 플러그인이다. 놓칠 수 없는 플러그인들 중 하나다. 설치하면 `ys`, `ds`, `cs` 등의 verb가 생긴다. 예를 들어 `ysiw(` 를 하면 현재 커서가 있는 단어를 `()` 로 감싼다. `ds(` 를 하면 괄호를 삭제하고, `cs({` 를 하면 소괄호를 중괄호로 바꿔준다. 용법이 매우 자연스럽고 이것도 그냥 코어에 통합돼도 문제 없을 것 같은데...

### [vim-fugitive](https://github.com/tpope/vim-fugitive)

Git wrapper 플러그인이다. 플러그인 중 거의 1순위다. 있으면 git 관리가 정말 편해진다.

## Colorschemes

테마도 신경쓰는 편이다. 나는 대체로 high contrast 테마를 좋아한다.

- [tokyonight.nvim](https://github.com/folke/tokyonight.nvim) - 차가운 계열의 테마다
- [srcery-vim](https://github.com/srcery-colors/srcery-vim) - 따뜻한 계열의 테마다
- [modus-theme-vim](https://github.com/ishan9299/modus-theme-vim) - high contrast 만땅이면서 색깔이 마음에 든다
- [panic.vim](https://github.com/pacokwon/panic.vim) - 역시 high contrast 만땅이다. 다만 유지보수가 되고 있지는 않아서 fork해서 내가 사용하는 플러그인들에서 요하는 highlight group들을 추가해 쓰는 중이다.
- [onedarkhc.vim](https://github.com/pacokwon/onedarkhc.vim) - 기존에 있던 onedark의 색깔들을 수정해서 조금 더 high contrast로 만들어 두었다. 사실 색깔만 바꾼거라 fork하는게 맞는데 1학년 때 암 생각없이 만들었어서 README에 credit만 해놓은 상태다.


Development Environment - Neovim


Rust로 뭔가는 만들어보고 싶은데 마침 에뮬레이터도 만들어보고 싶어서 입문용 프로젝트로 많이 한다는 Chip-8 에뮬레이터를 작성해보려고 한다. 아직 시작도 안했기 때문에 여기 적을 내용은 많지 않다. 이 포스트를 업데이트해가며 짜려고 한다.

### Update:

생각보다 instruction 개수가 적고 구조도 단순한 편이라 구현이 이틀 정도만에 완성되었다. 좀 생소했던 부분들은 크게 두 가지였는데, 첫 번째는 opcode 구현 시 명세가 인터넷에 있는 참고자료마다 다른 경우가 있었다는 거다. 그래서 뇌피셜 + 다수의 의견을 따라 구현을 했다. 두 번째는 SDL2 사용인데, [SDL2 binding for Rust](https://github.com/Rust-SDL2/rust-sdl2) 의 문서화가 꽤 잘 돼있어서 데모 코드를 참고하니 생각보다 수월했다.

아주 제대로 된 테스팅은 진행하지 않았지만 [테스트 ROM](https://github.com/corax89/chip8-test-rom) 형태로 아주 손쉽게 테스팅해볼 수 있는 방법이 있어서 이 ROM을 실행해보긴 했다. 이 ROM을 통해 잡은 버그는 Rust에서 정수 연산 오버플로우가 자동으로 되지 않는다는 점이었다. 그래서 거의 모든 연산 부분을 그냥 오버플로우가 되도록 수정했다. `Wrapping`이라는 타입으로 해야 하던데 퍼포먼스 저하는 없는 것으로 알고 있다. 그냥 코드가 조금 더 verbose해질 뿐..

오디오 구현은 안(못)했는데 큰 관점에서 중요도가 떨어지는 반면 trivial한 해결 방법이 없어 그냥 냅둔 상태이다. `'\a'` 코드처럼 삑 소리만 나도 충분할 것 같던데 오래된 규약이다 보니 기기마다 `'\a'` 가 작동하지 않는 경우도 C 프로그래밍을 할 때 종종 보았는데 Rust에서는 그냥 지원이 안 되는 것 같았다. 뭔가 내가 모르는 쉬운 방법을 찾거나 아주 미니멀한 오디오 라이브러리를 사용하면 될 것 같다.

이 작은 프로젝트를 통해 에뮬레이터를 조금 더 자세히 이해할 수 있었던 것 같다. 그 다음 단계는 NES나 Gameboy 에뮬레이터 구현일텐데, 난이도 상승 폭이 조금 큰 것으로 보인다.

## Repository

https://github.com/pacokwon/scaters

## References

참고자료들이다. 꽤 오래된 매뉴얼들인데 필요한 내용은 모두 담고 있고 상당히 도움이 많이 되었다.

- http://www.cs.columbia.edu/~sedwards/classes/2016/4840-spring/designs/Chip8.pdf
- http://devernay.free.fr/hacks/chip8/C8TECH10.HTM


Building a Chip-8 Emulator in Rust


It's been two years since I've first used Vim.

The reason I started to learn Vim was because I saw so many experience programmers using it. I thought that there must be something special to it, and I had to give it a try.

It wasn't easy at first. There certainly is a learning curve, and I often was tempted to go back to my old editor. But once I got used to it, it only got better from there. I loved the speed, the efficient keybindings, the ecosystem of plugins, and the fact that it's still a minimal editor that I configured for myself.

Then there was Neovim. The first time I've heard about it was from [coc.nvim](https://github.com/neoclide/coc.nvim), which was one of the few plugins that had great LSP support out of the box. It was from then I started using Neovim.

I suspect that Neovim was version `0.4.x` at the time. I couldn't feel _any_ differences from Vim whatsoever, but it turns out Neovim at that time was in the verge of a major breakthrough: `0.5.0`.

## Neovim `0.5.0`

Neovim `0.5.0` introduced a ton of new updates to the editor, as a user, there were 3 major featuresthat were added in this release.

### Built-in LSP client support

The Language Server Protocol is a spec that allows independent "language servers" to communicate with and provide useful functionalities such as `Hover Docs`, `Goto Definition`, `Format` to editors that implement a "language client". The separation of responsibilities allowed: language servers to do what they do best, and editors to offer rich features without implementing it themselves.

Previously, plugins were acting as LSP clients to communicate with the respective servers, and this is what coc.nvim was doing really well. But I felt guilty using it because one could easily see that it was a little bloated. It did too many things at once, not to mention that it spawned node processes in the background.

The built-in LSP support in the `0.5.0` release allowed users to configure lsp servers to their own preference by providing a generic configuration interface. It felt minimal, it was less laggy, I knew what it was doing, and I loved it. One downside might be that it requires a fair amount of code to configure.

### tree-sitter syntax highlighting support

The way Vim does highlighting is through regexes (AFAIK). It parses tokens through regexes and applies the corresponding highlight groups to them. tree-sitter is a replacement for this highlighting method.

tree-sitter is a dedicated parser generator, meaning that it outputs a parser given a certain language's grammar. I've heard good things about tree-sitter such as its performance and tolerance to syntax errors, but I won't go further because I don't have background knowledge to back it up - for all I know, it does its job really well, and it is capable of providing consistent syntax highlighting across a ton of languages.

So far, the syntax highlighting that tree-sitter provides has been really great, and it's making me happy.

### lua as a first class configuration language

Previously and still in Vim 8, vimscript remains the primary language for editor configuration. And vimscript is.. such an odd language. I tried learning it, but the experience was not so good. It was not like any other language that I've learned, and not in a good way either. IMO this would have certainly prevented some users from being able to comfortably write their `vimrc`s or plugins.

And then lua came in. It's a very small scripting language that got integrated into Neovim from `0.5.0`. Unlike vimscript it's a general purpose language, it makes more sense and knowledge can be transferred from and to other languages more easily. This allowed users to write their `vimrc`s and plugins in lua and only using lua. The pace at which new plugins came out after lua was first integrated into Neovim was astonishing. Although there now exists incompatibilities between Vim and Neovim with lua plugins, I'm still very happy that the ecosystem is thriving much faster now.

As someone who loves using and making tools for developers, Neovim stands as my favorite open source project. And because of that, one of my goals is to try to create plugins and/or contribute to the Neovim project. At least I hope to do so.


Neovim 0.5.0 - A User's Perspective


While teaching myself some Rust, it was common to see some code that "looked like" it was destructuring references, like:

```rust
fn main() {
    let vec = vec![1, 2, 3];
    let mut iter = vec.into_iter();

    println!("Find 2 in vec: {:?}", iter.find(|&x| x == 2)); // Find 2 in vec: Some(2)
}
```

At first glance, the semantics were a little hard to predict. My curiosity all came down to this: does this copy the whole value? So I decided to write some code to make things clear.

```rust
#[derive(Debug,Clone,Copy)]
struct Foo {
    a: u32,
    b: u32,
}

fn main() {
    let mut x = Foo { a: 3, b: 4 };
    let &mut mut y = &mut x;        // destructure mutable reference, AND the variable is mutable
    y.a = 50;
    println!("{:?} {:?}", x, y);    // ??
}
```

### Output:

```bash
Foo { a: 3, b: 4 } Foo { a: 50, b: 4 }
```

A pretty minimal example here, but the syntax looks real weird. I actually had a hard time trying to express what I wanted to because of the syntax.

Once we try to mutate the struct's field, the output shows that only `y` is mutated. It shows us that it indeed copies the whole value.

What if we try to destructure something that does not implement the `Copy` trait, like a vector?

```rust
fn main() {
    let mut x = vec![1, 2, 3];
    let &mut mut y = &mut x;
    println!("{:?}", y);
}
```

### Output:

```bash
error[E0507]: cannot move out of a mutable reference
  --> src/main.rs:10:22
   |
10 |     let &mut mut y = &mut x;
   |         ----------   ^^^^^^
   |         |    |
   |         |    data moved here
   |         |    move occurs because `y` has type `Vec<i32>`, which does not implement the `Copy` trait
   |         help: consider removing the `&mut`: `mut y`

error: aborting due to previous error; 1 warning emitted
```

Pretty much the same example except that it's a vector, but the compiler complains for the exact reason why we tried this example in the first place. The destructure does not work because the `Vec` struct does not implement `Copy`. What I've understood from these examples, is that such destructuring is meant to be used on types that support cheap copying.

## References

- https://doc.rust-lang.org/rust-by-example/flow_control/match/destructuring/destructure_pointers.html


Destructuring & References in Rust


_This post is based on [this video](https://www.youtube.com/watch?v=WYysg5Nf7AU) from Graham Hutton's playlist on advanced functional programming. I tried to write this post without rewatching the video, to deliver my own understanding of the concept._

## Defining `State`

State를 표현하는 어떤 값이 있을 때, 이 state를 변경시키는 어떤 black box가 있다고 하자. 그 black box는 이렇게 표현할 수 있을 것 같다.

```haskell
blackBox :: a -> a -- where a denotes the state's type
```

이때 black box에서 input으로 들어온 state를 이용해 어떤 값을 계산한다고 가정한다면, 현재 함수의 타입 정보로는 해당 결과를 잘 표현하기 어렵다. 따라서 output을 두 개 돌려주는 다음과 같은 타입이 더 편리하다.

```haskell
blackBox :: a -> (b, a) -- where a denotes the state's type, and b the return value's type
```

이러한 black box에 해당하는 새로운 타입을 다음과 같이 작성해보자. Record에 대해 매번 pattern match를 하는 것을 방지하기 위해, `State`와 state 값이 주어졌을 때, transformer를 호출해주는 helper 또한 정의하자.

```haskell
newtype State a b = S {getState :: a -> (b, a)}

runState :: State a b -> a -> (b, a)
runState S {getState = f} = f
```

0부터 시작하는 id를 생성하는 함수가 있다고 하자. 이러한 상황에서는 ST를 다음과 같이 표현하여 id를 뽑아낼 수 있을 것이다.

```haskell
-- Plain.hs
next :: State Int Int
next = S $ \n -> (n, n + 1)

main :: IO ()
main = do
    let n0 = 0
    let (id, n)     = runState next n0
    let (id', n')   = runState next n
    let (id'', n'') = runState next n'
    print id        -- 0
    print id'       -- 1
    print id''      -- 2
    print n''       -- 3
```

`next` 라는 state transformer를 사용하면 id를 하나 생성하고 state를 하나 증가시키는 것을 확인할 수 있다. 따라서 `id`, `id'`, `id''`등 `next` ST에 새로운 state를 input으로 넣어 생성한 id들은 각각 0, 1, 2, 3의 값을 가지게 된다.

## 기존 방식의 문제점과 `bind` 함수

위 코드에서 문제점이 있다고 할 수 있는 부분은 composition이 불편하다는 점이다. `runState` 는 새로운 state를 만들어 내기 때문에, 이 함수를 여러 번 호출해야 하는 상황에서는 최신 state를 잘 넘겨주도록 유의해야 한다. 이를 위해 매번 pattern match를 해야 하고, 매번 state를 explicit하게 넘겨주어야 한다. 흐름 상으로만 보면 반복되는 코드인데 필요는 하기 때문에 일종의 boilerplate인 것이다. 이는 코드를 작성할 때 error prone하고, 읽을 때도 불필요한 디테일이다. 다음과 같은 문제점을 monad를 통해 해결해보자!

먼저 `bind` 함수를 정의해보자. `bind` 의 타입은 다음과 같다.

```haskell
bind :: m a -> (a -> m b) -> m b
```

이때 `m` 은 type constructor으로, 현재 상황의 경우 `State s` 에 해당한다.

```haskell
bind :: State s a -> (a -> State s b) -> State s b
```

state transformation을 두 번 시행함으로써 구현할 수 있다.

```haskell
bind :: State s a -> (a -> State s b) -> State s b
bind sa f = S $ \s ->
  let (a, s') = runState sa s in runState (f a) s'
```

이 함수만 있어도 composition이 더 깔끔해진다. 위에 있는 `main` 함수를 리팩토링해보자.

```haskell
-- Bind.hs
next :: State Int Int
next = S $ \n -> (n, n + 1)

main :: IO ()
main = fst $ runState (
    next `bind` \id ->
    next `bind` \id' ->
    next `bind` \id'' ->
    S $ \s -> (
      do
        print id
        print id'
        print id'',
      s
    ))
  0
```

(표준 출력을 위한 IO 조작 코드가 있는데...무시하고 보자)

`runState` 의 첫 번째 인자로 넘겨진 `State` 코드와, 위에 있는 리팩토링 이전 코드를 비교했을 때, trivial한 state 관리 코드가 아예 사라진 것을 확인할 수 있다. composition을 위해 매번 새로운 state를 다음 호출에 넘겨주던 패턴을 `bind` 라는 함수 안에 넣어두었기 때문에 핵심 코드가 더욱 중점적으로 드러나게 되었다.

이 `bind` 라는 함수는 `Monad` 타입클래스에 `(>>=)` 라는 함수의 형태로 존재한다. `State` 를 `Monad` 타입클래스의 인스턴스로 만들면 `do` notation의 syntactic sugar 또한 사용할 수 있게 된다. 다만 `Monad` 타입클래스의 인스턴스로 만들기 위해서는 그 superclass인 `Applicative` 까지 구현을 해야 하고, `Applicative` 의 superclass인 `Functor` 까지 구현해야 한다. 구현 코드는 다음과 같이 작성할 수 있다.

```haskell
import Control.Applicative

-- a type that contains a state transformer
-- the state transformer accepts a state, and returns a state with some return value
newtype State a b = S {getState :: a -> (b, a)}

runState :: State a b -> a -> (b, a)
runState S {getState = f} = f

instance Functor (State a) where
  -- fmap :: (a -> b) -> State s a -> State s b
  fmap f (S transform) = S (\s -> let (r, s') = transform s in (f r, s'))

instance Applicative (State a) where
  -- pure :: a -> State s a
  pure x = S $ \s -> (x, s)

  -- (<*>) :: State s (a->b) -> State s a -> State s b
  sf <*> sa = S $ \s ->
    let (f', s') = runState sf s
     in runState (f' `fmap` sa) s'

instance Monad (State a) where
  -- (>>=) :: State s a -> (a -> State s b) -> State s b
  (S f) >>= t = S $ \s ->
    let (a, s') = f s in runState (t a) s'
```

이제 `do` notation을 이용해 코드를 2차로 리팩토링해보자.

```haskell
next :: State Int Int
next = S $ \n -> (n, n + 1)

main :: IO ()
main = fst $ runState (
  do
    id <- next
    id' <- next
    id'' <- next
    S $ \s ->
      ( do
          print id
          print id'
          print id'',
        s
      )
  )
  0
```

`bind` 호출이 없으니 조금 더 간결해졌다. 마지막으로, `State` monad를 사용하는 코드를 분리하여 리팩토링을 해보자.

```haskell
-- Main.hs
next :: State Int Int
next = S $ \n -> (n, n + 1)

nextThree :: State Int (Int, Int, Int)
nextThree = do
  id <- next
  id' <- next
  id'' <- next
  return (id, id', id'')

getThreeIds :: Int -> (Int, Int, Int)
getThreeIds start = fst $ runState nextThree start

main :: IO ()
main = do
  let (id, id', id'') = getThreeIds 0
  print id
  print id'
  print id''
```

특히 처음에 비하면 코드가 훨씬 간결해진 것을 확인할 수 있다.

## Tree Labeling

해당 monad를 또 다른 예시에 적용해보자. 이는 위에 언급된 동영상에 있는 예시이기도 하다.

```haskell
data Tree a = Leaf a | Node (Tree a) (Tree a) deriving Show
```

다음과 같은 트리 자료구조가 있을 때, 각각 leaf마다 숫자 id를 붙여 `label`하는 함수를 작성해보자. 먼저 monad 없이 매뉴얼하게 작성해보자.

```haskell
label :: Tree a -> Int -> (Tree Int, Int)
label (Leaf v) n = (Leaf n, n + 1)
label (Node l r) n = (Node l' r', n'')
  where
    (l', n') = label l n
    (r', n'') = label r n'
```

이 함수는 state를 관리한다. 그 다음에 사용할 id인 `n`이다. 함수를 pure하게 유지하기 위해서는 바늘구멍에 실 궤매듯이 이 state를 계속 들고 다녀야 한다.그럼 위에서 만든 `State` 를 이용하여 같은 코드를 작성해보자.

```haskell
mlabel :: Tree a -> State Int (Tree Int)
mlabel (Leaf v) = do
  n <- next
  return (Leaf n)

mlabel (Node l r) = do
  l' <- mlabel l
  r' <- mlabel r
  return (Node l' r')
```

실 꿰매듯 state를 운반하는 코드는 더이상 보이지 않는다. 이 함수는 이렇게 사용할 수 있을 것이다.

```haskell
-- Tree.hs
testTree :: Tree String
testTree = Node (Leaf "foo") (Node (Leaf "bar") (Leaf "baz"))

main :: IO ()
main = do
  let labeled = fst $ runState (mlabel testTree) 0
  print labeled
```

(`runState` 랑 0이 불편하면 다른 함수로 만들어두면 된다...여기선 생략한다)

이로써 순수 함수형 언어인 haskell에서 monad를 통해 state를 깔끔하게 처리하는 방법을 알아보았다! 글을 쓰며 나 역시 많이 배운 것 같다. 이 게시글에서 사용한 코드는 [이 레포](https://github.com/pacokwon/simple-state-monad-demo)에 업로드되어있다!


Simple State Monad in Haskell with Examples


In this post I'll be briefly going through how I built my blog with Next.js and some difficulties that I've faced. This will only be a personal reflection, not a tutorial.

So one day, I decided to build a personal blog. Nothing fancy but a rather simple blog to put my personal info with posting capability. Yes, you can use a given template, but I personally have this avoidance for templates. I wish to have complete control of what I use and build, and thus I decided to use a SSG/SSR framework called Next.js.

And so, here are the main tools/packages that I've used to build my blog:

- Next.js
- Remark / Rehype
- Material UI React
- GitHub Pages & Workflow
  I'll go through each of these to address my thoughts on them.

## Next.js

Next.js is a SSG/SSR framework for React. I haven't done SSG nor SSR ever before. It looked like Next.js and Gatsby both offer SSG functionality, so I had to choose. After a bit of research, I knew that Next.js would suit me better. To me Gatsby looked like a full fledged ecosystem with plugins and all, while Next.js was more like plug-and-play. It seemed like I would not have as much control over the project if I used Gatsby, so I chose Next.js. Of course, I haven't used Gatsby so there's the benefit of the doubt.

## Remark / Rehype

Remark / Rehype are libraries that transform markdown and html. I used these packages to convert them into React components, so that I could upload my posts.

The overall process of conversion is: `Markdown File - Remark - Rehype - React Component`. The markdown file is parsed with remark, translated to html using rehype, and then to a React component. The ecosystem allows you to plug processors in between. For example, I've used the `rehype-highlight` package that highlights code with `highlight.js` under the hood.

What I really liked about this package is that it allows users to use their own components for each html tag from markdown. For now, rounding corners in code blocks remain my only usage for this feature (...) but I'm sure I could do much more.

## Material UI React

Material UI component library provides many useful components that follow the Material UI design. _I like pretty things, but I don't like CSS._ This library is for me. The familiarity helps as well. Most (if not all) google products use this guideline. The documentation is top notch as well. It also allows easy custom styling.

## GitHub Pages & Workflow

I've used GitHub pages as my blog hosting service. It serves static assets for free. I heard good things about it, but have never used it before. I had some difficulty initially setting it up, only to find out that I haven't changed the branch for github pages.

Since generating static files requires a building process using Next.js, I have also set up GitHub Actions to automatically build as I push.

I hope to keep my blog minimal, but the minimum functionality will grow larger as the need arises. Eventually the stack will grow as well, and maybe I'll do version 2 of this post when it happens.


Building a Personal Blog in Next.js


블하 (블로그 하이라는 뜻)

아무 생각 없이 대학교를 다니다가 보니 시간이 참 빨리 지나갔다. 고등학교 동기들 중에서는 군대가는 친구들을 여럿 보았는데, 입대를 3학년 이후로 생각하고 있던 이유는 많았다.

1. 우리 학교는 다들 군대를 좀 늦게 가는 분위기였어서..
2. 입대하기 전에 학교에서 최대한 많이 배워보고 싶은 욕구도 좀 있었다. 물론 그래봐야 전공 수업들이긴 했지만 실제로 학점을 굉장히 몰아 들었다. 졸업 이런거 때문이 아니고 맛보고 싶은게 많았다.
3. 이왕 가는거 개발 쪽으로 갈 수 있으면 좋을 거라 생각했다. 근데 그러려면 2학년은 마쳐야 가능성이 조금이라도 생긴다.

3번 이유가 가장 컸다. 병특을 고려하지 않은 이유는 내가 대학원을 가게 되면 그 전에 시간을 너무 많이 써야 해서..그리고 난 대학원 옵션을 버리고 싶지는 않았다. 전문연을 고려하지 않은 이유는 외국 대학원 옵션을 버리고 싶지 않아서. 또 그렇다고 대학원을 가야겠다는 확신이 들지 않는 상황이었다. 이것저것 고민하다보니 머리가 상당히 복잡해져서, 좋은 보직에 선발되면 그냥 가자는 결론을 내렸다.

## 육군 SW 개발병 지원

2학년 때 입대 고민을 할 당시에는 이걸 지원해서 갈 생각이었다. 선발은 1차 서류 + 2차 면접으로 이루어졌었다. 1차 서류는 학년 점수 + 자격증 + 고교 출석률 3개로 이루어져 있었다. 난 모범생이었으니 고교 출석률은 문제 없었고, 학년은 내가 당장 바꿀 수 없었기에 학년 점수도 고정이었다. 마지막 남은 자격증의 경우 10점이 최고 점수였는데, 10점을 주는 자격증들(기사급)이 여러개 있었고, 그 다음이 8점(산업기사급), 마지막이 6점이었다. 난 자격증은 없는 상황이었어서 주변 사람들이 많이 따는 정보처리 자격증을 취득하기로 했는데, 10점을 주는 정보처리기사 자격증은 졸업(4학년이었나?)을 해야 딸 수 있고, 8점을 주는 정보처리산업기사 자격증은 3학년이 돼야 딸 수 있었다. 6점 주는 기능사 자격증은 초등학생도 딸 수 있던 것 같던데 이걸로는 부족할 것 같았다. 그래서 3학년 된 직후에 정보처리산업기사 자격증 딴다고 필기시험은 회사 다니면서 공부하고, 실기시험은 수요일에 중간고사 끝나고 며칠 공부하고, 참 바쁜 시간 쪼개가며 공부했는데 어쩌다 취득은 했다.

아무튼 내가 당시에 낼 수 있는 최대 점수를 냈는데 1차에서 탈락해버렸다. 모집 인원은 3명, 1차 통과는 3배수였고, 내 점수는 커트보다 3점 낮아서 떨어졌다. 내 점수는 선발 순위가 27위였다. 그만큼 1점씩이 중요했던 것 같다. 근데 한창 학기 중이라 바쁜 시기였던 것도 있었고, 나는 나름 최선을 다했어서 별로 후회되거나 아쉬운 점은 없었다. 누굴 탓할 순 없었다.

## 해군 SW 개발병 지원

육군을 떨어지고 바로 해군을 넣었다. 해군도 1차 서류 - 2차 면접 방식으로 선발을 하는데 1차는 모두 통과시키고 면접을 보는 방식이었다. 배점은 자격(30) + 경력(30) + 전공(40) + 면접(100)이었는데 솔직히 모르고 그냥 면접보러 갔었다. 면접은 대면으로 모든 대상자들이 계룡대에서 보았다. 나는 학교에 있었는데 가까이 있어서 택시타고 갔다. 근데 **면접을 보는 건물이 지도에 안 나오니 잘 찾아가야 한다...**, 택시에서 생각없이 내리고 길도 모르고 걸어가다 늦을 뻔했는데 어떤 은인이 나타나서 면접장까지 태워주셨다. 진짜 감사합니다...이걸 보시게 되면 연락해주세요. 보상이라도 해드리고 싶습니다.

선발은 1명 선발이라 적혀 있었고, 병무청 웹사이트에서 조회했을 때는 나의 1차 점수는 3위, 최종 점수가 1위였다. 총 13~15명 정도 지원했던 것으로 기억한다. 다만 지원할 때 1명보다 많이 뽑을 수도 있다고 적혀 있어 실제로 얼마나 뽑았는지는 모르겠다.

### 면접 후기

나에게 물어보신 질문들을 직접 적을 생각은 없다. 대신 어떤 느낌으로 나왔는지 설명하겠다.

#### 자료를 성심성의껏 준비하자

나는 이 자료로부터 나오는 질문이 많았다. 고정질문이랑 비슷한 수의 질문을 하신 것 같다. 그만큼 주의깊게 이 자료를 보시니 준비를 잘하자!

매수 또한 넉넉하게 출력해가는 것이 좋다. 나는 평소에 정말 생각이 없는 편이라 한 장만 뽑았었는데 운이 좋게도 여러 개 뽑을 생각을 했었다. 면접 보러 들어가니 면접관이 한 분보다 많이 계셔서 다행이 한 부씩 드릴 수 있었다.

우선 1차를 통과하고(2021년도 기준 100%) 포트폴리오나 자기소개서 등의 자료를 자유롭게고 지참하라는 연락을 받았다. 근데 나는 둘 다 없는 상황이었다. 사실 반년 전에 회사 인턴 지원하면서 작성한 게 있었는데 정말 편한 느낌으로 써놓은 거라 그대로 내기에는 부담스러웠다. 그래서 처음부터 다시 작성했다. 어떤 내용을 넣을지는 고민을 많이 한 부분이다. 나는 `짧은 소개 + 경력 + 프로젝트 경험 + 보유기술 + 어학능력 + 교육 + 기타 활동`으로 구성했다. 그냥 내 마음대로 만든 구성이니 따라할거면 위험은 알아서 감수하도록.

포트폴리오라는 말을 몰라 취업한 형에게 물어보니 보통 PPT 형태라고 하던데, 어떻게 가져오라는 건지 약간 의문이어서 그냥 문서 형식으로 작성해갔었다. 가보고 나니 그렇게 준비해가길 잘했다. 가서 보니 디지털로 발표를 할 환경은 아니었다. 물론 둘 다 준비를 하면 최고겠다. 나는 시간에 쫓겨 준비했었기 때문에..

#### 기본적인 조사는 하자

군면접의 성격을 띤 질문들도 많이 하신다. 대한민국 군대와 역사에 대해 최소한으로는 알아가면 좋을 것 같다. 나는 해군에 지원했기에 해군과 관련된 지식을 좀 쌓고 가는 것도 좋을 것이다.
이외에도 부대 내에서의 상황을 주시고 이런 상황에서 어떻게 행동할 것인지에 관한 질문들 또한 하신다. 여러 가지 상황을 준비해가는 것도 방법일 것 같다. 나는 약간 생소한 상황을 질문하셔서 내 평소 가치관이랑 부족한 순발력에 의지해서 대답을 드려야 했다.

내가 시간이 지나면 위 내용들을 잊을 것 같아 글을 작성하기도 했지만 해군 개발병에 지원할 때 후기가 전혀 없어 준비하기가 조금 어려워서 누군가 이 글을 보고 조금 더 수월하게 준비했으면 하는 마음도 있다. 지금 제 블로그가 바닥부터 만든거라 댓글 기능이 없는데, 추가 문의사항이 생기면 메일로 문의를 주시거나 보실 적에 댓글 기능이 있으면 댓글 달아주세요:)


해군 SW 개발병 지원 후기


## Hello World!

블로그를 시작하게 되었다.

블로그 운영은 거의 올해 초부터 해보고 싶었는데, 본업 때문에 시간이 부족하다는 변명을 스스로에게 하며 시작하지 않고 있었다... 나는 "From Scratch"를 굉장히 좋아하는 편이라 블로그도 템플릿에 의존하지 않고 직접 만들어야 한다는 생각 때문에 시작하는데 조금 장벽이 되었을 수도 있었을 것 같다는 생각이 든다.

21년 여름에는 본교 PLRG에서 개별연구를 했는데, 랩 미팅 때 교수님께서 "평소에 글을 쓰는 습관을 들이는 것이 좋다"라는 말씀을 하신 것을 듣고 조금 더 동기부여가 되었던 것 같다. 얼마 뒤인지부터는 모르겠는데 아무튼 블로그 개발을 시작했고, 소개, bio, 그리고 게시글 조회 기능을 만든 뒤에 이 글을 작성하고 있다.

동기부여가 되었던 또 다른 일은 입대가 얼마 안 남았다는 점이다. 이 이야기는 별도의 글에 더 자세하게 담겠지만, 불과 이틀 전에 해군 SW 개발병에 합격했는데, 한 명 뽑는 보직이다 보니 될 기대를 크게 안하고 있었어서 입영 날짜를 모르고 있었다. 알고 보니 10월 5일 입영이었고 백신 문제 때문에 정확히 그때 갈지는 모르겠지만 시간이 한 달...정도밖에 남지 않았기 때문에, 시간이 있을 때라도 좀 정리를 하고 가야겠다는 생각을 했다. 물론 아직 남은 시간동안 어떠한 일을 할지 제대로 생각을 못해봤는데, 최대한 블로그 정리를 하고 갈 수 있었으면 한다.

블로그 게시글들은 남이 볼 것이라고 기대하지는 않고 오히려 개인 일기 느낌에 가깝도록 편하게 적을 것 같은데, 또 나만 알아들을 수 있도록 적지는 않을 생각이다. 주 내용은 내가 평소에 관심있던 편집기 이야기 및 개발을 배우면서 사소하게 배웠던 것들을 적을 것 같다! 또 예전부터 개인 노션이나 `vimwiki` 등 여기저기 적어는 놓았는데 정리가 안된 자료들도 과거 작성 날짜에 맞춰 업로드할 생각이다.


블로그 개업!


Why is it that different patterns of imports are shown across typescript examples?

```typescript
import * as React from 'react';
import React from 'react';
```

Let us look at how the two examples are compiled to javascript code using `tsc`.

First, intialize a project with the following commands:

```bash
mkdir esminterop-example && cd esminterop-example   # create project directory
yarn init -y                                        # initialize npm project
yarn add react                                      # add react package (opt.)
yarn add -D typescript @types/node @types/react     # add typescript compiler and type definitions (req.)
touch star.ts plain.ts
```

Fill in the files `star.ts` and `plain.ts` with the following code:

`star.ts`

```typescript
import * as React from 'react';
console.log(React);
```

`plain.ts`

```typescript
import React from 'react';
console.log(React);
```

First, let's compile `star.ts` with `tsc` and see the output.

```bash
npx tsc star.ts
```

`star.js`

```javascript
'use strict';
exports.__esModule = true;
var React = require('react');
console.log(React);
```

All good. Now try to compile `plain.ts`, and an error will occur.

```bash
npx tsc plain.ts

plain.ts:1:8 - error TS1259: Module '"/Users/pacokwon/workspace/esminterop-example/node_modules/@types/react/index"' can only be default-imported using the 'esModuleInterop' flag

1 import React from 'react';
         ~~~~~

  node_modules/@types/react/index.d.ts:65:1
    65 export = React;
       ~~~~~~~~~~~~~~~
    This module is declared with using 'export =', and can only be used with a default import when using the 'esModuleInterop' flag.


Found 1 error.
```

The problem occurs because while `react` does not have a default export, our typescript file is attempting to default import it. One way of solving this issue might be to use the wildcard(asterisk) import above. Another way is to use the `--esModuleInterop` flag. Now let's see how the latter way works, by using that flag in our compiler.

```bash
npx tsc --esModuleInterop plain.ts
```

There are no errors, which is a good thing. The compiled file looks like this:

```javascript
'use strict';
var __importDefault =
  (this && this.__importDefault) ||
  function (mod) {
    return mod && mod.__esModule ? mod : { default: mod };
  };
exports.__esModule = true;
var react_1 = __importDefault(require('react'));
console.log(react_1['default']);
```

One can find out that a wrapper to the require is added. The wrapper provides additional logic, that allows flexible resolution between es6 modules and commonjs modules. It can also be observed that a "default" export or import is, from a commonjs module point of view, the value that corresponds to the key `"default"` in the `module.exports` object.

AFAIK, javascript packages are usually shipped with the original source code transpiled into using commonjs modules, so the `esModuleInterop` flag is a flag that I commonly use in my `tsconfig.json`.


Understanding the esModuleInterop option in tsconfig.json


Just until stumbling upon some random video on youtube about spellchecking in Vim, I didn't know such capability even existed in Vim. Turns out that you can, and it can be utilized in markdown files, commit messages and etc. This post is a demonstration of how you can enable and utilize spellchecking in Vim.

## Enabling Spellchecking in Vim

```vim
:set spell spellang=en_us " use english dictionary for spellchecking
```

To only set it for local buffers, use:

```vim
:setlocal spell spelllang=en_us
```

I utilize this primarily in autocmds, like this:

```vim
autocmd BufRead,BufNewFile *.md setlocal spell spelllang=en_us " enable spellchecking in markdown files
autocmd FileType gitcommit setlocal spell spelllang=en_us " enable spellchecking in git commit files
```

Once you have these set up, words that are recognized by the spellchecker will be highlighted according to the highlight groups `SpellBad`, `SpellCap`, `SpellRare`, `SpellLocal`. For further reference, consulting the `:help spell-quickstart` docs will come in handy. In my neovim setup, the words are shown underlined (Not exactly sure where it comes from).

## Utilizing it

One can get recommendations from the spellchecker from the completion engine. Run `set complete+=kspell`, as in:

```vim
autocmd FileType gitcommit setlocal spell spelllang=en_us | set complete+=kspell
```

One can navigate between recommendations in insert mode using `^N` and `^P`, and spellchecking recommendations will show up among the options.

Here are some commands I found useful:

- `]s` and `[s`: navigate between misspelled words. Former moves forward, the latter backwards.
- `z=`: see alternatives to the word under the cursor. For example, if I write `file` and run `z=` on it, it will recommend a list of words from the dictionary.
- `zg`: register a word as correct in the dictionary. The Vim dictionary does not know a lot of words, so it will mark a lot of words as incorrect. One way to solve that issue is to register a word to the dictionary. This command does that.
- `zw`: just like `zg`, but marks a word as incorrect.

For more, as always, consult the helpdocs. For spellchecking, `:help spell` is where you should go to.
