TeX (프로그래밍 언어)의 의미가 공식화 되었습니까?

T가 사용하는 매크로 언어 인 것 같습니다. 는 일종의 용어 재 작성 시스템 또는 이름 별 호출 범위를 가진 프로그래밍 언어의 일종으로 볼 수 있습니다.$\TeX$

T의 현대적인 구현조차도 엔진 (예 : X e$\TeX$ )는 코드를 매우 직접적인 방식으로 해석하며 (최적의 최적화 통역사가 할 수있는 것처럼) 실행 최적화를 시도하지 않습니다. 그러나 T 와 같은 언어에 대한 올바른 최적화 패스를 고안$\mathit{Xe}\TeX$ 는 매크로 재정의가 가질 수있는 "먼 거리에서의 행동"과 매크로를 이름으로 호출하여 재정의하는 능력 때문에 매우 어려울 것입니다.$\TeX$

T에 대한 가상 최적화 해석기를 구현실제로 T 는 X 에서 매우 어려운 문제이지만 매우 유용한 문제입니다.$\TeX$ 는 수학과 과학 전반에 걸쳐 사용되며 느린 컴파일 시간은 시스템의 알려진 단점입니다. 특히 계산량이 많은 패키지 (예 :)가 사용될 때 실제 조판을 계산하지 않고 코드를 해석하는 데 대부분의 시간이 소요됩니다.$\TeX$tikz

어쩌면 언어에 대한 공식 의미론이 문제를 해결하기 시작했을 수 있습니다. T 의 의미도 마찬가지입니다 프로그래밍 언어가 공식화 되었습니까?$\TeX$

(사이트의 범위와 다른 방향으로가는 긴 대답에 대한 사과와 함께 : 솔직히 나는 처음에 여기서 질문을 보는 것에 놀랐다.…)

TeX는 프로그래밍이 아닌 조판 용으로 설계되었습니다. 따라서 프로그래밍 언어로 간주 될 때 기껏해야“이상한”것입니다.

— Donald Knuth, 235 페이지 디지털 타이포그래피

나는 지난 몇 년 동안 TeX의 초기 역사 (1977 년경)와 Knuth의 많은 글을 읽었습니다. 제 결론은 “TeX (프로그래밍 언어)” 에 관해 이야기하는 순간 , 이미 잘못된 것입니다.

