Digital Garden by Rycont | 뉴스레터 구독하기

2024년 41주차 (10월 2주차)

집에서 주간정리 쓴다. 10월 12일부터 15일까지 휴가이다.

yaksok.ts 업데이트

다음과 같은 부분이 변경되었다:

약속 정의 문법이 새로워졌습니다

기존에는 다음과 같이 약속을 정의했다.

약속 "키가" 키 "cm이고 몸무게가" 몸무게 "kg일 때 비만도"
	# ...

키가 170 cm이고 몸무게가 50 kg일 때 비만도

기존 문법은 가독성도 좋지 않았고, 무엇보다 다의적으로 해석이 가능한 경우가 있었어서 문제가 되었다. 예를 들어 다음과 같은 상황에서 모호성이 드러난다.

약속 "키" 키 "몸무게" 몸무게"의 비만도"
    # ...

키: 170
몸무게: 68
비만도: 키 키 몸무게 몸무게 의 비만도

함수를 호출할 때 인자와 함수 이름이 전혀 분리가 되지 않아서, 이를 올바르게 해석하기가 어려울 뿐 더러 여러 방법으로 해석하는 방법이 모두 맞는 경우도 있었다.
그래서 다음과 같이 개선하였다:

약속, 키 (키) 몸무게 (몸무게)의 비만도
    # ...

키: 170
몸무게: 68
비만도: 키 (키) 몸무게 (몸무게)의 비만도
  1. 새 함수를 정의할 때 사용하는 "약속" 키워드의 뒤에 반점이 들어간다
  2. 함수에서 고정되는 부분에 따옴표를 감싸지 않는다
  3. 함수의 인수는 소괄호로 감싼다
  4. 함수를 호출할 때도 인자를 소괄호로 감싼다

function variants와 함께 활용하면 다음과 같다

약속 음식 "을/를" 사람 "와/과 먹기"
	# ...

"치킨"을 "형"과 먹기
약속, (음식)을/를 (사람)와/과 먹기
	# ...

("치킨")을 ("형")과 먹기

Identifier 노드

기존에는 다음과 같은 코드가 이렇게 토크나이징 되었었다

token-before-refactor.png

굉장히 틀린 설계였다. 다른 언어에서 사용하는 통상적인 Keyword의 정의와도 상당히 다르며, 이 둘을 구분하면서 파서가 크게 복잡해지고 있었다.
어떠한 토큰이 변수인지 키워드인지 구분하기 위해 다음과 같은 규칙을 사용했다

  1. 코드 전체에서 변수 정의 패턴을 찾아 코드 내에서 사용되는 모든 변수의 이름을 알아낸다
  2. 변수 이름과 동일한 내용을 가지는 키워드는 변수로 해석한다
  3. 그렇지 않으면 키워드로 해석한다
    가장 큰 문제는 다음과 같은 코드였다.
약속, 키가 (키)cm이고 몸무게가 (몸무게)kg일 때 비만도
	... # 비만도를 계산하는 코드

비만도: 키가 (140)cm이고 몸무게가 (30)kg일 때 비만도

위 코드에서는 비만도라는 변수를 선언했기에, 내용이 "비만도"인 모든 토큰은 변수로 해석되었다. 함수 선언과 사용에 있는 "비만도"라는 텍스트는 변수가 아님이 명확하지만, 변수로 해석되었기에 코드가 올바르게 파싱되지 못했다.
키워드와 변수의 구분을 없애고 Identifier라는 하나의 노드로 파싱하면서, 잘못 파싱하는 경우를 줄이면서도 파서를 더 간결하게 만들 수 있었다. 더 적은 코드로 우아하고 유연하게 동작하는 파서를 만들었다.
이 작업을 하면서 렉서를 완전히 새롭게 재작성 했다.

웹 데모에서 코드를 직접 공유할 수 있다

