RElf ([info]relf) wrote,
@ 2008-02-15 01:42:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
благодарности
В последней статье в секции благодарностей высказал оные авторам следующего свободно-распространяемого программного обеспечения, активно использовавшегося при написании статьи:
TeXlive distribution of the LaTeX typesetting system;
Xfig drawing program;
Graphviz graph visualization software;
и GNU Compiler Collection.

Мне пустячок, а им приятно (надеюсь). Но вообще, это как-то непринято, что ли. По крайней мере мне не попадались в статьях благодарности авторам TeX'а (хоть какого) в статьях, хотя большинство статей по математике/CS делается именно в нем.

(Post a new comment)


[info]ticklish_frog
2008-02-15 02:21 pm UTC (link)
Это напоминает классическое "автор благодарит алфавит за любезно предоставленные буквы" :)

Во многих книгах подробно описывается, какое оборудование и программы были использованы при подготовке, а в статьях, видимо, место все же мало для этого. Кроме того, пользователь ТеХ'а не обязан упоминать это, а вот получатель гранта *обязан* указывать благодетеля.

(Reply to this)(Thread)

[info]relf
2008-02-15 06:54 pm UTC (link)
Да, Кирилла с Мефодием надо бы упомянуть... ;)

С обязанностями отчитаться по грантам все понятно.
Непонятки с добровольными благодарностями. Ведь благодарят же люди других людей, если они подсказали что-то полезно. А с софтом получается, что пользуешься нахаляву, извлекаешь для себя какую-никакую выгоду, а упомянуть благодаря кому и чему, статья была написана быстро и оформлена качественно, - забываешь.

С коммерческим софтом, кстати, таких (моральных) проблем нет. Купив софт, ты уже "отблагодарил" его создателей, и дальше уже их упоминание может быть только требованием лиценции, но никак не твоей моральной обязанностью.

(Reply to this)(Parent)
Имхо
[info]bik_top
2008-02-15 05:18 pm UTC (link)
>По крайней мере мне не попадались в статьях благодарности авторам TeX'а.

Все так привыкли превозносить несомненно могучий ум Кнута, и охреневать от кнутовской охренительности, что вовсе не подвергают автора TeX'а критике. А напрасно, язык TeX'а с современной точки зрения более чем ужасен.

Например, в TeX'е очень плохо развита модульность. Плохо выражены уровни абстракции. Нет единого Стандарта. Высокое качество документов, получаемых с помощью TeX'а, не отменяет архитектурных изъянов, заложенных в язык.

Но поблагодарить Кнута таки стоит, да. Дональд, спасибо тебе большое! Лэсли Лампорт, тебе тоже огромное!

(Reply to this)(Thread)
Re: Имхо
[info]relf
2008-02-15 06:47 pm UTC (link)
Ну критика TeX - это отдельная тема. Если интересно, то вот тут поднималась, например:
http://lib.mexmat.ru/forum/viewtopic.php?t=11709

Но благодарности авторам, используемого продукта, внезависимости от нравится он или нет (в конце концов: не нравится - не пользуйся), сказать стоит.

(Reply to this)(Parent)(Thread)
Re: Имхо
[info]bik_top
2008-02-15 07:51 pm UTC (link)
Ну критика TeX - это отдельная тема. Если интересно...

Ага, интересно, спасибо за ссылку!

Правда, с основным доводом (WYSIWYG круче, чем Plain text) я не согласен, не в этом дело. Просто Кнут создавал свой язык в то время, когда о разработке языков было не так уж много известно, теория формальных грамматик была не развита, практика создания трансляторов — тоже. И всякие best practices создания языков программирования тогда были ещё не очевидны.

Мне кажется, было бы здорово, если бы кто-нибудь занялся разработкой нового языка системы набора и вёрстки. Полноценного языка (не какой-то WYSIWYG-поделки), учитывающего недостатки TeX'а и достижения современного языкоизобретательства. (<UPD /> На эту тему, кстати, упоминается некий TeXmacs. TODO: Посмотреть поближе.)

(Math typesetting in TeX: The good, the bad, the ugly — эту статью упоминали в обсуждении, на которое вы дали ссылку. Ещё не успел прочесть, просто вставил сюда линк до кучи, чтобы не искать.)

(Reply to this)(Parent)(Thread)
Re: Имхо
[info]relf
2008-02-15 08:27 pm UTC (link)
Еще есть некий LyX: http://www.lyx.org/
как я понимаю, конкурент TeXmacs ;)

(Reply to this)(Parent)
Re: Имхо
[info]dmitri_pavlov
2008-02-16 02:32 am UTC (link)
>Просто Кнут создавал свой язык в то время, когда о разработке языков было не так уж много известно, теория формальных грамматик была не развита, практика создания трансляторов — тоже. И всякие best practices создания языков программирования тогда были ещё не очевидны.

Вы очень серьезно заблуждаетесь. В этом утверждении
неверно буквально каждое слово. Притом неверно в существенном смысле.

Я понимаю, что легко рубить с плечая, но следует помнить,
что Кнут является одним из крупнейших специалистов во всех
без исключения указанных вами областях.
Могу лишь напомнить, что он придумал атрибуртные грамматики,
алгоритм трансляции LR(1)-языков, изобрёл (модульную!)
парадигму программирования — грамотное программирование,
написал кучу компиляторов, и так далее, и тому подобное.

В общем, будет очень трудно написать более неверное утверждение,
чем ваше. Надо быть крайне наивным, чтобы думать, что
Кнут не размышлял над темой структурности и не структурности
своего будущего языка. Между прочим, он описывал,
почему он сделал ТеХ таким, каким он есть, и не другим,
в частности, слабо структурированным.

Вы уж простите за такое сравнение, но тут явно
Моська тявкает на слона.

>Мне кажется, было бы здорово, если бы кто-нибудь занялся разработкой нового языка системы набора и вёрстки. Полноценного языка (не какой-то WYSIWYG-поделки), учитывающего недостатки TeX'а и достижения современного языкоизобретательства.

Боюсь, некому делать такой язык. Или у вас есть кандидатуры?
Да и непонятно, что в нём должно быть по-другому.
Со времени выпуска ТеХа (1982 год!) в нём нашли очень мало недостатков.
Есть небольшие заморочки со шрифтами, но они нас не волнуют,
поскольку созданием шрифтов занимается крайне мало людей.

>Нет единого Стандарта.
Ась? А TeXbook на что?

(Reply to this)(Parent)(Thread)
Re: Имхо
[info]bik_top
2008-02-16 06:57 pm UTC (link)
Со времени выпуска ТеХа (1982 год!) в нём нашли очень мало недостатков.