이전에 작성된 TeX의 초기“디자인 문서”를 보면 (참조 TEXDR.AFT 및 TEX.ONE발표, 디지털 타이포그래피 ), 그것은 크 누스는 주로 조판위한 시스템 설계 한 것이 분명하다 컴퓨터 프로그래밍의 예술을 (그가 말했다 (예 : 여기 ) 그가 염두에 두었던 주요 사용자는 자신과 그의 비서였으며, 적절하게 수정되면 더 일반적으로 유용 할 수 있다는 생각과 함께. 타이핑을 저장하기 위해 반복적으로 수행해야하는 작업 (예 : TAOCP가 저자의 인용문을 포함해야 할 때마다 일정량만큼 세로로 이동하고 특정 줄 건너 뛰기를 설정하고 특정 글꼴을 선택하고 오른쪽 정렬 인용, 다른 글꼴 선택, 저자 이름 입력 ...) 매크로가있었습니다.

나머지는 짐작할 수 있습니다. 우리가 TeX에 가지고있는 것은 "우연히 Turing-complete" ( 더 많은 것 )의 경우입니다. 단, 커뮤니티 (컴퓨터 과학자와 수학자, 그리고 DEK 자신도 불행히도)의 한가운데서 일어난 것입니다. 이것을 무시하기에는 너무 영리합니다. (Legend는 Michael Spivak 이 TeX를 만나기 전에 프로그래밍 한 적이 없다고 생각했지만, 너무 복잡해서 현재 존재하는 가장 복잡한 매크로 중 하나 인 AMS-TeX를 작성했습니다.) TeX가 작성 되었기 때문에 많은 시간에 걸쳐 시스템을 이식 할 수 있었기 때문에 (당시 큰 문제 였음) TeX에서 모든 일을하려는 유혹이 항상있었습니다. 게다가, 그의 컴파일러 작성 경험 때문에, Knuth는 TeX를 컴파일러와 같이 작성하고 때때로 그것을 하나라고 설명했으며, 입력에서 작동하는 프로그램이 "컴파일러"라면 반드시 프로그래밍하고 있습니까?

이 답변 에서 Knuth가 TeX에서 프로그래밍을 수행하지 않으려는 방법과 "차고 비명을 지른 후에 만 ​​TeX의 프로그래밍 기능을 많이 사용하는 방법"에 대해 조금 더 읽을 수 있습니다 . 내가 말했듯이, 그의 의도가 무엇이든 사람들은 TeX 매크로 시스템을 사용하여 놀라운 프로그래밍 기술을 달성하는 방법을 찾기 시작했습니다. Knuth는이 흥미로운 사실을 발견했으며 TeX 자체에 일부 기능을 추가하는 것 외에도 부록 D "더러운 트릭" TeXbook, 하지만, 이름에도 불구하고, 밝혀 것을 아홉 열 예를 벗어 그 안에" LaTeX의 구현에 사용됩니다”.

내가 그것을 다른 방법을 넣어 보자 : 유액, 레슬리 램 포트가로, 텍 위에 쓴 매크로 시스템 아이디어 , 좋은 하나입니다. (램 포트가 전화 또는, (크 누스) 텍의 페이지 지향적 인 방법보다는, 의미 론적, 구조, 인간 중심의 방법으로 문서를 저작 논리보다는 시각은 ) 좋은 일이다. 그러나 “적절한”프로그래밍 언어가 아닌 TeX 매크로를 사용하여 LaTeX와 같이 복잡한 것을 구현하는 것은 적어도 내가보기에 그리고 적어도 오늘날까지 이루어 졌다면, 큰 실수와 원치 않는 행동 사이에있다. Knuth조차도 사람들이 TeX 매크로에서 모든 것을하는 대신 TeX 프로그램을 확장하지 않는다는 사실에 충격 을 받았습니다 .

오늘날에는 "프로그래밍"을 수행하는 훨씬 더 좋은 방법이 있습니다. 대부분의 사람들의 컴퓨터에서 널리 사용 가능한 많은 언어로 외부 프로그램을 사용하거나 LuaTeX 및 Lua에서 프로그램을 사용할 수 있습니다 ( 더 나은 일을 당신이 내부 구조를 조작 할 수 있기 때문에, 혹시 혼자 텍 매크로 수보다 및 올바른 수준의 알고리즘). 그리고 올바르게 수행하면 TeX 매크로로 구현 된 프로그램보다 더 우수하거나 빠른 프로그램을 운영 할 수 있습니다.

빠른 텍에서 프로그램을 만드는 작업은 거의 이러한 관점에서 볼, 다른 프로그래밍 "언어" "실수로 전체를 튜링"설명하는 종이의 마지막 단어 나에게 연상시키는 재미있는 경우 : 톰 Wildenhain의 사랑 " MS의에 튜링 완전성을 파워 포인트 ( 작년의 비디오 ) :

PPTXTM는 파워 포인트 개발의 이론적 가능성을 증명하지만 […]. 작업은 PowerPoint 응용 프로그램 최적화에서도 수행해야합니다. PowerPoint의 다음 슬라이드 자동 버퍼링을 활용하는 데에는 많은 가능성이 있습니다.이 슬라이드는 신중한 슬라이드 배치를 통해 응용 프로그램 성능을 크게 향상시키는 데 사용될 수 있습니다.

Lipton이 설명 하는 일화 는 예시입니다. TeX의 형식적 의미론이 존재하지 않았을뿐만 아니라, TeX의 형식적 의미론도 존재하지 않을 것입니다. 그것은 너무 "이상한" "언어"이며, (위에서 설명했듯이) 언어로도 의도되지 않았습니다. 예를 들어, 매크로를 함수로 작성하고 있다고 생각할 수 있지만, 단일 스트레이 문자 ( 공백 포함 )를 도입하면 TeX는이를 즉시 조판 명령으로 취급합니다.

요약하자면, TeX는 가장 빠른시기에 조판으로 되돌아 가고, 매크로를 확장 할 때 거칠게 ( '실제'조판 작업에 이르지 못하는 환자), 이러한 확장은 그 자체로 수백 가지 종류의 "상태"에 의존 할 수 있습니다 TeX 프로그램 ( \hsize또는 or 와 같은 매개 변수 값 \baselineskip, 상자 및 기타 레지스터의 내용…)은 TeX의 형식적 의미론이 반드시 프로그램의 전체 상태와 모든 메모리를 고려할 때 반드시 있어야하는 이유입니다. “Tex 코드의 의미는 TeX가하는 모든 것”과 같은 것으로 TeX 프로그램 자체보다 복잡한 형태로 끝납니다.

TeX는 프로그래밍 언어가 아니며 실제 언어처럼 작동하지 않으며 공식적인 의미 체계가 없으며 오늘날 프로그래밍하는 더 좋은 방법이 있습니다. 그러나이 모든 것이 도움이되지는 않습니다. 실제 질문 / 문제, 실제로 TeX에서 처리하기위한 많은 문서가 있습니다. 어떻게 (라텍스 TikZ 등) 사용 복잡한 매크로를, 서로의 상단에 내장 괴물 복잡성의 멋진 건축물. 어떻게하면 더 빠르게 만들고 "최적화 패스"를 고안 할 수 있습니까?

공식적인 의미 론적 IMO로는 거기에 갈 수 없습니다. 나는 이것에 대해 최근에 생각했으며 다음은 예비 생각입니다.

Knuth는 1960 년대에 숙련 된 컴파일러 제작자 중 한 명이며 (그래서 그는 The Computer of Computer Programming 으로 바뀌는 컴파일러 책을 작성하도록 요청 받았으며 ) TeX는 컴파일러가 1970 년대에 쓰여졌다. 그 이후로 컴파일러 기술과 디자인이 개선되어 TeX 프로그램도 개선 될 수 있습니다. 속도를 높여서 수행 할 수있는 작업은 다음과 같습니다.

• 핵심적으로 TeX는“통역 루틴”처럼 작성되었으며, TeX“눈”과“입”(입력 루틴)은“위”(의미 적 루틴)에 명령을 하나씩 실행하여 명령을 전달합니다. ( TeX 프로그램의 15 부 에서 목록을 볼 수 있습니다 .) 예를 들어, TeX의 눈 / 입이 마주 치 \hfill거나 \hskip입력 될 때 위는“hskip”명령을 받아 작동합니다. 이것은 오늘날 바이트 코드 인터프리터라고하는 것과 유사하며, TeX 프로그램을 리팩토링하여 이러한 바이트 코드 / 오피 코드를 명시 적으로 방출 할 수 있으므로 기존의 (보다 전통적인) 컴파일러 기술을 사용할 수 있습니다. 또는 작업을 다시 실행하지 않도록 적어도 캐시하십시오. 물론 많은 도전이 있습니다 :

  • "위"에서 명령을 실행하는 데는 여전히 입력을 읽는 것이 필요합니다. 즉, 입력 루틴과 의미 루틴의 작업은 별도의 단계에서 발생하지 않습니다. 예를 들어, "hskip"명령이 주어진 경우 \hskip(라고 말하지 않고 \hfill) scan_glue입력에서 글루 사양을 읽도록 호출 할 것이며 , 이로 인해 글루에 대한 충분한 토큰이 발견 될 때까지 매크로를 확장하는 등의 작업을 수행 할 수 있습니다. 실질적으로 다른 상태.

  • eTeX 및 pdfTeX 및 XeTeX 및 LuaTeX와 같은 엔진은 새로운 명령과 프리미티브를 도입합니다 (eTeX / pdfTex 프리미티브는 실제로 모든 사람이 실제로 사용함). 원래 Knuth의 TeX 프로그램에있는 것만이 아니라 이들도 지원해야합니다.

• 우리는“추론 적 실행”과 같은 일을 할 수 있으며, 미래의 문단 (새 섹션이나 챕터와 같은 자연 체크 포인트에서 시작될 수 있음)을 병렬로 (여러 코어 사용) 처리하고, 사용하는 모든 TeX 내부 상태를 추적하고, 던질 수 있습니다. 나중에 우리가 이전 단락이 그 상태의 일부를 바꾸는 것을 알게되면 그 작업을 멀리하고 (다시 실행). 현재 TeX는 하나의 프로세서에서 완전히 순차적으로 실행됩니다. 일반적인 하드웨어는 다른 방향으로 이동했으며 여러 코어를 사용할 수 있습니다.

• 더 간단하게, 우리는 입력 파일의 특정 섹션에 의해 간단히 작업 (TeX 상태에 액세스하고 수정 한 작업)을 캐시 할 수 있습니다. (이 캐싱은 입력 수준, 즉 모든 매크로를 확장 한 결과 또는 조립 된 상자 세트 수준 또는 프로그램의 전체 상태까지 수행 할 수 있습니다.) 예를 들어 내부 내용 에이\begin{tikzpicture} … \end{tikzpicture} 는 페이지 번호 카운터와 같은 TeX 상태에 크게 의존하지 않을 가능성이 높으므로 TeX 문서를 다시 컴파일 할 때 모든 작업을 재사용 할 수 있습니다. 충분한 정보를 추적 한 경우 안전하게 수행 할 수 있습니다. (물론 TikZ는 특히 이것을 외부화하고 결과를 포함하는 방법을 가지고 있지만 아이디어는 더 일반적입니다.)

• 우리는 기술 (예 : 기능 프로그래밍에 사용되는 기술)을 사용하여“구멍”으로 일부 TeX 처리를 수행 할 수 있습니다. 예를 들어, 작성할 때\ref{foo} LaTeX에서 미래의 섹션 번호를 언급 할 때 두 가지 컴파일 단계에서만 작동합니다. 섹션 번호는 제 2 패스에이어서, 보조 파일에 기록되고 먼저 전체 문서 (모든 문단 조판은 등의 페이지 상에 배치 수레) 처리되는 모든이번에는 섹션 번호가 실제로 사용 가능한 상태로 작업이 다시 수행됩니다. (이런 종류의 핵은 필연적으로 불가피했을 수도 있으며, 실행 시간에 미치는 영향은 "일관적인 요소"라는 것을 알고 있습니다 만….) 대신 "구멍"으로 문서를 처리 할 수 ​​있다면 어떨까요? 섹션 번호에 결정되지 않은 내용이 있지만 예상 너비가있는 상자)가 남아있는 경우 문서 처리가 끝나면 상자를 채 웁니다. (예, 예상 너비가 잘못되어 단락이 다시 처리되어 결과적으로 페이지가 필요할 수도 있지만 필요한 경우 작업을 수행하거나 속도를 위해 잘못된 너비를 허용하는 모드를 수락 할 수 있습니다 섹션 번호)