https://yaksok-ts.pages.dev/#JUVDJTk1JUJEJUVDJTg2JThEJTJDJTIwJUVEJTgyJUE0JUVBJUIwJTgwJTIwKCVFRCU4MiVBNCljbSVFQyU5RCVCNCVFQSVCMyVBMCUyMCVFQiVBQSVCOCVFQiVBQyVCNCVFQSVCMiU4QyVFQSVCMCU4MCUyMCglRUIlQUElQjglRUIlQUMlQjQlRUElQjIlOEMpJUVDJTlEJUJDJTIwJUVCJTk1JThDJTIwJUVCJUI5JTg0JUVCJUE3JThDJUVCJThGJTg0JTBBJTIwJTIwJTIwJTIwJUVBJUIyJUIwJUVBJUIzJUJDJTNBJTIwJUVCJUFBJUI4JUVCJUFDJUI0JUVBJUIyJThDJTIwJTJGJTIwKCVFRCU4MiVBNCUyMCUyRiUyMDEwMCUyMColMjAlRUQlODIlQTQlMjAlMkYlMjAxMDApJTBBJTBBJUVCJUI5JTg0JUVCJUE3JThDJUVCJThGJTg0JTNBJTIwJUVEJTgyJUE0JUVBJUIwJTgwJTIwKDE3MCljbSVFQyU5RCVCNCVFQSVCMyVBMCUyMCVFQiVBQSVCOCVFQiVBQyVCNCVFQSVCMiU4QyVFQSVCMCU4MCUyMCg3MCklRUMlOUQlQkMlMjAlRUIlOTUlOEMlMjAlRUIlQjklODQlRUIlQTclOEMlRUIlOEYlODQlMEElRUIlQjklODQlRUIlQTclOEMlRUIlOEYlODQlMjAlRUIlQjMlQjQlRUMlOTclQUMlRUMlQTMlQkMlRUElQjglQjA=

이제 URL을 사용해서 코드를 공유할 수 있다. 안되는 코드가 있다면 공유하기 버튼을 눌러서 제게 바로 보내주세요.

그 외 추가 기능


평양냉면..을 인생에서 두 번째 먹어봤다. 남대문 바로 앞에 있던 서령을 다녀왔다. 아직은 무슨 맛인지 모르겠다. 사골을 차갑게 식혀서 물타먹는 맛이다. 을밀대보다 별로인 것 같기도 한데, 둘 다 맛있진 않았다. 다섯번쯤 먹어야 익숙해질 것 같다.


무언가 애타게 기다리는 경험은 참 소중한 것이다. 나에게도 최근에 그러한 일이 있었다. 별건 아니지만, 성심당의 "보문산 메아리"가 내 기다림의 대상이었다.

기다림의 발단은 다음 트윗이었다:

X에서 케이온임 님 : "대전 재난상황발생함 https://t.co/Caj0nkVY0Q" / X

대전역 구내 선로에 빵 상자가 와르르 쏟아져 있는 사진이다. 단순히 지나칠 수도 있었지만, 묘한 미감에 빠져 인용을 살펴보았다. 다들 통탄을 금치 못하고 있었다. 저 빵이 무엇이길래 많은 이들을 절망케 했을까 알아보니, 그 이름이 "보문산 메아리"인 것 같았다. 무심코 보문산 메아리를 구글에 검색해서는 안 되었어야 했다.

그 뒤로 나는 자기 전마다 보문산 메아리를 먹는 상상을 했고, 누구와 함께 나눠 먹을지 고민했으며, 보문산 메아리를 맛있게 먹는 방법을 알아보았다. 한 번도 먹어본 적 없는 빵을 알아보는 시간 그 자체가 행복했다. 그렇게 몇 주 뒤로 예정되어 있는 휴가 때 꼭 대전에 들러 보문산 메아리를 사리라 다짐하였다.

휴가를 나와 대전역에 들렀고, 부푼 기대를 숨길 노력조차 하지 않은 채 성심당 대전역점으로 직행했다. 한 바퀴를 둘러보았는데 보문산 메아리를 찾을 수 없었다. 보문산 메아리는 없었다. 사실 이번 휴가는 오직 보문산 메아리만을 위해 나왔다고 해도 과언이 아니었다. 그래서 무척 실망스러웠고, 아쉬운 마음이 컸다.

이렇게 된 이상 다른 빵이나 더 사자는 생각에 한 바퀴를 더 도는데, 내 눈앞에서 카트에 한가득 담긴 보문산 메아리가! 방금 나온 보문산 메아리가! 이토록 기다리고 그 순간만큼은 내 존재 이유였던 보문산 메아리가! 막 진열되고 있었다! 다른 빵들은 볼 겨를도 없이 바로 진열대로 달려가서 보문산 메아리를 두 개 집었다. 어쩌면 나는 행운아가 아닐까?

결국 보문산 메아리는 맛있게 먹었다. 기대한 만큼 맛있더라. 그런데 돌이켜 생각해보니, 보문산 메아리를 고대하며 설레는 마음을 더는 느낄 수 없다는 게 아쉬웠다. 기다림이란 것은, 대상을 얻음으로써만 완성되는 미완의 감정이 아니다. 기다림은 기다림 그 자체로 아름다웠다. 각박한 삶에서 흔치 않게 경험한 몽글몽글한 순간이었다.


그 외에는 한 일이 없다.


연결된 페이지 (Inlinks)

연결된 페이지가 없습니다.


댓글 쓰기, GitHub에서 보기