Позиционируется, что в нём нашли очень мало ошибок реализации, Кнут здорово ядро закодировал, спору нет. Но недостатки проектирования собственно языка там таки есть.

Да и непонятно, что в нём должно быть по-другому.

1) Иногда встречается повторяющаяся последовательность комманд, общая (с точностью до некоторых параметров) для разных частей документа — логично завернуть её во что-нибудь процедурообразное, \(re)newcommand, например. Однако в издательстве мне запрещают пользоваться самопальными командами, из-за боязни конфликтов с уже определёнными коммандами в их стилевых пакетах. Действительно, стоит мне ввести (или не приведи бог переопределить) существующую командку, как вскрывается куча несовместимостей подключаемых packag'ей. Это вызвано отсутствием модульности. Это можно было бы разрулить, например, введнеием пространств имён, или ещё как-то.

2) Некоторые особенности TeX'а имеют лексический, а не синтаксический характер, что роднит эти особенности с препроцессором, как в Си. Со всеми вытекающими недостатками.

3) Программистами иногда используется GoF-паттерном Template Method. Он нужен, когда требуется изменить только один шаг алгоритма, не переписывая всю функцию целиком. В C++ используется переопределение защищённых (чисто) виртуальных методов класса так, чтобы изменила своё поведение другая открытая функция-член. В Си использовался просто метод предоставления хуков пользователю функции. Так вот, Кнут, имхо, злоупотребил этой в принципе хорошей идеей. Это выражается в следующем: чтобы изменить поведение команды1, часто надо переопределить не её, а совсем другую команду2 (это не всегда интуитивно понятно), которая используется при реализации команды1. И тут возникает проблема в другом: внезапно меняет своё поведение и команда3, тоже использующая команду2. Другая сторона этой проблемы — не вседа понятно, на каком уровне надо эту команду менять, какое звено в цепочке вызовов переопределить, чтобы добиться нужного эффекта. В некоторой степени, это вызвано следующим недостатком.

4) Отсутствие стандарта, как истины в последней инстанции. В C++ таковым является Стандарт ANSI ISO/IEC 14882. А «Всё про TeX» Кнута для TeXника представляет собой то же, что и «TC++PL» Страуструпа для плюсиста, не более.

5) Про модульность уже было сказано, но ещё раз. TeXовские packag'и явно недотягивают до звания модулей. Часто бывает, что додкумент разительно меняется при изменении порядка подключаемых пакетов — а это Очень Плохая Штука, с полноценной модульностью в её современном понимании несовместима.

6) Сложный и местами мерзкий синтаксис я оставлю на последнем месте. Я-то, в принципе, смогу простить многие сомнительные конструкции языку, но вот новичкам они даются неоправданно туго.

Я понимаю, что легко рубить с плеча

Поверьте, нелегко. Учитывая моё глубочайшее уважение к Дональду Эрвиновичу. И его многократное превосходство в широте эрудиции и глубине квалификации любого (не исключено!) человека на планете.

но следует помнить, что Кнут является одним из крупнейших специалистов во всех без исключения указанных вами областях.

Я в курсе. Я читал его «ИП», «Конкретную математику», «Всё про TeX», «Всё про METAFONT» (у него ещё была переведена на русский книга по компьютерной типографии, но я её, увы, не читал). Насчёт он ли придумал алгоритм трансляции LR(1), я не помню, но то что ему принадлежит ряд важных результатов в этой области — бесспорно, это и в Dragon Book написано.

(Reply to this)(Parent)(Thread)
Re: Имхо
[info]dmitri_pavlov
2008-02-16 10:08 pm UTC (link)
>Однако в издательстве мне запрещают пользоваться самопальными командами, из-за боязни конфликтов с уже определёнными коммандами в их стилевых пакетах.

Такие проблемы очень легко устраняются. К тому же, документ готовите вы,
а не издательство, и вы видите, конфликтуют ваши
команды со стилевым пакетом издательства или нет.
И технический редактор тоже это видит.
И если имена команд случайно совпали, то
исправляется это за пять секунд. Какие проблемы?

>2) Некоторые особенности TeX'а имеют лексический, а не синтаксический характер, что роднит эти особенности с препроцессором, как в Си. Со всеми вытекающими недостатками.

Это было сделано намеренно. Я уже вам это говорил в предыдущем комментарии.

>И тут возникает проблема в другом: внезапно меняет своё поведение и команда3, тоже использующая команду2. Другая сторона этой проблемы — не вседа понятно, на каком уровне надо эту команду менять, какое звено в цепочке вызовов переопределить, чтобы добиться нужного эффекта. В некоторой степени, это вызвано следующим недостатком.

Надуманная проблема. Я много лет занимаюсь
разнообразным TeXackingом, и никаких проблем
подобного рода не испытывал. Возможно, для LaTeXа
с его чудовищным размером это более актуально.
Опять же, надо аккуратнее писать макропакеты.
Это проблема не языка, а авторов LaTeXа или тех пакетов,
которыми вы пользуетесь.

>4) Отсутствие стандарта, как истины в последней инстанции. В C++ таковым является Стандарт ANSI ISO/IEC 14882. А «Всё про TeX» Кнута для TeXника представляет собой то же, что и «TC++PL» Страуструпа для плюсиста, не более.

Вы заблуждаетесь. Читайте TeXbook внимательнее,
это TC++PL + стандарт. В основном тексте
есть четыре справочных главы. Есть справочные приложения.
Всё это сделано для того, чтобы в книге было
полное и однозначное описание языка.

>5) Про модульность уже было сказано, но ещё раз. TeXовские packag'и явно недотягивают до звания модулей. Часто бывает, что додкумент разительно меняется при изменении порядка подключаемых пакетов — а это Очень Плохая Штука, с полноценной модульностью в её современном понимании несовместима.

Это проблема пакетов, а не языка. Надо писать нормальные
пакеты.

>6) Сложный и местами мерзкий синтаксис я оставлю на последнем месте. Я-то, в принципе, смогу простить многие сомнительные конструкции языку, но вот новичкам они даются неоправданно туго.

Какие-нибудь примеры можете привести?

(Reply to this)(Parent)(Thread)
Re: Имхо
[info]bik_top
2008-02-17 12:15 am UTC (link)
К тому же, документ готовите вы, а не издательство, и вы видите, конфликтуют ваши команды со стилевым пакетом издательства или нет.

* Издательство может не предоставить свой пакет.
* Автор может не знать, в какое издательство попадёт его статья.
* Автор планирует отдать статью в несколько издательств, и не захочет переименовывать команды под каждое из них.
* Даже если автор видит, что в данный момент не конфликуют, то никто не даст гарантии, что издательство не изменит свой пакет в дальнейшем.
* Автор может не увидеть сразу, конфликутют ли его команды со стилевым пакетом издательства. Это может проявится когда угодно, стать источником всяких шрёдинбагов и гейзенбагов.