• TeX 문서를 대화식으로 편집 할 때도 비슷한 기술을 사용할 수 있습니다. 단락을 편집 할 때 "실시간"으로 처리 할 수 ​​있으며, 다음 단락은 단순히 교정쇄로 내려갑니다. BaKoMaTeX 및 Texpad 및 이전 Textures 와 같이이를 수행하는 (상업용) TeX 구현이 이미 존재하기 때문에 가능하다는 것을 알고 있습니다 . ( BaKoMa-TeX 의 홈 페이지 와 이와 유사한 TeXpad의 비디오 ( 예 : 이 비디오)를 참조 하십시오. 후자를 시도했지만 실제로는 버그가 많았 습니다.)

• 과소 평가해서는 안됩니다 : 사용자에게 물건을 보여주는 가치, TeX를 더 디버깅 가능하게 만듭니다. 현재 사용자는 TeX 입력 만 볼 수 있으며 단락의 줄 바꿈 또는 매크로 확장 (및 어떤 매크로)에 어떤 시간을 소비하는지, TeX가 무엇을하고 있는지 정확히 알지 못합니다. 버리기, 어떤 패키지로 어떤 스페셜이 작성되는지 등 백그라운드에서 그래디언트가있는 방정식은 저렴하거나 (처리 시간에 거의 추가하지 않음). 많은 낭비적인 작업이 수행되는 위치를 확인하면 일부 작업을 버릴 수 있습니다 (최소한 최종 인쇄가 실행될 때까지). (이는 프로파일 링 정보를 프로그램에 삽입하는 컴파일러 나 다른 툴과 다소 비슷합니다.) TeX를보다 투명하고 디버깅 가능하게 만드는 것은 유용성을 크게 향상시킬 수 있습니다. (TeX는 매크로가 거의없는 평범한 TeX를 사용하지만 LaTeX에는 사용하지 않거나 오늘날 많은 사용자가이 문제를 경험하는 경우 IMO에 대해 이미 사용하기 쉽고 디버깅이 가능합니다.)

