1) не нравится, как работает оператор s/.../.../
например, выражение s/(а)(б)(в)/$1 $2 $3/ - раставляет пробелы между абв. Но если (б) в строке нет, то, соответственно, на месте $2 находится символ "в". Как-то нелогично. Имно нужно, чтобы если (б) нет, то чтобы и $2 - не было.
.
А какие конструкции вам не нравятся, и что бы вы хотели добавить в регекспы? 

Это сообщение отредактировал(а) Suppir - 13.5.2009, 16:43

странное пишете.

# perl -le '$a = "abc"; $a =~ s#(a)(b)©#$1 $2 $3#; print $a; $a = "ac"; $a =~ s#(a)(b)©#$1 $2 $3#; print $a'
a b c
ac
#

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

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

ага, диапазоны чисел пожалуй круто будет.. я бы еще предложил возоможность вставки предикатов на perl в регулярки
... что бы например поиск числа < 515 выглядел так


Внимание: это невалидный код, всего лишь пожелание.

\b(?:[0-4]\d\d|50\d|51[0-5]|\d?\d)\b, не оно?

Модификатор нечеткого поиска? Например, строка ABCD, 
регулярка /(?1:ABBD)/ - вроде "одна любая буква может не совпадать". 

(?:.BBD|A.BD|AB.D|ABB.) ?

Оно. но оно вам самим нравится ?  Хотя это классика..

Вообщем что бы вот таких конструкиций не писать я и хотел перловые предикаты.

arto, ну а если "5 букв могут не совпадать"? Перебирать все варианты в регулярном выражении очень сложно (и длинно). Было бы удобней, если такая фича на уровне механизма присутствовала. Конечно, поиск с таким модификатором будет медленный. И еще будет несколько ответов разной релевантности.
.
Еще вариант:
/<я> <люблю> <Perl>/
Хочу чтобы для слова в угловых скобках работали любые синонимы, с любыми окончаниями. Представляете как будет удобно? 

/<make me happy>/ && exit;

/make arto happy/ or die 'trying =)' ;

А еще чтобы они кофе умели готовить ;)

 
  заведите жену, она мнооого что умеет делать. Ее просто иногда нужно кормить 

Это сообщение отредактировал(а) shamber - 15.5.2009, 10:30

Ну а что там сложного в синонимах?
допустим слово "кошка" можно представить в современном синтаксисе как $cat='ко(шка|т|тенок)';
m/$cat/;
 и т.п.  

Добавлено через 1 минуту и 42 секунды
Только сделать обращение к библиотеке синонимов не через переменную, а на уровне синтаксиса. Библиотеку распространять модулем. Наверное, что-то подобное есть уже

Добавлено через 3 минуты и 42 секунды
<кошка>  - синонимы
<?!кошка> - антонимы
<!кошка> - синонимы кроме самого слова "кошка"

perldoc re::engine::Suppir ?

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

по-вашему, вся программа должна состоять из одного, средних размеров регулярного выражения?
("make me happy" рассматриваем как эктремальный вырожденный случай, к которому надо стремиться).

arto, мне кажется, нужно стремиться к более высокоуровневому представлению. 
Чтобы не пришлось описывать все варианты руками. Имхо это может дать Perl новую жизнь.
.
1) например, если у меня в регулярном выражении /кошка/, я хочу, чтобы слово "кошка" нашлось и в ANSI и DOS и в UNICODE кодировках (чтобы регулярное выражение для юникода было таким же как и для других кодировок)
2) нечеткий поиск, например /?2:конституция/ - любые две буквы могут не совпадать
3) поддержка синонимов. Имхо это очень крутая фича, особенно для поиска-замены.
4) автоматическая упаковка набора из регулярных выражений. Например, у меня для разбора текста написаны 200 регулярок. Из них большинство пересекаются (есть одинаковые конструкции). Соответственно, их можно преобразовать в один автомат, и очистить от повторяющихся (лишних) состояний. Это значительно ускорит поиск. 


Это сообщение отредактировал(а) Suppir - 15.5.2009, 15:19

1. проще все привести все данные к одной кодировке. каким автоматом вы распознаете koi8-r, cp1251 и iso-8859-1 ?
2. проще выделить слово и самому проверить его.
3. пример?
4. типа ORM, который perl-код переводит в sql, от которого плачут dba?

to arto:
1. 
Допустим, у меня данные в cp866 (dos), cp1251 (ansi) и unicode. Я хочу написать одно регулярное выражение, и чтобы оно работало в любой кодировке. Первые две похожи, но регулярка для юникода делается иначе.

2. 
Фразу "Интернет-сайт" могут написать так: "Интернет-сайт", "интернет сайт" и так далее. Достаточно набрать /(?3:интернет сайт)/ - и регулярка найдет все возможные варианты. А если написать s/(?3:интернет сайт)/интернет сайт/, то Perl преобразует варианты к одному виду.

Другой пример - поиск текста с ошибками и опечатками. Слово может быть набрано "Итернет-сайт", "презедент", "инструция" - как вы его найдете обычным регулярным выражением? Никак.
Еще пример - ошибка распознавания при сканировании. Вместо какой-нибудь буквы может быть цифра (о - 0, 1 - i), вместо кириллической буквы латинская (o - о, p - р). В шаблоне вы ведь не сможете учесть все варианты ошибок. А с нечетким поиском достаточно ввести правильный шаблон и максимальное допущение.


3. Например, я хочу найти все документы 2009 года:
/\d{1,2} мая 2009 года/    - найдутся и "мая" и "апреля" и "июня"
также исключение лишних синонимов из текста:
замена слов одно на другое с учетом окончаний (вы ведь не будете вручную все окончания перебирать)
и так далее. 

1. пример -- "опхбер", это в какой кодировке? откуда perl узнает кодировку?

2. /интернет[\s-]+сайт/i, не подойдет?

угу, как сделать в слове из 3 букв 4 ошибки? грамотность написание -- проблема не perl, а средней школы.

3. а "февраль" не найдется? а почему? а "maaliskuu"? а почему?

ps. семимильными шагами идем к /<make me happy>/ :)

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

полагаю, неграмотность российских чиновников должна волновать их начальство, а не разработчиков perl.

К сожалению, начальников это мало волнует :( 
Приходится перелопачивать весь текст - искать ошибки, приводить к единому виду. Юзаю (в основном) архивариус 3000, powergrep и perl. Архивариус - для поиска с поддержкой морфологии, powergrep - для пакетных фильтров и замен в тексте, а Perl - как универсальный инструмент для сложных случаев. 
Вот эти вышеперечисленные фичи Perl принесли бы огромную пользу, по крайней мере в моей работе  
Наверное, их не так просто реализовать, хотя, я, кажется, видел модуль нечеткого поиска на CPAN...

Это сообщение отредактировал(а) Suppir - 15.5.2009, 17:07

большинство, если не все, заточены под английский язык.
а левенштейн вам, imho, не очень поможет.

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

Если кто знает софтину для поиска/замен со следующими функциями:

1) поиск/замена в .doc, .pdf, поддержка юникода
2) регулярные выражения Perl (PCRE)
3) поиск (и замена) с учетом морфологии (русский язык)
4) поиск орфографических, пунктуационных ошибок
5) возможность создавать и редактировать коллекции фильтров 
6) поддержка нечеткого поиска

то дайте знать 

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

Учет языка это скорее удел библиотек, а не ядра. Запихать туда множество языков мира, плюс различные профессиональные сленги не реально 
Где-то видел платную Perl/PHP либу для поиска с учетом морфологии.

Это как такое реализовать ?

В книге у Фридла писалось

sample.pl


regexaddon.pm


О плохом, самое плохое нельзя будет использовать интерполяцию переменной внутрь конструкции, например \fd{<$numeric}.
Еще нельзя будет использовать новую конструкцию в строке, которая интерполируется в регулярное выражение, можно только в конструции qr//;

Это банальное переписывание регулярки. Меня интересует встраивание этого в движок + открытие доступа к внутренним переменным движка. 

А так - это не многим  круче, чем source filters

Я и говорю, встроенная в движок конструкция быстрее работать будет, + нет ограничений.