И технический редактор тоже это видит.

Технический редактор этого не видит, и не хочет видеть. Всё, что является error prone издательству проще запретить.

И если имена команд случайно совпали, то исправляется это за пять секунд.

Каким образом? Только не спешите с ответом, подумайте хорошо.
За пять секунд? Как вы можете быть в этом уверены?

Какие проблемы?

Извините, но проблемы принципиальные. Собственно, я не должен был отвечать на ваш вопрос, а закатывать глаза в вашем стиле: «Вы несёте какую-то совершеннейшую чушь.» Потому что вопросы модульности разжёвывались почти всеми авторами учебников по программированию, начиная с Дейкстры.

Возможно, для LaTeXа с его чудовищным размером это более актуально.

Ок, тогда перекладываю свои претензии с Кнута на Лэмпорта :) Но общая проблема остаётся: нет хорошо сбалансированных чётких механизмов переопределения некоторых шагов в командах.

Это проблема пакетов, а не языка. Надо писать нормальные пакеты.

Вы ошибаетесь, это всё-таки проблема языка — минимизировать ошибкоопасные конструкции. Разработчики языка не имеют морального права винить пользователей в своих недоработках, дескать, «Если не хотите получать по лбу, то не наступайте на забытые нами грабли! Мало ли что вам хочется, убирать их нам недосуг!» Собственно, создатели современных языков не позволяют себе таких заявлений, а просто делают, как будет удобнее пользователю. Сравните, например, модульность в C++ и C#. Просто в случае TeXа нет конкурентов и стимула как-то язык развивать.

Вот ещё одна из пафосных нелепиц TeX'а... Как вы относитесь к желанию Кнута нумеровать версии своего TeXа, прибавляя по одной цифре к десятичной записи числа π?

(Reply to this)(Parent)(Thread)
Re: Имхо
[info]dmitri_pavlov
2008-02-17 12:26 am UTC (link)
>* Издательство может не предоставить свой пакет.
К такому издательству я бы на километр не подошёл.
Кстати, можете привести примеры?
Springer и AMS свои пакеты распространяют свободно.

На все остальные возражения
могу только сказать, что такая ситуация
(названия двух команд случайно совпали)
встречается достаточно редко. В конце концов,
даже модульность в программировании не спасает.
Запаришься все имена писать с квалификаторами,
а когда будешь использовать using, тут проблемы и наступят.

>Каким образом? Только не спешите с ответом, подумайте хорошо.
За пять секунд? Как вы можете быть в этом уверены?

Делаете replace по всему тексту.

>Извините, но проблемы принципиальные. Собственно, я не должен был отвечать на ваш вопрос, а закатывать глаза в вашем стиле: «Вы несёте какую-то совершеннейшую чушь.» Потому что вопросы модульности разжёвывались почти всеми авторами учебников по программированию, начиная с Дейкстры.

Не те масштабы, чтобы активно развивать модульность.
ТеХ предназначен для набора статей и книг,
в то время, как программистские проекты
зачастую пишутся сотнями и тысячами людей.
Самое близкое в ТеХе — это сборник статей
нескольких авторов. В этом случае им просто выдают
стилевой файл, и сами авторы за всем следят.
Для ТеХа модульность — ненужное (а потому
вредное) усложнение.
Кнут был прекрасно знаком с идеями модульности,
и его решение в отношении ТеХа было принято
с учётом этого знания.

>Вы ошибаетесь, это всё-таки проблема языка — минимизировать ошибкоопасные конструкции. Разработчики языка не имеют морального права винить пользователей в своих недоработках, дескать, «Если не хотите получать по лбу, то не наступайте на забытые нами грабли! Мало ли что вам хочется, убирать их нам недосуг!» Собственно, создатели современных языков не позволяют себе таких заявлений, а просто делают, как будет удобнее пользователю. Сравните, например, модульность в C++ и C#. Просто в случае TeXа нет конкурентов и стимула как-то язык развивать.

TeX сделан по принципу C, а не Java.

>делают, как будет удобнее пользователю.
Как будет удобнее пользователям-идиотам.
Нормальным пользователям от этого только одни
неудобства. Именно по этой причине я не использую Java.

>Вот ещё одна из пафосных нелепиц TeX'а... Как вы относитесь к желанию Кнута нумеровать версии своего TeXа, прибавляя по одной цифре к десятичной записи числа π?

Положительно :-)
А METAFONT нумеруется числом e.

(Reply to this)(Parent)(Thread)
Re: Имхо
[info]ltwood
2008-02-22 01:19 am UTC (link)
Надо быть крайне наивным, чтобы думать, что Кнут не размышлял над темой структурности и не структурности своего будущего языка.

Обратимся к первоисточнику:

В 70-е годы у меня сложилось отрицательное отношение к программам, которые пытались делать все для всех. /.../ Поэтому я думал: «Ну, я-то не собираюсь создавать язык программирования; мне нужен просто язык для печати текстов». Мало-помалу, тем не менее, мне требовались все новые возможности, и поэтому программистские конструкции множились. /.../ Но причина, по которой я не включил возможности программирования с самого начала, заключалась в том, что как программист я устал от необходимости учить еще один почти-такой же язык программирования для каждой системы, которая меня интересовала; я хотел попытаться избежать этого. Потом я понял, что это в некотором роде неизбежно, но старался оставаться по возможности верным образцу TeX'а как посимвольного макроязыка. /.../ Было бы неплохо, если бы существовал всем понятный стандарт внутреннего языка-интерпретатора для произвольного приложения. /.../ Теперь, если бы существовал простой язык-интерпретатор, общий с другими системами, я бы, естественно, на него перешел.

Здесь (и не только здесь) Кнут честно описывает стихийность возникновения возможностей TeX'а, связанных с программированием. Входной язык TeX'а заточен на удобный набор текстов. Вообще же главная проблема состоит в том, что входной язык TeX'а пытается одновременно выполнять две совершенно разные задачи — быть удобным (для набора) языком структурной разметки документа и быть полноценным языком программирования для создания макропакетов. Из-за более сильной ориентации на первую задачу вторая сильно страдает. В целом с точки зрения программирования TeX (и METAFONT/METAPOST) представляет собой совершенно чудовищный и уродливый макропроцессор в худшем смысле этого слова.

Надуманная проблема. Я много лет занимаюсь разнообразным TeXackingом, и никаких проблем подобного рода не испытывал. Возможно, для LaTeXа с его чудовищным размером это более актуально.Опять же, надо аккуратнее писать макропакеты. Это проблема не языка, а авторов LaTeXа или тех пакетов, которыми вы пользуетесь.

