매크로로는 줄바꿈이 폼을 끝내게 만들 수 없어요. 자꾸 그렇게 하고 싶어지지만요.
표기는 아주 작아요. 한 줄에 쓴 paint red blue를 (paint red blue)로 읽고, 줄바꿈에서 폼을 닫고, #부터는 주석으로 처리해요. 셋 다 무엇이 토큰이고 폼이 어디서 끝나는지에 대한 결정이고, 확장기가 뭔가를 보기 전에 리더가 이미 내려 둔 결정이에요. 기존 언어 안의 평범한 매크로는 이미 만들어진 폼을 다뤄요. 거꾸로 돌아가서 자기를 둘러싼 어휘 규칙을 바꿀 수는 없어요.
그러니 이 규칙들은 커스텀 리더가 맡아야 해요. 가능은 하지만 관리할 도구와 문서가 따라오고, 여기서는 왜 #이 Racket에서 보통 뜻하는 것과 다르냐고 묻는 처음 읽는 사람도 따라와요. 단어 세 개짜리라면 그냥 괄호를 쓰는 편이 낫겠다는 쪽으로 반쯤 기울어 있어요.
괄호를 쓰든 안 쓰든, 내장 규칙 편집기에서는 읽는 문제와 평가하는 문제가 갈라져요. 줄바꿈과 # 규칙은 리더가 맡을 일이에요. 그다음 호스트가 색을 고르려고 Lispex 규칙을 평가할 때는 팔레트와 제안된 타일을 명시적으로 넘기고, 돌아온 결정 데이터에 따라 동작해요.
맞춤 표기법이 실행 상한을 주지는 않아요. Lispex 1.21의 기본 소스 평가에서는 신뢰하는 로컬 규칙이 프로세스 안에서 실행돼요. 실행에 상한이 필요하다면 설계에 native embed인지 embed full인지, 그리고 어떤 프로필인지 적어야 해요. 리더를 고르면 규칙을 어떻게 읽는지가 정해질 뿐이에요. 어느 평가기의 보장이 적용되는지는 다른 질문이에요.
Prolog가 반례다. 대충은. :- op(700, xfx, ===>)는 파일을 읽어 들이는 도중에 실행되고, 그 뒤에 읽히는 절은 모두 a ===> b를 항으로 파싱한다. 지시문 하나가 파일 중간에서 리더를 바꾸는 셈이다. 커스텀 리더 없이.
그래도 줄바꿈 규칙은 못 만든다. 연산자는 토큰이 어떻게 결합하는지를 바꿀 뿐, 무엇이 토큰인지나 절이 어디서 끝나는지는 못 바꾼다. 절은 여전히 마침표에서 끝난다. 결론은 같고 각도만 다르다. 연산자 표는 싸다. 어휘 규칙은 비싸다.
