(З вибаченнями за довгу відповідь, яка йде в напрямку, відмінному від сфери використання сайту: відверто кажучи, я здивувався, побачивши тут питання в першу чергу…).
TeX був розроблений для набору тексту, а не для програмування; тому це в кращому випадку "дивно", якщо розглядати його як мову програмування.
- Дональд Кнут, Цифрова типографія, сторінка 235
За останні пару років я багато читав про ранню історію (близько 1977 року) про TeX, і багато того, що написав Кнут. Мій висновок полягає в тому, що в той момент, коли ми говоримо про "TeX" (як мову програмування) " , щось вже не так.
Якщо ми подивимось на ранні «документи проектування» для TeX, написані раніше (див. TEXDR.AFTТа TEX.ONEопубліковані в « Цифровій типографії» ), то зрозуміло, що Кнут розробляв систему, в першу чергу, для набору «Мистецтва комп’ютерного програмування» (він сказав (наприклад, тут ) що головними користувачами, які він мав на увазі, були він та його секретар), з думкою, що, відповідно модифікована, це може бути корисним загалом. Щоб зберегти введення тексту, для речей, які неодноразово доводилося робити (наприклад, кожного разу, коли TAOCP потрібно було включити цитату від автора, ви хочете пересуватися вертикально на певну суму, встановити певний рядок, підібрати певний шрифт, набрати цитуйте вирівнювання праворуч, підберіть інший шрифт, введіть ім'я автора…), були макроси.
Ви можете вгадати решту. Текс у нас є випадком «випадково повного Тьюрінга» ( більше ), за винятком того, що це сталося посеред спільноти (комп'ютерних вчених та математиків, а сам DEK теж «винен»), які (на жаль) занадто розумний, щоб ігнорувати це. (Легенда стверджує, що Майкл Співак ніколи не програмував, перш ніж зіткнутися з TeX, але його настільки взяли з собою, що він закінчив писати AMS-TeX, в той час, як один із найскладніших наборів макросів, що існують.) Тому, що TeX був написаний щоб бути переносним для великої кількості систем (що було великою справою на той час), завжди була спокуса зробити все в TeX. Крім того, через досвід написання укладачів, Кнут написав TeX як компілятор і час від часу описував його як один, і якщо програма, яка працює на вашому вході, є "компілятором", то, звичайно, ви програмуєте, правда?
Ви можете прочитати трохи більше про те, як Кнут не мав наміру проводити будь-яке програмування в TeX, і як він "вводив багато функцій програмування TeX лише після ударів і крику" в цій відповіді . Як би я не говорив, як я вже говорив, люди почали розбирати способи (аб) використовувати макросистему TeX для досягнення дивовижних подвигів програмування. Кнут вважав це захоплюючим і (крім додавання деяких функцій до самого TeX) включив декілька з них у Додаток D "Брудні хитрощі" The TeXbook, але, незважаючи на назву, виявляється, що "дев'ять із десяти прикладів у них є використовується при впровадженні LaTeX ».
Дозвольте сказати іншим чином: LaTeX - макросистема, про яку Леслі Лампорт написав поверх TeX, як ідея - чудова. Оформлення документів семантичним, структурованим, орієнтованим на людину способом, а не (Knuth) TeX-орієнтованим на сторінку способом (або, як Лампорт називав його, логічним, а не візуальним ) - це чудово. Але реалізація чогось такого складного, як LaTeX, використовуючи макроси TeX, а не «належною» мовою програмування, на мій погляд, і принаймні, якби це було зроблено сьогодні, десь між гігантською помилкою та актом безладдя. Навіть Кнут вражений тим, що люди не просто розширюють програму TeX, а не роблять все в TeX макросах.
Сьогодні є набагато кращі способи зробити «програмування»; ви можете використовувати зовнішню програму на будь-якій з багатьох мов, широко доступних на комп'ютерах більшості людей, або ви можете використовувати LuaTeX і програму в Lua (і зробити кращу роботу, ніж ви могли коли-небудь лише з TeX макросами, оскільки ви можете маніпулювати внутрішніми структурами та алгоритми на потрібному рівні). І якщо ви зробите це правильно, у вас можуть бути програми, які працюють краще або швидше, ніж ті, що реалізовані в TeX макросах.
Завдання зробити програми в TeX швидше майже кумедно, якщо побачити в цьому світлі, і нагадує мені заключні слова статті, що описують ще одну "випадково затіювану" програмувальну "мову": милу Тома Уайлденхайна " Про цілісність повноти М.С. PowerPoint ( відео ) минулого року:
Хоча PPTXTM доводить теоретичну можливість розвитку PowerPoint, […]. Також необхідно провести роботу з оптимізації додатків PowerPoint. Тут є великий потенціал для використання автоматичного буферизації наступного слайда PowerPoint, який завдяки ретельному розміщенню слайдів може бути використаний для значного підвищення продуктивності програми.
Анекдот , який описує Lipton є ілюстративним. Мало того, що ніколи не існувало формальної семантики TeX, вона також навряд чи буде такою. Це занадто "дивно" для цього "мова", і (як я сподіваюся, я пояснив вище), вона навіть не розглядається як мова. Наприклад, ви можете подумати, що ви пишете макроси як функції, але вводите в нього єдиний бродячий символ (навіть пробіл ), і TeX негайно розглядає його як інструкцію з набору тексту.
Коротше кажучи: TeX повертається до набору тексту при першій же можливості, і коли він розширює макроси, він робить це грубо (нетерпляче дістатися до своєї "реальної" роботи набору тексту), і ці розширення можуть самі залежати від сотень видів "стану" в межах програма TeX (значення таких параметрів, як \hsizeабо \baselineskip, вміст полів та інших регістрів ...), тому будь-яка формальна семантика TeX обов'язково повинна бути чимось, що враховує весь стан програми та всю її пам'ять, поки ми не в кінцевому підсумку, на кшталт "значення коду TeX - це те, що робить TeX", у формі, більш складній, ніж сама програма TeX.
Так добре, (якщо я вас переконав) TeX не розглядався як мова програмування і не працює як реальна, формальної семантики немає, і сьогодні є кращі способи програмування - але все це не допомагає вашому актуальне питання / проблема, яка полягає в тому, що на практиці багато документів, призначених для обробки TeX , використовують складні макроси (як LaTeX і TikZ), приголомшливі споруди жахливої складності, побудовані один на одного. Як ми можемо зробити це швидше і розробити "оптимізаційні проходи"?
Ви не потрапите туди з формальною семантикою ІМО. Я недавно про це думав, і далі - кілька попередніх думок.
Моє враження, що Кнут був одним із досвідчених авторів-компіляторів у 60-х роках (тому його попросили написати книгу компіляторів, що перетворилася на «Мистецтво комп’ютерного програмування» ), а TeX (багато в чому) написано так, як компілятори були написано у 1970-х, скажімо. Техніки та дизайн компілятора покращилися відтоді, як і програма TeX. Ось деякі дії, які можна зробити, прискоривши роботу:
По суті, TeX написаний як «інтерпретаційний розпорядок», де «очі» та «рот» (його вхідні процедури) TeX надають інструкції своєму «шлунку» (його семантичній процедурі), які виконуються одна за одною. (Ви можете побачити список у частині 15 програми TeX .) Наприклад, коли очі / рот TeX стикаються \hfillабо \hskipвводяться, шлунок отримує команду «hskip», на яку він діє. Це схоже на те, що сьогодні називають інтерпретаторами байт-кодів, і може бути корисно в рефакторингу програми TeX, щоб явно випромінювати ці байт-коди / опкоди, щоб ми могли мати можливість використовувати існуючі (більш звичайні сьогодні) методи компілятора. Або принаймні кешуйте їх, щоб уникнути повторної роботи. Звичайно, існує багато проблем:
Виконання команди в "шлунку", як правило, все ще включає зчитування вводу, тобто робота вхідних процедур і смислових підпрограм не відбувається в окремі фази. Наприклад, команда "hskip", якщо дано \hskip(а не скаже \hfill), буде викликати scan_glueдля зчитування специфікації клею з входу, що, в свою чергу, може включати розширення макросів і так далі, поки не буде знайдено достатньо лексем для клею, залишивши вхідний стек у істотно інший стан.
Такі двигуни, як eTeX і pdfTeX, XeTeX і LuaTeX, вводять нові команди та примітиви (примітиви eTeX / pdfTex практично використовуються всіма на практиці); Вам також потрібно буде їх підтримувати, а не тільки в оригінальній програмі TeX Knuth.
Ми могли б зробити щось на кшталт "спекулятивного виконання", обробляючи майбутні абзаци (можливо, починаючи з природних контрольних пунктів, як нові розділи чи глави) паралельно (використовуючи декілька ядер), відслідковуючи весь внутрішній стан TeX, який вони використовують (залежно від), і кидати осторонь цієї роботи (і перероблення її), якщо пізніше ми з'ясуємо, що попередній абзац закінчує зміну деякого стану. На даний момент TeX працює повністю послідовно на 1 процесорі; типове обладнання перейшло в інший бік, і кілька ядер доступні.
Навіть простіше, ми могли просто кешувати роботу (який стан TeX був доступний і змінений) певним розділом вхідного файлу. (Ми могли б зробити це кешування на рівні вводу - чистий результат розширення всіх макросів - або на рівні того, який набір ящиків зібраний, або аж до загального стану програми.) Наприклад вміст всередині a \begin{tikzpicture} … \end{tikzpicture}навряд чи багато що залежатиме від стану TeX, наприклад лічильника номерів сторінки, тому, коли ми перекомпілюємо документ TeX, ми можемо просто повторно використати всю роботу - якщо ми відслідковували достатню кількість інформації, щоб знати, що це безпечно. (Звичайно, у TikZ, зокрема, є способи покращити це та включити результати, але ідея більш загальна.)
Ми можемо використовувати методи (наприклад, ті, які використовуються у функціональному програмуванні), щоб виконати деяку обробку TeX з "дірками" - наприклад, зараз, коли ви пишете \ref{foo}в LaTeX для позначення (скажімо, майбутнього) номера розділу, він працює лише у двох проходах компіляції: спочатку весь документ обробляється (усі набори абзаців, плаває розміщені на сторінках тощо), при цьому номери розділів виписуються в допоміжний файл, потім на другий проходять усіробота виконується знову, при цьому номер розділу фактично доступний на цей раз. (Такий злом, можливо, був неминучим у той час, і я знаю, що вплив на час роботи - це "лише постійний фактор", але ...) Натомість, що робити, якщо ми могли просто обробити документ "діркою" ( поле номер із невизначеним вмістом, але деякою орієнтовною шириною) залишено для номера розділу, то наприкінці обробки документів заповнюйте поле? (Так, наша передбачувана ширина може виявитися неправильною, а абзац може потребувати повторної обробки та, отже, навіть сторінки, але ми можемо або виконати роботу при необхідності, або прийняти для швидкості режим, у якому ми дозволимо отримати неправильну ширину для номер розділу.)
Подібні методи можуть працювати для інтерактивного редагування документа TeX: коли ви редагуєте абзац, він може бути оброблений "в прямому ефірі", а майбутні абзаци просто переміщаться вниз по галереї (скажіть). Ми знаємо , що це можливо, тому що вже існує (комерційна) реалізація TeX , які роблять це, наприклад , BaKoMaTeX і Texpad і колишні Текстури . (Дивіться відео на домашній сторінці BaKoMa-TeX та аналогічно TeXpad, наприклад, це відео - я спробував останнє, але воно було нестерпно баггі на практиці.)
Не варто недооцінювати: цінність показу речей користувачеві, що робить TeX більш налагоджуваним. Зараз користувачі бачать лише свій вхід TeX і не мають уявлення, якою саме роботою займається TeX, наприклад, скільки часу він витрачає на розбиття рядків для абзаців або на макророзширення (і на які макроси), які поля він збирає та викидаючи, які спеціальні послуги виписуються, яким пакетом і т. д. Я (можливо, оптимістично) вважаю, що існують користувачі, які хотіли б бачити цю інформацію і вважають її корисною, наприклад, щоб знати, чи дивний пакет вони використовують для затінення рівняння з градієнтом у фоновому режимі дешеві (додаючи мало часу на обробку) чи ні. Побачивши, де робиться багато марної роботи, вони могли б викинути її частину (принаймні, до остаточного друку). (Це дещо схоже на компілятори чи інші інструменти, що вставляють інформацію про профілювання в програми.) Зробити TeX більш прозорим і налагоджуваним, можливо, є величезним покращенням зручності використання. (TeX вже досить зручний для користувачів і налагоджує свій час IMO, якщо ми використовуємо в основному звичайний TeX з дуже малою кількістю макросів, але не з LaTeX або як сьогодні більшість користувачів стикаються з ним.)
Крім того, будь-яка майбутня робота, мабуть, повинна враховувати (надбудовувати) LuaTeX, яка є найкращою модифікацією TeX у нас.
Все це лише простою думки (я не реалізував жодної з них, щоб знати необхідні зусилля чи скільки прискорення ми отримали б), але я сподіваюся, що це певним чином допоможе відповісти на ваше запитання або дати вам ідеї щодо майбутніх вказівок. .