Много это сколько? За 15 лет работы с plainTeX'ом, AMSTeX'ом и LaTeX'ом я неоднократно сталкивался с подобными проблемами, когда макросы из одного пакета конфликтовали с макросами из другого пакета. Эта проблема актуальна для любой системы реальных размеров, решающей реальные задачи верстки. (Кстати, LaTeX был бы не такой и сложной системой, будь он написан на нормальном языке программирования.)

Именно поэтому следующее Ваше утверждение:

Для ТеХа модульность — ненужное (а потому вредное) усложнение.

является полным бредом.

//За пять секунд? Как вы можете быть в этом уверены?
Делаете replace по всему тексту.

А это — еще один пример бреда. Никакой replace не дает никакой уверенности. Я неоднократно был вынужден по нескольку раз менять имена макросов, поскольку все разумные имена оказывались уже занятыми. Более того, любой работающий сегодня макрос может перестать работать завтра, когда изменится его окружение.

В конце концов, даже модульность в программировании не спасает. Запаришься все имена писать с квалификаторами, а когда будешь использовать using, тут проблемы и наступят.

Тут важно принципиальное наличие решения проблемы. То, что какой-то ламер где-то сказал "using namespace", не помешает опытному программисту успешно использовать тот же модуль в сколь угодно враждебном окружении. TeX решать эту проблему даже не пытается. Не потому, что автор не считал ее важной, а потому что «посимвольный макроязык», изначально не предназначенный для использования в качестве языка программирования.

(Reply to this)(Parent)(Thread)
Re: Имхо
[info]dmitri_pavlov
2008-02-22 02:46 am UTC (link)
>Обратимся к первоисточнику:

Первоисточником это быть ни разу не может,
поскольку литературным русским языков Кнут не владеет.
Впрочем, это совершенно не важно, ибо
этот текст совершенно не противоречит чему-либо.

>Здесь (и не только здесь) Кнут честно описывает стихийность возникновения возможностей TeX'а, связанных с программированием. Входной язык TeX'а заточен на удобный набор текстов. Вообще же главная проблема состоит в том, что входной язык TeX'а пытается одновременно выполнять две совершенно разные задачи — быть удобным (для набора) языком структурной разметки документа и быть полноценным языком программирования для создания макропакетов. Из-за более сильной ориентации на первую задачу вторая сильно страдает. В целом с точки зрения программирования TeX (и METAFONT/METAPOST) представляет собой совершенно чудовищный и уродливый макропроцессор в худшем смысле этого слова.

Здесь всё правильно, кроме одного: TeX (а также и METAFONT) не предназначен для программировании.
Если вы что-то забыли, то я напоминаю:
ТеХ — это система, созданная математиком
и для математиков, предназначенная для набора математических
текстов. Если возникает потребность в нетривиальном
программировании, следует писать внешнюю программу.
Именно по этой причине (C)TANGLE, переводящий
(C)WEB в TeX, написан на Pascal/C, а вовсе
не на ТеХе (как это сделали бы в LaTeXe).
И это совершенно правильно.

Я вообще не понимаю, у кого могла возникнуть больная идея
использовать ТеХ для нетривиального программирования.
Видимо, у того же Лемпорта, который, в отличии от Кнута,
был программистом.

>Много это сколько?
Использую ТеХ с 1999 года.

>Много это сколько? За 15 лет работы с plainTeX'ом, AMSTeX'ом и LaTeX'ом я неоднократно сталкивался с подобными проблемами, когда макросы из одного пакета конфликтовали с макросами из другого пакета. Эта проблема актуальна для любой системы реальных размеров, решающей реальные задачи верстки.

Это проблема тривиальным образом решается
обёртыванием нужного места в тексте в \begingroup \endgroup.

>Именно поэтому следующее Ваше утверждение:
>Для ТеХа модульность — ненужное (а потому вредное) усложнение.
>является полным бредом.

Бредом, как я только что продемнострировал, являются
как раз ваши высказывания.
Максимум, на что предназначен ТеХ — большая книга
(2000 страниц, например).
А для программирования на сотни тысяч строк он как
раз не предназначен.

>А это — еще один пример бреда. Никакой replace не дает никакой уверенности. Я неоднократно был вынужден по нескольку раз менять имена макросов, поскольку все разумные имена оказывались уже занятыми.

Как-то неловко даже указывать, что имена макросов
надо выбирать такие, которые ещё не использовались.
(Проверяется это тривиально: делается Search по этому
имени.) Если вы не удосужились этого сделать,
то сами создали себе работу.

>Более того, любой работающий сегодня макрос может перестать работать завтра, когда изменится его окружение.

Как я уже говорил, все проблемы подобного рода
тривиальным образом решаются
путём обёртывания в \begingroup \endgroup.
И никакие смены окружения не страшны.

(Reply to this)(Parent)(Thread)
Re: Имхо
[info]ltwood
2008-02-22 01:56 pm UTC (link)
Первоисточником это быть ни разу не может

Кнут Д.Э. Компьютерная типография. М.: Мир, 2003, 668 с. [стр. 645--646]

TeX (а также и METAFONT) не предназначен для программировании

Ответ Кнута: Потом я понял, что это в некотором роде неизбежно /.../ если бы существовал простой язык-интерпретатор, /.../ я бы, естественно, на него перешел

Если возникает потребность в нетривиальном программировании, следует писать внешнюю программу.

Очевидно, что это возможно только в простейших случаях, а именно, когда нет необходимости писать собственные реализации TeX'овских хуков.

Это проблема тривиальным образом решается обёртыванием нужного места в тексте в \begingroup \endgroup.

Выяснение того, почему \begingroup в большинстве случаев не является решением, можете считать упражнением.

Максимум, на что предназначен ТеХ — большая книга (2000 страниц, например).

Книга в 2000 страниц может содержать несколько тысяч ссылок, ручное управление которыми окажется утомительным и неприятным занятием. Автоматическое управление ссылками потребует логики, которая реализована в LaTeX'е и полностью отсутствует в plainTeX'е. Т.е. с точки зрения обычного пользователя решение, предоставляемое plainTeX'ом, не масштабируется дальше небольшой статьи.

А для программирования на сотни тысяч строк он как раз не предназначен.

К сожалению, проблемы начинаются уже с 1000 строк.

имена макросов надо выбирать такие, которые ещё не использовались. (Проверяется это тривиально: делается Search по этому имени.)

