информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Все любят медАтака на Internet
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 С наступающим 
 Серьезная уязвимость в Apache Log4j 
 Крупный взлом GoDaddy 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / miscellaneous
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Лисперы со смолтолковцами матерятся когда им надо... [упд2] 09.09.08 19:52  Число просмотров: 2807
Автор: 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 - как захочешь). Остальные проблемы, как я уже говорил, не зависят от первоначального языка.
<miscellaneous> Поиск 








Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2022 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach