Компилятор регулярного выражения

1) Perl разрешает /x включите регулярные выражения, чтобы позволить комментариям и пробелу быть включенными в самом regex. Это позволяет распространить комплекс regex по нескольким строкам, с помощью добавления отступа для указания на блочную структуру.

2) Если Вам не нравятся сами напоминающие шум в линии символы, не слишком трудно записать Вашим собственным функциям ту сборку регулярные выражения. Например, в Perl:

sub at_start { '^'; }
sub at_end { '$'; }
sub any { "."; }
sub zero_or_more { "(?:$_[0])*"; }
sub one_or_more { "(?:$_[0])+"; }
sub optional { "(?:$_[0])?"; }
sub remember { "($_[0])"; }
sub one_of { "(?:" . join("|", @_) . ")"; }
sub in_charset { "[$_[0]]"; }       # I know it's broken for ']'...
sub not_in_charset { "[^$_[0]]"; }   # I know it's broken for ']'...

Затем, например, regex для соответствия заключенной в кавычки строке (/^"(?:[^\\"]|\\.)*"/) становится:

at_start .
'"' .
zero_or_more(
    one_of(
        not_in_charset('\\\\"'),    # Yuck, 2 levels of escaping required
        '\\\\' . any
    )
) .
'"'

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

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

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

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

Что относительно пишут им с Regex Buddy и вставляют описание, которое это генерирует как комментарий к Вашему коду?

Регулярные выражения (хорошо, "реальные" регулярные выражения, ничего подобного современный материал;) конечные автоматы. Поэтому Вы создаете синтаксис, который описывает регулярные выражения с точки зрения состояний, краев, входа и возможно выходных маркировок. fsmtools AT&T поддерживают что-то как этот, но они далеки от инструмента, готового к повседневному использованию.

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

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

Существуют способы сделать REs в их обычной форме более читаемым (такой как жемчуг /x синтаксис), и несколько намного более многословных языков для выражения их. См.:

• https://stackoverflow.com/questions/263072/why-are-regular-expressions-such-a-complicated-cryptic-mess
• Почему люди защищают regex синтаксис?

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

Нет никакой фундаментальной причины, которую Вы не могли записать компилятору для многословного языка РЕ, предназначающегося для компактного, но я не вижу большого преимущества в нем. Если Вам нравится многословная форма, просто используйте ее.

"Модель содержания XML-схемы" является примером того, что Вы хотите.

c(a|d)+r

может быть выражен как модель содержания в XML-схеме как:

<sequence>
 <element name="c" type="xs:string"/>
 <choice minOccurs="1" maxOccurs="unbounded">
  <element name="a" type="xs:string"/>
  <element name="d" type="xs:string"/>     
 </choice>
 <element name="r" type="xs:string"/>
<sequence>

Ослабьтесь NG имеет другой способ выразить ту же идею. Это не должен быть сам формат XML (Ослабьтесь, NG также имеет эквивалентный синтаксис не XML).

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

Вы рассмотрели использование парсера-генератора (иначе компилятор компилятора), такой как ANTLR?

ANTLR также имеет некоторый IDE (Работы ANTLR), где можно визуализировать/отлаживать синтаксические анализаторы.

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

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

Одним путем Вы можете передачей, которая эта проблема при помощи программ как QuickREx, это показывает, как regex работает над несколькими данными тестирования (с выделениями). Вы могли сохранить текстовые данные в файле около Вашего regex и последний, когда Вы хотите изменить его, понять его или зафиксировать его, который был бы намного легче.

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

Что-то, что Вы не упоминаете в своем сообщении, но которое является почти как плохо, то, что почти у каждого языка, редактора или инструмента есть своя собственная вариация на regexp синтаксис. Некоторые из них поддерживают синтаксис POSIX, поскольку он был определен столько лет назад, некоторый синтаксис Perl поддержки, как это сегодня. Но у многих есть их собственные независимые способы выразить вещи, или какие символы являются "особенными" (специальные символы другая тема), и которые не являются. Чего оставляют и что не. И т.д. Мало того, что трудно считать regexp, записанный для одного языка или инструмента, но даже если Вы полностью запоминаете синтаксические правила для своего любимого изменения, они могут сбить Вас с толку на другом языке, где {2,3} больше средства, что Вы ожидаете. Это - действительно путаница.

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

Так, для ответа на вопрос я часто думал о создании некоторого межплатформенного, межъязыкового, перекрестное все библиотека, которая позволила бы Вам "переводить" из любого regexp синтаксиса (быть этим Perl, или POSIX или Emacs, и т.д.) в любой другой regexp синтаксис. Так, чтобы Вы не должны были бы волноваться, мог ли Python regexps сделать отрицательный, оглядываются, или если скобок класса символов нужно оставить в Emacs regexp. Вы могли просто запомнить один синтаксис, затем сделать вызов функции вынуть эквивалентный синтаксис для того, что Вы, оказалось, использовали.

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

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

компилятор регулярного выражения:

ftp://reports.stanford.edu/pub/cstr/reports/cs/tr/83/972/CS-TR-83-972.pdf