О, решение в Вашем духе, "search and replace". Когда-нибудь Вы сами поймете, почему такие решения на самом деле решениями не являются. Подсказка: корпус исходников, в которых следует искать, заранее не известен, особенно, если ожидается, что документ имеет достаточно большое время жизни. Самый страшный неофит — опытный неофит, научившийся успешно решать все проблемы своими негодными средствами.

(Reply to this)(Parent)(Thread)
Re: Имхо
[info]dmitri_pavlov
2008-02-22 06:05 pm UTC (link)
>Кнут Д.Э. Компьютерная типография. М.: Мир, 2003, 668 с. [стр. 645--646]

Правильно, это не первоисточник, а его перевод.

>Ответ Кнута: Потом я понял, что это в некотором роде неизбежно /.../ если бы существовал простой язык-интерпретатор, /.../ я бы, естественно, на него перешел

Такого языка не существует и сейчас.
Ещё раз: ТеХ не предназначен для серьёзного программирования.
Это можно видеть даже из перевода книги Кнута, который
вы цитируете.

>Очевидно, что это возможно только в простейших случаях, а именно, когда нет необходимости писать собственные реализации TeX'овских хуков.

Приведите пример, разберёмся.

>Выяснение того, почему \begingroup в большинстве случаев не является решением, можете считать упражнением.

Вы уж поясните, а то я 9 год программирую, не знаю.
Можете привести пример.

>ручное управление которыми окажется утомительным и неприятным занятием.

Для таких вещей есть BibTeX.

>Автоматическое управление ссылками потребует логики, которая реализована в LaTeX'е и полностью отсутствует в plainTeX'е.

Смеялся. Смотри выше.

>К сожалению, проблемы начинаются уже с 1000 строк.

Какие же? Приведите примеры.

>Подсказка: корпус исходников, в которых следует искать, заранее не известен, особенно, если ожидается, что документ имеет достаточно большое время жизни.

Что-что? Мне казалось, что у нас речь идёт о том,
что ТеХнический редактор делает правки в уже
полностью собранном сборнике статей.
К тому же, как я сказал, \begingroup эту проблему
прекрасно решает.

>Самый страшный неофит — опытный неофит, научившийся успешно решать все проблемы своими негодными средствами.

Голословное утверждение.

(Reply to this)(Parent)(Thread)
Re: Имхо
[info]ltwood
2008-02-23 05:22 am UTC (link)
Такого языка не существует и сейчас.

Для любого программирования (даже самого простейшего, которым все мы постоянно занимаемся в TeX'е) любой широко распространенный язык (JavaScript, TCL, Lua, Schema) будет лучше TeX'овской эзотерики. Самый простой код в TeX'е выглядит ужасно с любой точки зрения. Достаточно уже простого \newif\ifXXX\XXXfalse \ifXXX ... \fi — все что угодно лучше этого, потому что хуже пока никому не удалось придумать.

>Очевидно, что это возможно только в простейших случаях, а именно, когда нет необходимости писать собственные реализации TeX'овских хуков.
Приведите пример, разберёмся.

Прочитайте внимательно свое утверждение выше. Я сказал, что никакой код, требующий анализа состояния TeX'а, возникшего на момент выполнения этого кода, очевидно не может быть реализован как внешняя программа (иначе весь LaTeX мог бы быть препроцессором). Для доказательства своего утверждения можете рассказать, как Вы будете реализовывать функциональность какого-нибудь fancyhdr в виде независимой программы.

>Выяснение того, почему \begingroup в большинстве случаев не является решением, можете считать упражнением.
Вы уж поясните, а то я 9 год программирую, не знаю.
Можете привести пример.

Потому что \begingroup является (слабым) аналогом безымянного namespace в C++ и любой код, определяющий макросы для использования вне себя, вынужден определять их вне group. Соответственно никакой выгоды для написания пакетов (где модульность наиболее важна) этот прием не дает.

>ручное управление которыми окажется утомительным и неприятным занятием.
Для таких вещей есть BibTeX.

Автоматические ссылки (с контекстной зависимостью) не исчерпываются списком литературы. Да и BibTeX'у далеко до претензий на изящество в том месте, где он взаимодействует с TeX'ом.

>Автоматическое управление ссылками потребует логики, которая реализована в LaTeX'е и полностью отсутствует в plainTeX'е.
Смеялся. Смотри выше.

Автоматическое управление ссылками (не только на литературу!) в plainTeX'е и AmSTeX'е требует навыков, недоступных рядовому пользователю. А нерядовой пользователь очень быстро переходит на LaTeX, когда понимает, что начинает его переписывать.

Что-что? Мне казалось, что у нас речь идёт о том, что ТеХнический редактор делает правки в уже полностью собранном сборнике статей.

Нет, речь идет о постоянных конфликтах пакетов по именам макросов. Эта проблема всем известна и очень сложно не столкнуться с ней уже при минимальном опыте нетривиального использования TeX'а. Никакой поиск положения не спасает, поскольку набор используемых пакетов никак заранее не зафиксирован и автор нового пакета просто принципиально не может гарантировать отсутствие конфликтов с другими пакетами (в том числе появившимися позже или попросту ему не известными).

Впрочем, и тексты часто живут гораздо дольше одной публикации и при включении в новое окружение каждый раз требуют внимания, тогда как при минимальной модульности могли бы совершенно не зависеть от окружения.

Голословное утверждение.

Вы его доказываете делом, пытаясь убедить меня в отсутствии проблем, с которыми я уже сталкивался, а Вы пока нет. На досуге подумайте над такими вопросами: а) как в plainTeX'е нормально верстать многостраничные таблицы с согласованной шириной столбцов; б) как объяснить пользователю, сколько раз (и почему) ему нужно компилировать документ при использовании автоматической расстановки ссылок / автоматической сборки оглавления / автоматической сборки предметного указателя; в) [бонус!] как в TeX'е реализовать сборку абзаца в модели плавающего горизонта, когда строки «ложатся» друг на друга не как прямоугольные боксы, а как фигуры, составленные из прямоугольных боксов, соответствующих буквам.

