Лет пять назад реализовал декомпилятор байт кода Firebird процедур /ну надо было. Процентов на 98 позволяет получить исходник. Большего мне и не нужно было/.
Их байт код - обратная польская запись.
да задача то весьма узко-специфичная - для одной крайне-специфичной субд нужен какойнить человекочитаемый язык запросов при этом безопасно ограниченный по функционалу, поддерживающий только следующие базовые принципи - логические операторы OR и AND, любая вложенность без ограничений, и собственно передача какой ключ с каким значением сравнивать и каким образом (== или != пока достаточно). При этом запрос может быть передан не по сети, а вызовом соответствующего метода если система импортирована в чьето приложение.
но при таком подходе нужен довольно тяжелый (при нагрузке) механизм отслеживания циклических ссылок внутри запроса.
поэтому появилась мысль использовать текстовый формат, а чтобы быстро это дело парсить - польская нотация. И внезапно готового конфигурируемого парсера польки под это дело мне не попалось.
Парсер RPN - это str.split. Что тебе в нём не хватает?
А вообще интересно зачем RPN мог вообще кому-то понадобиться. Как вариант этого вопроса, почему RPN использовали в RRDTool вместо нормальных выражений. По мне так сейчас RPN нужен только чтобы детей учить на первых уроках программирования, когда скобки им ещё сложно (что, вообще, спорно), а для практического применения готовых парсеров чего угодно, используемых одной строчкой, вагон и тележка.
В SQLite имеется https://www.sqlite.org/vtab.html.
Если кратко - можно разработать SQL запросы к различным наборам данных.
Например для себя реализовал возможность выполнения SQL запросов к DBF, использующих CDX файлы /обеспечено использование CDX на все 100/.
извиняюсь, а причем тут sqlite? субд другая, даже не sql-like и даже не реляционка. прикрутить сюда sqlite будет ох как непросто :)
Вы ничего не поняли.
Еще раз акцентирую использование API virtual table позволит вам реализовать возможность выполнения SQL запросов к любому типу данных /даже обычным текстовым файлам/.
да задача то весьма узко-специфичная - для одной крайне-специфичной субд нужен какойнить человекочитаемый язык запросов
Ну так напиши сперва этот язык запросов.
А то, ты пытаешься без начального понимания своего языка запросов положить его на конкретные реализации: скобочный json и бескобочную польскую нотацию.
нужен довольно тяжелый (при нагрузке) механизм отслеживания циклических ссылок внутри запроса.
Это семантическая деталь реализации твоего языка не решается присутствем или отсутствием скобок в языке описания. Ты пытаешься сделать то, чего сам не понимаешь.
Уверены? У меня в голове SQL както плохо укладывается на графовые субд с совершенно иной моделью запросов. А если оставить от sql только крошечный кусочек - то зачем он нужен, это ведь дизориентирует.
Речь не про удобное представление, а про то, что ты поставил перед фактом, что ты уже выбрал обратную польскую нотацию. А нам надо придумать оправдание твоему выбору, предоставивь быстрый парсер (который проще написать самому), и вписавь его в твой язык запросов (который мы не знаем).
Особенно позабавил «механизм отслеживания циклических ссылок», который не про язык запросов, а про внутреннее представление данных.
На счет твоего json-примера. Польская нотация предполагает, что ты заранее знаешь количество операндов у оператора. Придется придумывать одинаковые операторы разной арности and2, and3,..., andN, или придумывать метки начала(конца) операторов, аналоги скобок.
что за субд сказать не могу, а почему другие не устроили - другие это какие? не-графовые? ну дык иной концепт совершенно, инструмент по задаче. или другие графовые? дак монопенисуально же.
я гляну как будет время, спасибо. но всеравно пока плохо представляю себе сие соитие - хотябы потому, что при попытке натянуть термины реляционки на графовую у меня выходит, что каждая строка в таблице сама является таблицей - в нее может быть вложена произвольная(ну ок, ограниченная схемой) иерархия других таблиц.
ну метки начала-конца итак нужны, чтобы все это было удобно читать и писать.
Особенно позабавил «механизм отслеживания циклических ссылок», который не про язык запросов
согласен, да. технически этот механизм на этапе выполнения запроса у меня есть, но он дает неприятный оверхед по памяти, посему подефолту пока отключен. если удастся избавиться от него, выбрав иное представление для языка запросов (в котором впринципе не может быть ссылок) - будет здорово.
ты поставил перед фактом, что ты уже выбрал обратную польскую нотацию который не про язык запросов, а про внутреннее представление данных