LINUX.ORG.RU

Поиск языка программирования.


0

0

Что наиболее похожее на нижеописанный язык вы можете вспомнить?

Это похоже на regexp-ы. Основная цель - находить шаблоны. Но работает немного умнее regexp-ов, позволяя создавать переменные, сравнивать их с чем-то и т.п. Для ясности - пример:

Есть тексты: «abcdef», «abcddeeff»

Программа на таком языке:

a, b, c, d, f, $X="OK", $CODE=33

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

В конце стоят два специальных оператора - создание двух переменных, присваивание им чего-то. До них дело доходит по вышеописанной логике - если все предыдущие операторы успешно «пройденены» (соотв. символы найдены). Т.е., если текст будет не «abcdef», то переменные $X и $CODE созданы не будут.

Оператор ИЛИ:

(a,b,c) || (w,d,x) || (g,p,o,x,a), $X = 1

Три последовательности через ИЛИ. Делаются три попытки поиска разных последовательностей с одного места в тексте. Три последовательности, разделённые ИЛИ - это один оператор, далее запятая и второй - «$X=1». Смысл - нашли хотябы одну из них - перейдём к выполнению следующего, который создаёт переменную. Не нашли ничего, до $X дело не дойдёт.

Программа посложнее:

a, b ,c, (d, f, $CODE=1, $X=55) || ( d,d,e,e,f,f,$CODE=2, $X=66), ( $CODE == 1, $TEXT="Hello world" ) || ( 2 == $CODE, $TEXT = "mama, mama, chto ya budu delat" )

В зависимости от вида строки, создаётся разная переменная $CODE, и в зависимости от неё, переменная $TEXT имеет разное содержимое. Все программы тут дурацкие, решаются уже имеющимися во вселенной средствами, конечно. Но интересно узнать, существуют ли подобные «языки», работающие по подобной логике - «прохождение» последовательности операторов, зависящее от нахождения их во входной последовательности или от результатов выполнения условных операторов...

Спасибченко!

Либо написать свой...

ma1uta ★★★
()

существуют ли подобные «языки»

Да, существуют. Называются «парсер-комбинаторы». Представляют из себя embedded domain specific language (eDSL), т.е. встроенный мини-язык в виде библиотеки. Из известных мне существуют разновидности для Haskell (parsec), F# (fparsec) и Scala (scala.util.parsing.combinator). Вероятно, что-то есть готовое для OCaml.

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

dave ★★★★★
()

Это похоже на regexp-ы. Основная цель - находить шаблоны. Но работает немного умнее regexp-ов, позволяя создавать переменные, сравнивать их с чем-то и т.п.

Perl. Идеальная для него ниша.

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

>Да, существуют. Называются «парсер-комбинаторы»

необязательно парсер-комбинаторы (как реализация, хотя по сути похоже).

РЕФАЛ http://ru.wikipedia.org/wiki/РЕФАЛ — это вот что?

OMeta — http://tinlizzie.org/ometa/ http://lambda-the-ultimate.org/node/2477 — язык поверх PEG
или «π: a pattern language» http://lambda-the-ultimate.org/node/3662

-- это вот почти что ТС искал.

Как применение: http://news.ycombinator.com/item?id=846028 http://www.moserware.com/2008/04/towards-moores-law-software-part-3-of-3.html — TCP/IP стек в 200 строк на DSL

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

>flex

Не, lex/flex и yacc/bison не катят — в условии написано $CODE=правило, чего flex не умеет, умеет только $1, $2, ..., $CODE=токен

Можно взять ANTLR, там с этим погибче.

1. Пишем простенькую грамматику на ANTLR => автоматически получаем AST.
2. Пишем простенький транслятор с этой грамматикой: .toStringTree() => получаем на выходе Lisp-подобное представление в терминах токенов языка (правда, человекоНЕчитаемое, pretty printing-ом тут и не пахло).
3. Пишем макросы для такого представления, которые будут раскрываться в полноценный Common Lisp/Scheme/whatever => получаем исполняемый код, который можно скормить лисп-компилятору.

В итоге, минимум возни, и написали «компилятор своего языка».
Я так сделал for fun для Си-компилятора — правда, фибоначчи лисп считает медленнее скомпилированной gcc программы. Нужно аннотировать типы в лисп-программе, избавляться от BIGNUM-ов в пользу FIXNUM-ов, профилировать лисп-код, что там пришло в голову конкретной лисп-реализации. В первом приближении разница с gcc/sbcl составила 10%, для начала неплохо.

Исчо, gUnit в ANTLR весьма полезен.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.