(Reply to this)(Parent)(Thread)
Re: Имхо
[info]dmitri_pavlov
2008-02-23 06:45 am UTC (link)
>Для любого программирования (даже самого простейшего, которым все мы постоянно занимаемся в TeX'е) любой широко распространенный язык (JavaScript, TCL, Lua, Schema) будет лучше TeX'овской эзотерики. Самый простой код в TeX'е выглядит ужасно с любой точки зрения. Достаточно уже простого \newif\ifXXX\XXXfalse \ifXXX ... \fi — все что угодно лучше этого, потому что хуже пока никому не удалось придумать.

Включение элементов структурного программирования
потребовало бы непропорционального возрастания
сложности языка. Что касается вашего примера, то как
раз он мне кажется совершенно нормальным.
\newif\ifX === bool X;
\Xfalse === X = false;
\ifX === if (X)
\fi === fi;
По-моему, здесь очевидное соответствие.

> Я сказал, что никакой код, требующий анализа состояния TeX'а, возникшего на момент выполнения этого кода, очевидно не может быть реализован как внешняя программа (иначе весь LaTeX мог бы быть препроцессором). Для доказательства своего утверждения можете рассказать, как Вы будете реализовывать функциональность какого-нибудь fancyhdr в виде независимой программы.

А что здесь сложного-то? Необходимые параметры
просто передаются программе. Какие проблемы?

Что касается конкретно fancyhdr, то здесь
мы имеем пример ненужного пакета. Гораздо
проще самому задать расположение колонтитулов,
чем возиться с хитроумным пакетом, который
ещё непонятно как работать.

>Потому что \begingroup является (слабым) аналогом безымянного namespace в C++ и любой код, определяющий макросы для использования вне себя, вынужден определять их вне group. Соответственно никакой выгоды для написания пакетов (где модульность наиболее важна) этот прием не дает.

Вы имеете ввиду, что он использует \global\def?
Это ошибка разработчика пакета.
\global\def в пакетах совершенно ненужен.
Если вы имели ввиду что-то другое, поясните, что именно.

>Да и BibTeX'у далеко до претензий на изящество в том месте, где он взаимодействует с TeX'ом.

Странное утверждение.
Ничего особо сложного там нет.

К тому же, если сразу вписывать ссылки
в алфавитном порядке (что при написании статьи сделать
совсем несложно), то
можно обойтись без BibTeXa при помощи
одной-двух строк (в сумме будет символов 60).
Если хотите, могу написать. Это абсолютно тривиально.

Тоже самое для автоматической нумерации ссылок внутри текста (я так понимаю, что вы их имели ввиду).

>Автоматическое управление ссылками (не только на литературу!) в plainTeX'е и AmSTeX'е требует навыков, недоступных рядовому пользователю.

Это неверно, я уже указал на это в предыдущем абзаце.

>Нет, речь идет о постоянных конфликтах пакетов по именам макросов. Эта проблема всем известна и очень сложно не столкнуться с ней уже при минимальном опыте нетривиального использования TeX'а. Никакой поиск положения не спасает, поскольку набор используемых пакетов никак заранее не зафиксирован и автор нового пакета просто принципиально не может гарантировать отсутствие конфликтов с другими пакетами (в том числе появившимися позже или попросту ему не известными).
>Впрочем, и тексты часто живут гораздо дольше одной публикации и при включении в новое окружение каждый раз требуют внимания, тогда как при минимальной модульности могли бы совершенно не зависеть от окружения.

Я уже писал, что вина здесь лежит на авторах тех пактов,
которые используют глобальные определения.
Не надо их использовать. Они предназначены для другого.
Кстати, а они их действительно используют? Зачем?
Как-то это странно очень.

>Вы его доказываете делом, пытаясь убедить меня в отсутствии проблем, с которыми я уже сталкивался, а Вы пока нет.

Всё проще: я их себе не создаю.

(Reply to this)(Parent)(Thread)
Re: Имхо
[info]ltwood
2008-02-24 06:53 am UTC (link)
Включение элементов структурного программирования потребовало бы непропорционального возрастания сложности языка.

Это неверно. Имеются примеры более простых и одновременно более структурированных языков. Уродский язык TeX'а надоел не мне одному. См., например, google по ключевому слову luatex.

Что касается вашего примера, то как раз он мне кажется совершенно нормальным.

No comments. Очевидное синтаксическое уродство Вы называете нормальным. Либо Вы не видели нормальных языков, либо мне просто нечего сказать.

А что здесь сложного-то? Необходимые параметры просто передаются программе. Какие проблемы?

Именно механизм передачи параметров и отсутствует (да и вообще нет механизма взаимодействия с внешним окружением). Во всех случаях задача решается посредством вывода информации в файл, постобработки и повторной компиляции. Если такое решение кажется Вам естественным, то снова no comments.

Что касается конкретно fancyhdr, то здесь мы имеем пример ненужного пакета.

Мне хочется выводить одни колонтитулы на четных страницах, другие на нечетных и не выводить никаких колонтитулов на тех страницах, где начинаются главы. Колонтитулы на четных страницах в простых случаях должны автоматически формироваться из названия главы. В любой издательской системе это поведение является одной из умалчиваемых схем. a) Я пользователь и не хочу писать никаких программ mdash; как мне обойтись без fancyhdr? b) Я программист и меня тошнит от противоестественных языков — как без fancyhdr реализовать эту схему с помощью внешней программы? Проблемы тут именно с передачей параметров.

Вы имеете ввиду, что он использует \global\def? Это ошибка разработчика пакета.

Кроме \gdef нет никакого другого способа объявить макрос, доступный пользователю пакета для изменения. Т.е. вся интерфейсная часть пакета должна быть глобальной и все интерфейсы должны быть согласованными, что невозможно обеспечить и гарантировать для долгоживущих пакетов/текстов.

Тоже самое для автоматической нумерации ссылок внутри текста

Управление ссылками не исчерпывается их нумерацией. Оно включает в себя зависимость внешнего вида ссылки от контекста ее использования (например, ссылка может включать номер главы) и возможность автоматического его изменения при смене контекста (сначала текст был статьей, а потом без изменений стал главой диссертации). Впрочем, написание даже этих 60 символов недоступно рядовому пользователю (не надо их писать, я умею).

я их себе не создаю.

Вопрос в том, насколько масштабные задачи Вы решаете. Сколько книг объемом более 100 страниц Вы издали и сколько поддержали издательских проектов, заключающихся в регулярном издании журнала, когда необходимо минимизировать участие в технологическом процессе специалиста высокой квалификации. А статейки в TeX'е набирать, это и кошку научить можно ;))

(Reply to this)(Parent)(Thread)
Re: Имхо
[info]dmitri_pavlov
2008-02-24 07:58 am UTC (link)
>Это неверно. Имеются примеры более простых и одновременно более структурированных языков. Уродский язык TeX'а надоел не мне одному. См., например, google по ключевому слову luatex.

Извините, но в TeXe программированию посвящено
два или три примитива. А в LuaTeX?

>No comments. Очевидное синтаксическое уродство Вы называете нормальным. Либо Вы не видели нормальных языков, либо мне просто нечего сказать.

Это не синтаксическое уродство, это просто другой
синтаксис. Я так понимаю, что LISP вы тоже считаете уродством?

>Именно механизм передачи параметров и отсутствует (да и вообще нет механизма взаимодействия с внешним окружением).

