Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Шахтер,
>>>> главная трудность состоит в том, что без знания типа объекта, представленного в тексте программы именем G, мы не можем правильно провести интерпретацию данного фрагмента <...>
>> ПК> Это подход, принятый в C++. Более сложный для анализа компилятором, и, действительно, не поддающийся описанию контекстно-свободной грамматикой, т.к. как минимум не проще задания грамматикой предварительного объявления переменных, что сводит задачу к классике.
>> Если я правильно понимаю ситуацию, то эта проблема решается встраиванием name lookup непосредственно в LR(1) парсер, т.е. парсер, вытащив очередной токен-идентификатор, должен запустить процедуру name lookup для нахождения определения идентификатора
ПК>В общем да, но ему далеко не обязательно делать это для каждого встреченного идентификатора. Можно отложить поиск имени до момента, когда анализ непосредственно дойдет до неоднозначности. Правда, иногда это сделать нелегко, к тому же порой приходится делать возврат, т.к. неоднозначность распознается уже после того, как первые шаги разбора пошли в "неверном" направлении. Но это все равно может оказаться более эффективным, чем поиск имен для всех идентификаторов.
Можно делать загрузку следующего токена, и, если в синтаксической таблице нашлась неоднозначность, запускать name lookup немедленно, в противном случае, отложенно. Смысл всего этого -- как можно меньше отойти от классического LR(1) парсера, чтобы упростить реализацию парсинга и большую часть её делать механически по механически же сгенерированным синтаксическим таблицам, а не вручную.
Я, правда, не совсем понимаю, какой бенефит от отложенного name lookup. Его же всё равно нужно делать, раньше или позже. Единственное, что приходит на ум -- упрощение архитектуры компилятора. В плане эффективности не должно быть разницы.
>> (отсюда растет корнями невозможность отказаться в С++ от принципа предварительного объявления как это сделано в С#)
ПК>А вот как это следует из предыдущего, я пока не вижу.
А
где я буду делать name lookup? Только в отпарсеной части кода, т.е.
перед идентификатором. Всё, что следует после -- terra incognita.
ПК>Имхо, в C++ вполне можно ввести модули, при импорте которых компилятор будет подгружать те же определения сущностей, которые он строит при анализе заголовков, включенных директивой препроцессора.
Ну разумеется, только это не противоречит принципу предварительного объявления, поскольку, фактически, это эквивалентно включению в самое начало единицы трансляции соответствующих определений.
Ну так предкомпиляция уже лет как десять, если не больше, существует, так что технических препятствий нет.
ПК>Вопрос больше не в технических аспектах, а в том, чтобы удачно совместить концепцию модулей с огромным количеством уже существующего кода, использующего #include. Благо, хоть какие-то подвижки в этом направлении уже начались.
Идея прекрасная, синтаксис только дурной. Почему бы не ввести ключевое слово module и не писать, например,
using module std;? Не стоит перегружать namespace.
... << RSDN@Home 1.1.0 stable >>