Есть задача реализовать CodeCompletion для скриптового редактора, написанного на Delphi. Для корректной реализации фичи необходимо распарсить текст скрипта до курсора. Подскажите, может есть готовый парсер который вывалит по исходнику нечто вроде XML, который можно будет потом проанализировать руками, и построить по этому делу корректный список для CodeCompletion.

Да, такой парсер есть, это Boost.Spirit. На вход ему нужно задать БНФ грамматику языка, но он event-driven, поэтому построение XML или синтаксического дерева нужно будет писать самому.
http://spirit.sourceforge.net/distrib/spirit_1_8_5/libs/spirit/index.html

> molto mutevoli   (18.12.08 08:51) [1]

Замечательно, а как использовать boost в программе, написанной на Дельфи?
Зачем давать заведомо бесполезные советы?

Alkid   (18.12.08 11:22) [2]

>Замечательно, а как использовать boost в программе, написанной на Дельфи?

Например, посредством динамически загружаемых библиотек.

>Зачем давать заведомо бесполезные советы?

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

> molto mutevoli   (18.12.08 11:30) [3]
> Например, посредством динамически загружаемых библиотек.

В принципе как вариант. Или, мне тут ещё подумалось, можно сделать компонент на CBuilder.


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

В чём заключается "непомерность запросов" автора?

>В чём заключается "непомерность запросов" автора?

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

Впрочем, мне удалось найти в гугле некий сомнительный рантайм БНФ-парсер на дельфи в бета стадии. Ссылку не дам, так как, если его удалось найти мне, то сможет и автор. Пусть тренируется.

> molto mutevoli   (18.12.08 11:55) [5]
> Насколько можно понять из вопроса, непомерность запросов
> автора заключается в том, что он хочет получить результат
> сразу, используя готовый компонент, не затрачивая при этом
> никаких усилий (возможно, он просто не представляет, как
> работают синтаксические анализаторы).

Ох, чую я тут двойные стандарты. :) Скажи, а boost::spirit это разве не готовый программный компонент, который можно использовать не затрачивая усилий (подразумеваются усилия на его разработку)?

Alkid   (18.12.08 12:10) [6]

Попробуйте его использовать, и вы поймете о чем я говорю - на определение грамматики и построение синтаксического дерева следует затратить некоторые усилия (как, вероятно, и при использовании любого подобного парсера). Мы можем предположить, что автор не говорит об этом, так как ему известно как работают синтаксические анализаторы. Но тогда, автор должен быть достаточно опытен, для того, чтобы найти нужный компонент самостоятельно (мне удалось найти на sourceforge нечто, по описанию напоминающее Spirit).
Если автор сам не опровергнет этого, то нам остается предположить, что автор не знает о том, с чем ему предстоит столкнуться, и что выполнить эту работу быстро в принципе не получится, так как кроме голого синтаксического дерева нужно обрабатывать систему типов и пр., то есть писать еще элементы компилятора, если конечно это уж совсем не простой скриптовый язык, для которого комплишен может и не понадобится.
Но это все уже желчное буквоедство и пустое сотрясание воздуха.

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

> molto mutevoli   (18.12.08 12:39) [7]

Что-то ты как-то всё усложняешь :)
ИМХО, проще надо к таким вещам относиться.

> molto mutevoli   (18.12.08 11:30) [3]
> Alkid   (18.12.08 11:22) [2]
>
> >Замечательно, а как использовать boost в программе, написанной
> на Дельфи?
>
> Например, посредством динамически загружаемых библиотек.
>
>
> >Зачем давать заведомо бесполезные советы?
>
> Это иногда бывает полезно для расширения кругозора, и осознания
> автором непомерности своих запросов (да, именно к этому
> приучает система компонентов Delphi), а так же неполноценностей
> используемого им инструмента. К сожалению, если об этом
> говорить прямо, то часто это просто не воспринимается, или
> принимается в штыки.


Готов с тобой обсудить неполноценности инструмента.
Укажи на полноценный инструмент. И аргументируй свой ответ.

>К сожалению, если об этом говорить прямо, то часто это просто не >воспринимается, или принимается в штыки.

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

> molto mutevoli   (18.12.08 11:55) [5]
>
>
> Впрочем, мне удалось найти в гугле некий сомнительный рантайм
> БНФ-парсер на дельфи в бета стадии. Ссылку не дам, так как,
>  если его удалось найти мне, то сможет и автор. Пусть тренируется.
>
>