Слушайте, я не нанимался учить вас TeXу.
В реализации Web2C (которая используется более
чем в 99/100 дистрибутивов) есть стандартный
метод взаимодействия с внешним окружением. Учите матчасть.

>Во всех случаях задача решается посредством вывода информации в файл, постобработки и повторной компиляции. Если такое решение кажется Вам естественным, то снова no comments.

Смотри выше.

>Мне хочется выводить одни колонтитулы на четных страницах, другие на нечетных и не выводить никаких колонтитулов на тех страницах, где начинаются главы. Колонтитулы на четных страницах в простых случаях должны автоматически формироваться из названия главы. В любой издательской системе это поведение является одной из умалчиваемых схем. a) Я пользователь и не хочу писать никаких программ mdash; как мне обойтись без fancyhdr? b) Я программист и меня тошнит от противоестественных языков — как без fancyhdr реализовать эту схему с помощью внешней программы? Проблемы тут именно с передачей параметров.

То, что вы написали, тривиальным образом реализуется без всякого программирования.

>Я программист и меня тошнит от противоестественных языков

Вы программист-шовинист. Для меня приемлемы языки
с разным синтаксисом: TeX, C, LISP. А также
многие другие.

>Проблемы тут именно с передачей параметров.

Этого я не понял. Причём здесь это?

>Кроме \gdef нет никакого другого способа объявить макрос, доступный пользователю пакета для изменения. Т.е. вся интерфейсная часть пакета должна быть глобальной и все интерфейсы должны быть согласованными, что невозможно обеспечить и гарантировать для долгоживущих пакетов/текстов.

Извините, но это просто не соответствует действительности.
Я даже не знаю, что сказать.
Посмотрите реализации стандартных пакетов
plain TeXa. Даже как-то странно вести дискуссию
на этом уровне.

>Управление ссылками не исчерпывается их нумерацией. Оно включает в себя зависимость внешнего вида ссылки от контекста ее использования (например, ссылка может включать номер главы) и возможность автоматического его изменения при смене контекста (сначала текст был статьей, а потом без изменений стал главой диссертации).

Номер главы добавляется при помощи одной команды.

>Впрочем, написание даже этих 60 символов недоступно рядовому пользователю (не надо их писать, я умею).

У нас с вами разные представления о рядовых
пользователях. В моём понимании рядовой
пользователь умеет всё, что описано
в TeXbook и не помечено знаком опасного поворота.

Что довольно естественно, заметьте. Кстати,
объём соответствующего текста совсем невелик
и составляет 250 или около того страниц.
А если выкниуть опасные повороты, то будет меньше 200.
Совсем немного. Поменьше большинства руководств
по LaTeXу, вроду чудовищной книжки Львовского.

Теперь что касается журналов, то ваши претензии
всё равно туманны. Хорошо, предположим,
что каждая статья определяет свои макросы,
притом имена конфликтуют между собой.
Не говоря о том, что можно использовать
\begingroup, который решает все проблемы,
в любом случае новые макроопределения
перекроют старые и никаких проблем не возникнет.
Хотелось бы увидеть конкретный пример.

>А статейки в TeX'е набирать, это и кошку научить можно ;))

Вы, видимо, так и не научились, судя по вашему
незнанию нескольких простейших аспектов ТеХа.
Хотите сказать, что вы глупее кошки?
(No offense meant.)

(Reply to this)(Parent)(Thread)
Re: Имхо
[info]ltwood
2008-02-24 02:33 pm UTC (link)
Извините, но в TeXe программированию посвящено два или три примитива. А в LuaTeX?

Тоже порядка десятка. 1) Зато значительно более удобных и удобочитаемых; 2) Зато там нет замечательных операторов \aftergroup, \afterassignment, и \futurelet; 3) Зато там нет TeX'овского правила поиска \fi (или \else) для текущего \if; 4) Зато там нет выделенной стадии расширения макросов, в процессе которой переменные остаются неизменными. Все эти особенности делают программирование в TeX'е практически невозможным и существенно тормозят его развитие как издательской системы. Сейчас все это понимают и одновременно идет работа над несколькими проектами, снимающими эти ограничения — один из них (LuaTeX, на базе lua) я упомянул, другой называется exTeX (на базе Java).

так понимаю, что LISP вы тоже считаете уродством?

В значительной степени (до TeX'а ему все равно далеко). Кстати, David Kastrup предлагал Schema в качестве базового языка для exTeX, но использовать стали именно Java. Так что против уродств синтаксиса люди голосуют ногами (вернее, уже проголосовали).

В реализации Web2C (которая используется более чем в 99/100 дистрибутивов) есть стандартный метод взаимодействия с внешним окружением.

Есть, но он НЕ стандартный. Он не описан в TeXbook и его стабильность не гарантируется. Кстати, какой пакет (в широком смысле) из известных его использует? И еще, если это инструмент для пользователя (пусть опытного и не конечного), то где он описан? А вывод в файл стандартизирован, и все используют именно его как единственный метод.

Посмотрите реализации стандартных пакетов plain TeXa. Даже как-то странно

Читывал, уже под сотню читанных набежало. Пожалуйста, принесите пример в студию — просто ссылку на пакет и место в нем (или ссылку на раздел в TeXbook). А то после Ваших совершенно ламерских (ничего личного!) заявлений про всемогущий "search and replace" появляется подозрение, что под разными «тривиальным образом реализуется» Вы понимаете что свое, личное, никому не известное ;))

В моём понимании рядовой пользователь умеет всё, что описано в TeXbook и не помечено знаком опасного поворота. /.../ объём соответствующего текста совсем невелик и составляет 250 или около того страниц. /.../ Поменьше большинства руководств по LaTeXу, вроду чудовищной книжки Львовского.

Рядовой пользователь просматривает первые 50 страниц Львовского и начинает успешно набирать свои тексты, заглядывая в остальную часть текста в сложных местах и обращаясь к эксперту, если это не помогает.

(Reply to this)(Parent)(Thread)
Re: Имхо
[info]ltwood
2008-02-24 03:08 pm UTC (link)
«понимаете что свое, личное» -> «понимаете что-то свое, личное»

(Reply to this)(Parent)
Re: Имхо
[info]dmitri_pavlov
2008-02-24 09:19 pm UTC (link)
>Тоже порядка десятка.
Ну-ну. То-то я вижу, что их Reference Manual
заниает 112 страниц. Не многовато-ли для
10 примитивов, а?

>1) Зато значительно более удобных и удобочитаемых;
С вашей точки зрения.

>2) Зато там нет замечательных операторов \aftergroup, \afterassignment, и \futurelet;

А вы хотя бы понимаете, что добавления аналогичной функциональности в Lua потребует способа внедрения
во внутренние структуры ТеХа? И как следствие,
очередного усложнения языка.

