LINUX.ORG.RU

Ответ на: комментарий от anonymous

Лет пять назад реализовал декомпилятор байт кода Firebird процедур /ну надо было. Процентов на 98 позволяет получить исходник. Большего мне и не нужно было/.
Их байт код - обратная польская запись.

Вообщем ТС стек спасет /как и меня/.

Владимир

anonymous ()
Ответ на: комментарий от anonymous

да задача то весьма узко-специфичная - для одной крайне-специфичной субд нужен какойнить человекочитаемый язык запросов при этом безопасно ограниченный по функционалу, поддерживающий только следующие базовые принципи - логические операторы OR и AND, любая вложенность без ограничений, и собственно передача какой ключ с каким значением сравнивать и каким образом (== или != пока достаточно). При этом запрос может быть передан не по сети, а вызовом соответствующего метода если система импортирована в чьето приложение.

Сейчас у меня запросы это структура вида

{
   'or':[
      {'key':'label', 'value':'label1', 'match':'=='},
      {'and':[
         {'key':'label', 'value':'label2', 'match':'!='},
         {'or':[
            {'key':'from', 'value':'from1', 'match':'=='},
            {'key':'from', 'value':'from2', 'match':'=='},
            {'and':[
               {'key':'label', 'value':'label3', 'match':'!='},
               {'key':'from', 'value':'from3', 'match':'=='},
            ]},
            {'key':'label', 'value':'label4', 'match':'=='},
         ]},
      ]},
      {'key':'from', 'value':'from4', 'match':'=='},
      {'key':'from', 'value':'from5', 'match':'=='},
   ]
}

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

поэтому появилась мысль использовать текстовый формат, а чтобы быстро это дело парсить - польская нотация. И внезапно готового конфигурируемого парсера польки под это дело мне не попалось.

genryRar ★★ ()

Парсер RPN - это str.split. Что тебе в нём не хватает?

А вообще интересно зачем RPN мог вообще кому-то понадобиться. Как вариант этого вопроса, почему RPN использовали в RRDTool вместо нормальных выражений. По мне так сейчас RPN нужен только чтобы детей учить на первых уроках программирования, когда скобки им ещё сложно (что, вообще, спорно), а для практического применения готовых парсеров чего угодно, используемых одной строчкой, вагон и тележка.

slovazap ★★★★★ ()
Ответ на: комментарий от genryRar

На будущее.

В SQLite имеется https://www.sqlite.org/vtab.html.
Если кратко - можно разработать SQL запросы к различным наборам данных.
Например для себя реализовал возможность выполнения SQL запросов к DBF, использующих CDX файлы /обеспечено использование CDX на все 100/.

PS: Потрудитесь и - «Будете счастливы».

Владимир

anonymous ()
Ответ на: комментарий от anonymous

Sorry.

Если кратко - можно разработать SQL запросы к различным наборам данных.

Если кратко - можно разработать возможность выполнения SQL запросов к различным наборам данных.

Владимир

anonymous ()
Ответ на: комментарий от genryRar

извиняюсь, а причем тут sqlite? субд другая, даже не sql-like и даже не реляционка. прикрутить сюда sqlite будет ох как непросто :)

Вы ничего не поняли.

Еще раз акцентирую использование API virtual table позволит вам
реализовать возможность выполнения SQL запросов к любому типу данных /даже обычным текстовым файлам/.

Владимир

anonymous ()
Ответ на: комментарий от genryRar

прикрутить сюда sqlite будет ох как непросто :)

Боягус.
Можно прикрутить!
И можно будет к вашей «не реляционки» выполнять SQL запросы.

Владимир

anonymous ()
Ответ на: комментарий от genryRar

да задача то весьма узко-специфичная - для одной крайне-специфичной субд нужен какойнить человекочитаемый язык запросов

Ну так напиши сперва этот язык запросов.
А то, ты пытаешься без начального понимания своего языка запросов положить его на конкретные реализации: скобочный json и бескобочную польскую нотацию.

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

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

anonymous ()
Ответ на: комментарий от anonymous

Уверены? У меня в голове SQL както плохо укладывается на графовые субд с совершенно иной моделью запросов. А если оставить от sql только крошечный кусочек - то зачем он нужен, это ведь дизориентирует.

genryRar ★★ ()
Ответ на: комментарий от genryRar

речь про удобное представления для этого языка

Речь не про удобное представление, а про то, что ты поставил перед фактом, что ты уже выбрал обратную польскую нотацию. А нам надо придумать оправдание твоему выбору, предоставивь быстрый парсер (который проще написать самому), и вписавь его в твой язык запросов (который мы не знаем).
Особенно позабавил «механизм отслеживания циклических ссылок», который не про язык запросов, а про внутреннее представление данных.
На счет твоего json-примера. Польская нотация предполагает, что ты заранее знаешь количество операндов у оператора. Придется придумывать одинаковые операторы разной арности and2, and3,..., andN, или придумывать метки начала(конца) операторов, аналоги скобок.

anonymous ()
Ответ на: комментарий от genryRar

API virtual table предоставит вам возможность использовать ваши специфичные функции для доступа к данным.
Не утверждаю, что для вас это лучший путь.

Владимир

anonymous ()
Ответ на: комментарий от anonymous

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

genryRar ★★ ()
Ответ на: комментарий от anonymous

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

genryRar ★★ ()
Ответ на: комментарий от anonymous

или придумывать метки начала(конца) операторов

ну метки начала-конца итак нужны, чтобы все это было удобно читать и писать.

Особенно позабавил «механизм отслеживания циклических ссылок», который не про язык запросов

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


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

ясно-понятно..

genryRar ★★ ()
Ответ на: комментарий от genryRar

ну метки начала-конца итак нужны, чтобы все это было удобно читать и писать.

В обратной польской нотации не нужны такие метки. Ты не имеешь понятия про обратную польскую нотацию.

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

ясно-понятно..

Выдрал цитаты из разных абзацев, даже не предложений. Я не уверен, что ты можешь понимать написанное.
Дальнейший диалог не имеет смысла. Успехов.

anonymous ()