dyacc & dlex вполне себе законченные продукты, без некоторых фич стандартного yacc'a. Я у себя прекрасно использую несколько модифицированные их версии. И инструмент в нормальных руках ой как полноценен. А кому и кобыла невеста, как известно.

oxffff ©   (18.12.08 14:54) [9]

>Готов с тобой обсудить неполноценности инструмента.
>Укажи на полноценный инструмент. И аргументируй свой ответ.

На достаточно полноценный инструмент было указано в [1]. Теперь ваша задача найти аналогичный инструмент для Delphi (я уже говорил, что нечто похожее мне удалось найти), а так же несколько примеров его использования. Если вы сможете это сделать (то есть аналогичный по возможностям инструмент для Delphi существует), то можно будет сравнить.
Если нет, то будем считать, что универсальный рантайм парсер на дельфи реализовать настолько сложно, что ни у кого не получалось этого сделать.

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


Э-э-э... А Вам не кажется, что универсализм - палко о двух концах? И гораздо проще (быстрее, дешевле) написать очень конкретный продукт, чем продукт универсальный?
В каких-то случаях действительно имеет смысл подумать об более-менее универсальном фреймворке (кстати, определить нужную степень универсальности - это тоже искусство). Но в случаях парсера...
Не знаю, насколько это имеет практическое применение в мире в целом. Алгоритмы есть, как делать - в целом понятно.
Писать универсальный ради "идеи"? Но годам к 24 такой энтузиазм пропадает, т.к. семью кормит надо, а до этого, как правило, знаний и опыта пока не хватает...

> molto mutevoli   (18.12.08 15:20) [11]


Это серьезный подход?

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

Этот вывод никак не напрашивается.
Не сложнее, чем на С++

http://www.grendelproject.nl/dyacclex/
http://www.remobjects.com/ps.aspx

oxffff ©   (18.12.08 15:33) [13]

Должно быть, вы не совсем понимаете, что такое Spirit. Он позволяет задать грамматику языка прямо в исходном коде (правда не совсем в рантайме, но на дельфи так просто не получится из-за отсутствия шаблонов и перегрузки операторов, поэтому единственный вариант - задавать ее в рантайме, как например здесь: http://www.codeproject.com/KB/recipes/spart.aspx), и позволяет полностью интегрировать себя в существующий исходный код без лишних телодвижений (например, задать обработчики токенов). Что собственно и хотет открыватель ветки.
Используя же lex и yacc, вы генерируете парсер и интегриуете его в свое приложение, что может быть далеко не так удобно (я тоже могу сказать, берите yacc и lex, и пользуйтесь).

Скажите теперь, почему аналогов Spirit нет на Delphi?
То о чем я говорил, находится здесь http://sourceforge.net/projects/bnfparser/ , но похоже оно мертво.

> molto mutevoli   (18.12.08 16:02) [14]
> Скажите теперь, почему аналогов Spirit нет на Delphi?

Та нафик оно никому не сдалось потому как :) Подсвечивальщики синтаксиса - есть, простой коде-коплитион прикрутить не сложно, не простой... хм... а оно надо? :)

А boost - по-моему это мега-поделка офигенных масштабов фанатиков от программизма. Столько в него напихано.... интересного, высокопрофессионального, но...

> Скажите теперь, почему аналогов Spirit нет на Delphi?


Всё очень просто. Большинство Опен-сорс проектос на с++ идёт. Соответственно, для большого серьёзного продукта вполне может потребоваться серьезный парсер. Мощный. Гибкий. С кучей возможностей.
Пуркуа бы и не па вынести его в отдельный модуль, благо один фиг - опенсорс.

Как правило, над таким модулем не один человек работает, да и не за голый энтузиазм.
Теперь берём Delphi. Это прекрасное средство RAD, с кучей возможностей, и то что в Delphi делается за пол-плевка, на каком-нибудь JavaScript - замучаешься писать. Т.е. в первую очередь это очень удобное средство для быстрого построения гуя (хотя и не только). Соответственно, реализовывать boost::spirit в рамках VCL Borland (или кто там у них теперь) никогда не будет.
А будет этим заниматься либо какая-нибудь сторонняя контора, которая напишет хороший код, а потом, возможно, Borland его у них купит и включит в свою поставку, либо вообще студенты-энтузиасты, для которых "нет нерешаемых задач" и "любая задача решается максимум за полгода".

А если кому-то и понадобится очень мощный и гибкий парсер, то этот кто-то погуглит-погуглит, да и напишет не парсер, а перемычку. И всё будет работать.