>3) Зато там нет TeX'овского правила поиска \fi (или \else) для текущего \if; 4) Зато там нет выделенной стадии расширения макросов, в процессе которой переменные остаются неизменными.

А это уже дополнительные возможности, а не недостатки.
Если использовать их в том же контексте, что и предлагаемый
Lua, то это правила не надо будет использовать вообще.

>Все эти особенности делают программирование в TeX'е практически невозможным и существенно тормозят его развитие как издательской системы.

Наверное, именно по этой причине ТеХ
используется для набора 0.9999 всех физических
и математических журналов и книг?

>Сейчас все это понимают и одновременно идет работа над несколькими проектами, снимающими эти ограничения — один из них (LuaTeX, на базе lua) я упомянул, другой называется exTeX (на базе Java).

Эти проекты смогут занять разве что свою узкую нишу
по следующим причинам: (1) квалификация авторов
явно не дотягивает до уровня Кнута; (2) ТеХ хорошо
известен, стабилен, хорошо задокументирован,
у него обширное сообщество. Коммерческая инертность
сделает своё дело. (3) Добавляемые возможности
не нужны 0.99 пользователей.
Впрочем, дискутировать по этому поводу у меня нет
ни малейшего желания.

>В значительной степени (до TeX'а ему все равно далеко). Кстати, David Kastrup предлагал Schema в качестве базового языка для exTeX, но использовать стали именно Java. Так что против уродств синтаксиса люди голосуют ногами (вернее, уже проголосовали).

Уже проголосовали, говорите? Что-то как-то незаметно.
Только какие-то маргинальные проекты в сети валяются.

>Есть, но он НЕ стандартный.
Естественно, он не стандартный. Он зависит от операционной
системы и не может быть стандартным.

>Он не описан в TeXbook и его стабильность не гарантируется.
Web2c будет постабильнее LaTeXa.

>Кстати, какой пакет (в широком смысле) из известных его использует?

Откуда мне знать? Я что, справочник по LaTeXy?

>И еще, если это инструмент для пользователя (пусть опытного и не конечного), то где он описан?
Он описан в документации Web2c.

>А вывод в файл стандартизирован, и все используют именно его как единственный метод.

Вывод в файл стандартизирован, но кто вам гарантирует,
что \write пишет файлы туда же, откуда их читает \input?
Да, de facto эти именно так и происходит.
De facto также верно, что все используют web2c,
поэтому можно делать как и говорил, и всё будет
переносимо на любую систему.

>Читывал, уже под сотню читанных набежало. Пожалуйста, принесите пример в студию — просто ссылку на пакет и место в нем (или ссылку на раздел в TeXbook).

epsf.tex. Вы предпочитаете отвечать на второстепенные вопросы,
в то время, как на главный вопрос вы так и не ответили:
а вам-то что с того, что имена конфликтуют?
Вы же хорошо знаете, что \def переопределяет команду,
и ему нет дела, была ли он определена до того.

Ситауция здесь такая, что у нас есть сборник статей,
и каждая статья компилируется как отдельный файл.
Прекрасно, тогда все вместе они тоже прекрасно будут
компилироваться, если какие-то имена конфликтуют,
то это совершенно неважно.

Исключение составляет тот случай, когда
модифицируются макросы plain.tex или примитивы,
но этого делать как раз не надо.

>Рядовой пользователь просматривает первые 50 страниц Львовского и начинает успешно набирать свои тексты, заглядывая в остальную часть текста в сложных местах и обращаясь к эксперту, если это не помогает.

Ага. Я видел много таких горе-пользователей от книги Львовского.
Они не знают простейших вещей, например,
что тире надо набирать не одним дефисом, а тремя.

(Reply to this)(Parent)(Thread)
Re: Имхо
[info]ltwood
2008-02-26 04:09 am UTC (link)
Reference Manual заниает 112 страниц. Не многовато-ли для 10 примитивов, а?

Нормально для описания программного интерфейса к потрохам TeX'а, описанным его автором на 500 страницах.

добавления аналогичной функциональности в Lua потребует способа внедрения во внутренние структуры ТеХа? И как следствие, очередного усложнения языка.

Вы, похоже, с программированием знакомились по Кнутовскому «Все про TeX». 1. Никто не собирается менять Lua, нормальному языку не требуются такие конструкции. 2. Эти конструкции сами по себе не вносят никакой новой функциональности, а являются «грязными хаками», служащими для обхода ограничений TeX'овской модели обработки входного потока вообще и макросов в частности.

А это уже дополнительные возможности, а не недостатки. Если использовать их в том же контексте, что и предлагаемый Lua, то это правила не надо будет использовать вообще.

Это неверно. Я перечислил базовые правила разбора входного потока, они не могут измениться в зависимости от контекста.

Наверное, именно по этой причине ТеХ используется для набора 0.9999 всех физических
и математических журналов и книг?

Нет, не по этой. Просто героический Лэсли Лампорт смог придать TeX'у человеческое лицо и теперь все (99% из 99.99%, пользующихся TeX'ом) пользуются именно LaTeX'ом.

Эти проекты смогут занять разве что свою узкую нишу по следующим причинам:

Да, именно инертность часто заставляет нас пользоваться плохими системами вместо хороших. Впрочем, тут этой проблемы нет. Эти расширения пишутся именно для того 1% пользователей, которые пишут пакеты. Расширения войдут в дистрибутивы, их начнут использовать разработчики пакетов, а пользователи вообще ничего не заметят, кроме появления более удобных и мощных пакетов.

epsf.tex

Команда

grep "^\\def" epsf.tex

даст Вам список определяемых этим пакетом глабальных макросов.

на главный вопрос вы так и не ответили: а вам-то что с того, что имена конфликтуют?

Елки-палки. Два пакета X и Y случайно используют один и тот же макрос M, который пользователь может переопределить. В тексте A, использующем пакет X, этот макрос не переопределен, пользователя устраивает дефолтное поведение. В тексте B другой пользователь использует пакет Y и переопределяет макрос M. Все, тексты A и B больше вместе не живут.

у нас есть сборник статей, и каждая статья компилируется как отдельный файл.

Это у Вас есть сборник, а у меня есть монография с общими ссылками всех видов и компилируется она как единый файл.

(Reply to this)(Parent)(Thread)
Re: Имхо
[info]dmitri_pavlov
2008-03-03 06:14 am UTC (link)
>Нормально для описания программного интерфейса к потрохам TeX'а, описанным его автором на 500 страницах.

500 страниц существуют в вашем больном воображении.

>Вы, похоже, с программированием знакомились по Кнутовскому «Все про TeX».

Необо