А кто-нибудь пробовал написать СУБД?

[MIT]

Нет. По второму нашел кучу теории, время будет - почитаю, а по первому быстрый поиск по Яндексу умного много не выявил, так, по мелочи.

[SLIM]

Гениально. Такое описание языка называется грамматикой. (Она может быть рекурсивной и в этом принципиально сложнее регэкспа.)
Для грамматик есть стандартные форматы, и есть "общепринятые" тулзы, которые по грамматике генерируют парсер.

Парсер сам по сути состоит из синтаксического\грамматического анализатора...например сначала можно проверять ситаксис, потом грамматику....или наоборот. Тут на самом деле гениального то ничего нет (или это ты меня так подколол?)

По поводу рекурсии....там вообще очень сложно. Начиная от построения деревьев заканчивая....хз чем

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

А недо-компилятор недо-

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

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

Уверяю, там всё гораздо интереснее, чем в типичных дилетантских поделках из Split/Mid, вороха условий, и рулона изоленты, чтобы всё не развалилось.
Это я к тому, что написание парсера стоит начинать с теории.

Я сначала тоже думал что все только в работе со строками....ан нет. Там действительно интересная область.

Теорию же я изучать начал еще месяц назад. Первой мне попалась книжка "Синаксический анализатор" изданная...внимание.....в 1985 г. Там даже примеры на паскале есть. Но ценна она свое теорией посторения алгоритмов (к сожалению тогда не было слова парсинг, и применялось аналогичное ему синаксический анализ)

Дело в том, что многие языки настолько сложны (в плане грамматики), что не могут быть описаны такими вот правилами. А то, что описываешь ты, по сути — регулярные выражения.

Вот только недавно я наткнулся на регулярные выражения и понял что это то же самое (почти)

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

Ну это только пример был ведь. С те же select куча вариантов (и ты ихперечислил). Просто первое что пришло на ум...

Разбиение — это очень сложно. Чтобы правильно разбить, нужно обработать полностью.

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

Вот например VB-код. Чтобы разбить его на statement-ы, нельзя просто взять и сделать Split(..., vbCrLf). Во-первых, vbCrLf не всегда означает конец statement-а, если перед CRLF стоит символ _ , то данный CRLF не является концом Statement-а. Во-вторых, Statement заканчивается не только на CRLF, а ещё двоеточие может разделять statement-ы.

Предположим, у нас VB-шный сплит понимал бы рег. выражения. Но мы всё равно не могли бы заюзать (\r\n|:) в качестве разделителя. Потому что двоеточике не всегда однозначно делит два statement-а. Оно может быть элементом конструкции := (при передачи некоторых именованых аргументов), оно может быть концом метки, не говоря уже о том, что оно может находиться внутри строки.

Возвращаясь к CRLF, то там символ _ будет подавлять CRLF только в том случае, если это отдельный символ, а не часть идентификатора (например CallMe_ ).

Тут у меня мысли такие. В любом случае допустим пробелы есть. Первично можно разбить по пробелам. Потом пробовать проверять "орфографию". Например на тот же :=. Допустим "...select(a,b,c) from" Мы разделим на две части "select(a,b,c)" и "from". Где по правилу from-это kwd, а вот с первым будем работать - его мы разобьем тоже на kwd-ы - скобки, запятые, переменные и сам select.

По поводу например _ - тут нужно анализировать правый и левый токены от текущего. Если правый токен - "_", то его мы просто отбросим и будем анализировать дальше...

Ну это все так - наметки, сейчас совсем не до этого, поэтому ничего еще не подтверждено практикой...


В остальном - имея универсальный парсер, недалеко и до анализа синтаксиса, орфографии, лексики и т.д. своего компилятора например. Или например той же СУБД. Это уже 1\4. А я как говорил хотел бы диплом написать....

[tyomitch]

В остальном - имея универсальный парсер, недалеко и до анализа синтаксиса, орфографии, лексики и т.д. своего компилятора например. Или например той же СУБД. Это уже 1\4. А я как говорил хотел бы диплом написать....

Разница в том, что в продвинутых институтах свой компилятор -- это не диплом, а обязательная работа на зачёт по одному из курсов

Написать нормальный унипарсер всем форумом было бы весьма интересно

[SLIM]

Разница в том, что в продвинутых институтах свой компилятор -- это не диплом, а обязательная работа на зачёт по одному из курсов

Возможно. Я пока на первом курсе. Может и у меня будет

Написать нормальный унипарсер всем форумом было бы весьма интересно

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

[tyomitch]

Так что, начинай
Обсуждение уже есть.

Если будут предметные вопросы, охотно поддержу.

[SLIM]

Так что, начинай
Обсуждение уже есть.

Если будут предметные вопросы, охотно поддержу.

Ок, это очень хорошо.

Вот скачал твой eval. Сижу разбираюсь.

Начать нужно видимо с определений
1. Что такое парсер
2. Что такое эвалютар
3. Что такое КА
4. Что такое регулярные выражения

[tyomitch]

1. анализатор текста
2. вычислитель выражений
3. конечный автомат (см. учебник или вики)
4. способ задать язык, распознаваемый КА (см. учебник или вики)

3,4: каждому посвящён здоровый кусок теории. Я могу и сюда скопипастить, но не вижу в этом смысла.

[SLIM]

ыы, уже посмотрел

[Zenitchik]

Очень рекомендую книгу "Основы построения трансляторов" Ю.Г.Карпова. Купил со скуки, когда почитать было нечего, но теперь это моя настольная книга. Увы, не все пока освоил, но уверенно пишу КА, немного менее уверенно МП-автоматы и чую, что на верном пути.

Единственное что не понял - как проектировать язык. Все известные мне формы записи грамматик Хомского слишком громоздки, чтобы ими было удобно описывать синтаксис в процессе его (синтаксиса) разработки.

[SLIM]

Есть у меня такая книжка. Скоро начну читать.

и чую, что на верном пути.

А какой твой путь?

[Zenitchik]

Я имел в виду путь к освоению методов разработки формальных языков.

Вчера в ходе разработки очередного КА (состояний на 30) допер до следующих шагов:
1. Описание языка в формате расширенной нотации Бэкуса - Наура, только немного подробнее (если правые части продукций совсем не похожи - записывал в разные строки) - удобно делать в текстовом редакторе типа np++;
2. По нотации строил синтаксическую диаграмму - тут лучше ручки бумаги еще ничего не придумали;
3. По диаграмме - граф переходов;
4. По графу - писал код (помечая галочками узлы по мере их описания ).

UPD:
Жаль, не придумал, как граф переходов в коментарии засунуть Обошелся нотацией.

[tyomitch]

Жаль, не придумал, как граф переходов в коментарии засунуть Обошелся нотацией.

Картинку в base64 и в каменты


Серьёзно: в проект можно добавлять как related files хоть рисунки, хоть доки. При компиляции игнорируются. Вроде бы, именно для таких случаев нужная возможность.

[SLIM]

Люди а посвятите о чем вы. А то что-то я не въехал. Состояний "не въехал" бывает два
1) Не въехал
2) Не въехал вааще

У меня второе

[Zenitchik]

SLIM
Книжку почитай

[SLIM]

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