> KSergey ©   (18.12.08 16:23) [15]
> А boost - по-моему это мега-поделка офигенных масштабов
> фанатиков от программизма. Столько в него напихано.... интересного,
>  высокопрофессионального, но...

Но что? Boost - правильная вещь для С++, собравшая в себя реализацию многих вещей, которые раньше делались "велосипедистами" просто потому, что они не поддерживались стандартной библиотекой.

> molto mutevoli   (18.12.08 16:02) [14]
> Должно быть, вы не совсем понимаете, что такое Spirit. Он
> позволяет задать грамматику языка прямо в исходном коде
> (правда не совсем в рантайме, но на дельфи так просто не
> получится из-за отсутствия шаблонов и перегрузки операторов,
>  поэтому единственный вариант - задавать ее в рантайме

Библиотеку, близкую по духу к Spirit`у можно реализовать и на дельфи. Самая большая разница для пользователя будет заключаться в синтаксической форме задания правил (она будет не столь наглядная) и в синтаксической форме взятия "выпарсенных" значений. Разделение работы между run-time и compile-time там будет почти такое же.

> molto mutevoli   (18.12.08 16:02) [14]
>
> oxffff ©   (18.12.08 15:33) [13]
>
> Должно быть, вы не совсем понимаете, что такое Spirit. Он
> позволяет задать грамматику языка прямо в исходном коде

Простите, простите. Повторяю для тех кто в танке. DYacc написан на Delphi, и мы его исходник можем использовать. Кушать на ходу любые LALR(1) грамматики и выплевывать их в деревья, и в XML и куда дуже угодно. В рантайме. Повторю для пущей убедительности: в рантайме, это когда программка работает и может запуздыривать иконку туда где часики.

pasha_golub ©   (18.12.08 18:26) [19]

Нет, это вы простите, может быть я чего-то не понимаю. Что с того, что DYacc написан на паскале? Оригинальный yacc тоже на С написан. Но ведь DLex/DYacc генерируют лексер/парсер в виде процедуры на паскале. Затем нужно прикрутить этот парсер к приложению и соответственно затем собрать.
Каким это образом его нужно модифицировать, чтобы он выдавал скомпилированный парсер во время выполнения программы по произвольному описанию грамматики?

> molto mutevoli   (18.12.08 16:02) [14]
> oxffff ©   (18.12.08 15:33) [13]
>



> Должно быть, вы не совсем понимаете, что такое Spirit. Он
> позволяет задать грамматику языка прямо в исходном коде
> (правда не совсем в рантайме, но на дельфи так просто не
> получится из-за отсутствия шаблонов и перегрузки операторов,


Хотелось бы обратить внимание, что и перегрузка операторов и параметризованные классы уже есть в Delphi. НО!!!

Каким образом наличие этого позволяет легко задать BNF?


>  поэтому единственный вариант - задавать ее в рантайме,
> как например здесь: http://www.codeproject.com/KB/recipes/spart.
> aspx), и позволяет полностью интегрировать себя в существующий
> исходный код без лишних телодвижений (например, задать обработчики
> токенов). Что собственно и хотет открыватель ветки.
> Используя же lex и yacc, вы генерируете парсер и интегриуете
> его в свое приложение, что может быть далеко не так удобно
> (я тоже могу сказать, берите yacc и lex, и пользуйтесь).


Так ничего не машает сенерировать и поключить к проекту код, просто в место задания семантического действия вставить динамический вызов метода по имени некоторого класса(А С++ такое может?) для отвязки обработчика от самого парсера. Или при жесткой связки, вызов конкретного статического метода.

> molto mutevoli   (18.12.08 19:07) [20]


>
> Нет, это вы простите, может быть я чего-то не понимаю. Что
> с того, что DYacc написан на паскале? Оригинальный yacc
> тоже на С написан. Но ведь DLex/DYacc генерируют лексер/парсер
> в виде процедуры на паскале.


В виде класса. Это раз. Далее. Каждый такой класс отличается от другого:

1. Таблицами (переходом, терминальный и нетерминальных символов и прочей другой лабуденью)
2. Реакцией которая будет прописана в yyaction (именно поэтому важно чтобы это был исходник, который впоследствии можно скомпилировать)
3. Вспомогательным кодом

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

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

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

>
> 1. Таблицами (переходом, терминальный и нетерминальных символов
> и прочей другой лабуденью)

таблицами переходов, терминальных и нетерминальных символов