Легенда:
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Лисперы со смолтолковцами матерятся когда им надо... [упд2] 09.09.08 19:52 Число просмотров: 3150
Автор: amirul <Serge> Статус: The Elderman Отредактировано 09.09.08 22:27 Количество правок: 2
|
Лисперы со смолтолковцами матерятся когда им надо поддерживать чужой код. Слышал о нескольких крупных проектах, которые оказалось проще ПЕРЕПИСАТЬ на нормальном языке, вместо того, чтобы поддерживать лисповую реализацию (вроде назывались lucent и yahoo store, хотя могу ошибаться).
> А вот стоит почитать разрабов компиляторов С++ — им не > позавидуешь.
А чего им не позавидуешь? Тут понимаешь какое дело, разработать с нуля фронтэнд (тот который из C++ кода получает IR - промежуточное представление) C++ компилятора - дело одного-двух месяцов для одного более-менее квалифицированного программиста. Просто потому что в открытом доступе ПОЛНО готовых препроцессоров, лексеров и грамматик (именно грамматик, а не готовых парсеров) для плюсов.
А вот сразу после этого начинаются проблемы. Вот только на этом этапе совершенно не важно какой язык программирования был изначально - оптимизация промежуточного представления, и кодогенерация (с оптимальным распределением регистров и оптимальным шедулингом инструкций) - собственно бекэнд - вот это задачки который надо решать долго. Иногда на протяжении всего жизненного цикла компилятора.
> Хотя нет, они очень горды, что у них таки получился быстрый > и надёжный компилятор с С++ за... 3 года. Ачуметь.
lifecycle компилятора может быть и дольше. Статью не читал, но не уверен, что эти три года - это время от начала разработки до альфы. Скорее уж до production/stable. Кстати, очень часто как лисперы (чикен) так и смолтолковцы (squeak кажется - точно не помню) в качестве промежуточного представления используют C. Просто потому, что писать бекэнд - действительно весьма неблагодарная задача.
> http://www.pcmag.ru/issues/detail.php?ID=9972 > > Особенно впечатляет "что такое T(a); если T — некоторый > тип?" Ну и далее по тексту. Неа, спасите -))
А что впечатляет то? Известная (единственная) контекстная зависимость плюсов, и точно так же есть стандартный и эффективный путь ее решения (lexical tie-in), описанный в комментариях практически ко всем грамматикам, не говоря уж о книгах по теории компиляторов - совершенно НИЧЕГО СТРАШНОГО. Квалифицированный разработчик пройдет это даже не замедлившись.
Кстати, в данном случае эта зависимость от контекста передана неверно (непонятно то ли журналамеры набочили, то ли еще кто): если T - некоторый тип, то T(a) - это конструктор этого типа. Без вариантов. А вот если есть запись T(a), то без доступа к метаинформации об идентификаторе T нельзя сказать какая свертка нужна - вызов функции T или конструирование типа T (и решение соответственно - лексер вместо того, чтобы сразу возвращать терминал IDENTIFIER просматривает таблицу символов для текущего контекста и, если T является типом, возвращает терминал TYPENAME - все).
------------
Подробнее можно например здесь:
ftp://ftp.iecc.com/pub/file/c++grammar/grammar5.txt
Начиная со слов "REVIEW: STANDARD LEXICAL ANALYSIS HACK: TYPEDEFname vs IDENTIFIER"
------------
http://www.computing.surrey.ac.uk/research/dsrg/fog/
Вот здесь чувак разобрался с reduce/reduce конфликтами без помощи лексера. Каким образом - я не разбирался (у него есть документация), но это готовый парсер вместе с yacc-овскими action-ами. Собственно это и есть готовый front-end. На выходе у нас AST (или сразу IR - как захочешь). Остальные проблемы, как я уже говорил, не зависят от первоначального языка.
|
|
|