또한 향후의 모든 작업은 현재 우리가 보유하고있는 TeX를 가장 잘 수정 한 LuaTeX (빌드 온)를 고려해야합니다.

이것들은 모두 유휴 생각입니다 (필요한 노력이나 얼마나 많은 속도를 얻었는지 알기 위해 구현하지 않았습니다). 그러나 이것이 귀하의 질문에 대답하거나 미래의 방향에 대한 아이디어를 제공하는 데 도움이되기를 바랍니다. .

아니, 내 지식으로는 당신이 관심있는 종류의 TeX를 공식화하는 작업이 없었습니다.

(다음은 주관적이고 개인적인 논평입니다.) 나는 그것이 흥미롭고 잘 짜여진 아이디어라고 생각하며, 최적화를 수행하기 위해 그것을 사용하려는 동기는 합리적이라고 들립니다. 또 다른 관련 질문은 해석 속도를 높이기 위해 바이트 코드 형식을 정의 할 수 있는지 여부입니다. 반면에이 아이디어에는 두 가지 단점이 있습니다.

첫째, 언어 의미론이 구문 분석과 밀접하게 관련되어 있기 때문에 최적화 가능성이 크다는 것은 분명하지 않습니다 (예 : 계산 속도를 높이기 위해 어떤 종류의 프로그램 보존 변환을 수행 할 수 있습니까?). 캐릭터 흐름, 따라서 최적화 친화적 인 중간 표현의 디자인에 그다지 수용되지 않습니다.

둘째, TeX 해석 속도의 개선 필요성은 잘 정립되어 있지 않습니다. 배치 속도 구축 속도는 하드웨어 개선 덕분에 합리적으로 유지되었습니다. 속도 향상을 환영 할 수있는 사례는 복잡한 그래픽 패키지 (비머 프레젠테이션은 빌드하는 데 시간이 오래 걸릴 수 있음), 풍부한 계산을 포함하는 패키지 (그러나 다른 언어가 더 적합 할 수 있음), 즉각적인 사용자 피드백을 위해 빠른 재 구축이 필요한 사용 사례입니다 (그러나 최적화보다는 증분이 핵심 일 수 있습니다. 공식적인 의미론은 증분 구현에 대한 추론에도 도움이 될 것입니다).

즉, 이것은 재미 있고 유익한 주제처럼 들리지만 작업을 수행하는 데 대한 실질적인 타당성이 강력하다는 것은 분명하지 않습니다. 누군가 호기심에서 벗어나는 데 관심이 있다면, 그것은 훌륭한 모험처럼 들리지만, 그렇지 않으면 최종 사용자가 더 많은 영향을 줄 수있는 동일한 기술을 사용하는 다른 방법이있을 수 있습니다.