LINUX.ORG.RU

История изменений

Исправление den73, (текущая версия) :

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

Мне не нравятся регекспы чем?

1. У них нет стандарта, поэтому в каждой новой среде приходится мучаться с нюансами и читать гигантские мануалы. Вот пример, чем реализация регекспов для лиспа отличается от таковой для перла

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

3. Они являются средством создания парсеров, причём сложным. Сложно то, что парсер может быть жадным и не жадным. Ставим рядом несколько жадных и не жадных и я уже ничего не понимаю. Если вы понимаете - я за вас рад.

4. Они состоят из кучи спец-значков. Если нужно вписать регэксп в командной строке, или в строковом литерале, или преобразовать из одного языка в другой, возникают заросли из обратных кавычек. Да, можно набить руку, но можно и задаться вопросом: а ради чего такие муки?

5. В обычной жизни всегда есть «отладка принтами». Вставь одну букву в регэксп - и это уже тот регэксп. Но в языке программирования регэкспов нет команды «напечатай в stderr», нужно сильно менять тот код, к-рый вызывает этот регэксп. Есть программы типа regexbuddy Но если пользуешься внешней программой, может быть всё равно не так легко решить вопрос «а почему эта сука в моём гигабайте находит только 180 вхождений из 200», ведь нужно же ещё и подсунуть ей именно мои данные, а для этого нужна именно трассировка в боевом окружении, а не сторонняя программа.

В общем, регэкспов в ближайшей версии Яра не будет. Видимо, для компенсации их отсутствия нужна какая-то библиотека для генерации парсеров, но более удобная, чем регулярки.

В Allegro был вариант человекочитемых регулярок.

Почему только в аллегро? А в cl-ppcre разве не то?

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

strlcpy & strlcat - обожаю эту парочку!

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

А зачем именно маленькая? Не является ли целью сделать работу со строками удобной?

Является целью выдать версию ранее, чем меня отнесут на кладбище.

Яр — это то, что раньше было «кодица»?

Да, подправь свой список.

left-pad

Спасибо. Прекрасная библиотека и прекрасная история. Правда, парень зря дал слабину. Не знаю, как я бы поступил на его месте, но он по сути струсил, испугался слова «юрист». Не надо было так делать. Может, они бы и не прислали к нему юристов, да юристы и не киллеры, может он бы и отбрехался от них как-то. Круги на воде быстро разойдутся, а имя он потерял.

ИТАК, пока что проект API выглядит так:

1. Как-то преобразовать в строку 
2. Аналог format, printf и пр. Хотя в лиспе формат тоже 
какой-то криптографический и страдает теми же недостатками,
что и регулярки. У меня была библиотечка вывода, когда 
строится дерево cons-ов, содержащее команды, а потом дерево
выводится. Медленнее, зато более человечно.

3. Функции из 1С (названия вряд ли уцелеют)

СокрЛП, Лев, Прав, Сред, "подстрока по номерам справа", СтрДлина 
(а вот мне почему-то не нравится "строка".Длина
, почему - не могу понять, но может быть и сойдёт). 

найти букву в строке по предикату, возвращая найденную букву или её смещение. 

ВРег, НРег, trim-left, trim-right, pad-left, pad-right .

Поток вывода в строку (with-output-to-string)

split (аналог перлового или split-sequence:split-sequence из лиспа)

заменить кусок текста от и до на такой-то иной кусок. 

поиск с заменой, можно передавать ему предикат для сравнения букв. 

операции конкатенации:

♥ - конкатенация только строк
♥♥ - преобразование в строку любых аргументов и конкатенация полученных строк

Преобразовать строку в односвязный список (а так строка в
лиспе это массив). 

Цикл по элементам строки. 
Цикл по подстрокам строки, битой по предикату (например,
 по литере конца строки)

Пока что дыра в том месте, где регулярные выражения и scanf. Для этой цели, я думаю, нужно проэкспортировать те парсеры, к-рыми я разбираю сам Яр. Это метод рекурсивного спуска с возможностью установки временных закладок (часть потока от самой ранней действительной закладки кешируется в памяти), а также PEG, плюс набор примитивов типа «прочитать число». Опять же, это будет не особо быстро.

Ну и очень удобно работать в программируемом текстовом редакторе, где можно ставить марки (теги) на текст, к-рые ездят после изменений текста. Т.е. можно сначала всё разметить, а потом менять, и марки будут сами ездить. Опять же это может быть медленно, зато очень удобно. Может быть, нужно сделать какой-то объект «буфер с марками», более легковесный, чем буфер редактора.

Извините, много букв получилось, и я уже устал :(

Исправление den73, :

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

Мне не нравятся регекспы чем?

1. У них нет стандарта, поэтому в каждой новой среде приходится мучаться с нюансами и читать гигантские мануалы. Вот пример, чем реализация регекспов для лиспа отличается от таковой для перла

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

3. Они являются средством создания парсеров, причём сложным. Сложно то, что парсер может быть жадным и не жадным. Ставим рядом несколько жадных и не жадных и я уже ничего не понимаю. Если вы понимаете - я за вас рад.

4. Они состоят из кучи спец-значков. Если нужно вписать регэксп в командной строке, или в строковом литерале, или преобразовать из одного языка в другой, возникают заросли из обратных кавычек. Да, можно набить руку, но можно и задаться вопросом: а ради чего такие муки?

5. В обычной жизни всегда есть «отладка принтами». Вставь одну букву в регэксп - и это уже тот регэксп. Но в языке программирования регэкспов нет команды «напечатай в stderr», нужно сильно менять тот код, к-рый вызывает этот регэксп. Есть программы типа regexbuddy Но если пользуешься внешней программой, может быть всё равно не так легко решить вопрос «а почему эта сука в моём гигабайте находит только 180 вхождений из 200», ведь нужно же ещё и подсунуть ей именно мои данные, а для этого нужна именно трассировка в боевом окружении, а не сторонняя программа.

В общем, регэкспов в ближайшей версии Яра не будет. Видимо, для компенсации их отсутствия нужна какая-то библиотека для генерации парсеров, но более удобная, чем регулярки.

В Allegro был вариант человекочитемых регулярок.

Почему только в аллегро? А в cl-ppcre разве не то?

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

strlcpy & strlcat - обожаю эту парочку!

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

А зачем именно маленькая? Не является ли целью сделать работу со строками удобной?

Является целью выдать версию ранее, чем меня отнесут на кладбище.

Яр — это то, что раньше было «кодица»?

Да, подправь свой список.

left-pad

Спасибо. Прекрасная библиотека и прекрасная история. Правда, парень зря дал слабину. Не знаю, как я бы поступил на его месте, но он по сути струсил, испугался слова «юрист». Не надо было так делать. Может, они бы и не прислали к нему юристов, да юристы и не киллеры, может он бы и отбрехался от них как-то. Круги на воде быстро разойдутся, а имя он потерял.

ИТАК, пока что проект API выглядит так:

1. Как-то преобразовать в строку 
2. Аналог format, printf и пр. Хотя в лиспе формат тоже 
какой-то криптографический и страдает теми же недостатками, что и регулярки. У меня была библиотечка вывода, когда 
строится дерево cons-ов, содержащее команды, а потом дерево 
выводится. Медленнее, зато более человечно.

3. Функции из 1С (названия вряд ли уцелеют)

СокрЛП, Лев, Прав, Сред, "подстрока по номерам справа", СтрДлина (а вот мне почему-то не нравится "строка".Длина
, почему - не могу понять, но может быть и сойдёт). 

найти букву в строке по предикату, возвращая найденную букву или её смещение. 

ВРег, НРег, trim-left, trim-right, pad-left, pad-right .

Поток вывода в строку (with-output-to-string)

split (аналог перлового или split-sequence:split-sequence из лиспа)

заменить кусок текста от и до на такой-то иной кусок. 

поиск с заменой, можно передавать ему предикат для сравнения букв. 

операции конкатенации:

♥ - конкатенация только строк
♥♥ - преобразование в строку любых аргументов и конкатенация полученных строк

Преобразовать строку в односвязный список (а так строка в
лиспе это массив). 

Цикл по элементам строки. 
Цикл по подстрокам строки, битой по предикату (например,
 по литере конца строки)

Пока что дыра в том месте, где регулярные выражения и scanf. Для этой цели, я думаю, нужно проэкспортировать те парсеры, к-рыми я разбираю сам Яр. Это метод рекурсивного спуска с возможностью установки временных закладок (часть потока от самой ранней действительной закладки кешируется в памяти), а также PEG, плюс набор примитивов типа «прочитать число». Опять же, это будет не особо быстро.

Ну и очень удобно работать в программируемом текстовом редакторе, где можно ставить марки (теги) на текст, к-рые ездят после изменений текста. Т.е. можно сначала всё разметить, а потом менять, и марки будут сами ездить. Опять же это может быть медленно, зато очень удобно. Может быть, нужно сделать какой-то объект «буфер с марками», более легковесный, чем буфер редактора.

Извините, много букв получилось, и я уже устал :(

Исходная версия den73, :

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

Мне не нравятся регекспы чем?

1. У них нет стандарта, поэтому в каждой новой среде приходится мучаться с нюансами и читать гигантские мануалы. Вот пример, чем реализация регекспов для лиспа отличается от таковой для перла

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

3. Они являются средством создания парсеров, причём сложным. Сложно то, что парсер может быть жадным и не жадным. Ставим рядом несколько жадных и не жадных и я уже ничего не понимаю. Если вы понимаете - я за вас рад.

4. Они состоят из кучи спец-значков. Если нужно вписать регэксп в командной строке, или в строковом литерале, или преобразовать из одного языка в другой, возникают заросли из обратных кавычек. Да, можно набить руку, но можно и задаться вопросом: а ради чего такие муки?

5. В обычной жизни всегда есть «отладка принтами». Вставь одну букву в регэксп - и это уже тот регэксп. Но в языке программирования регэкспов нет команды «напечатай в stderr», нужно сильно менять тот код, к-рый вызывает этот регэксп. Есть программы типа regexbuddy Но если пользуешься внешней программой, может быть всё равно не так легко решить вопрос «а почему эта сука в моём гигабайте находит только 180 вхождений из 200», ведь нужно же ещё и подсунуть ей именно мои данные, а для этого нужна именно трассировка в боевом окружении, а не сторонняя программа.

В общем, регэкспов в ближайшей версии Яра не будет. Видимо, для компенсации их отсутствия нужна какая-то библиотека для генерации парсеров, но более удобная, чем регулярки.

В Allegro был вариант человекочитемых регулярок.

Почему только в аллегро? А в cl-ppcre разве не то?

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

strlcpy & strlcat - обожаю эту парочку!

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

А зачем именно маленькая? Не является ли целью сделать работу со строками удобной?

Является целью выдать версию ранее, чем меня отнесут на кладбище.

Яр — это то, что раньше было «кодица»?

Да, подправь свой список.

left-pad

Спасибо. Прекрасная библиотека и прекрасная история. Правда, парень зря дал слабину. Не знаю, как я бы поступил на его месте, но он по сути струсил, испугался слова «юрист». Не надо было так делать. Может, они бы и не прислали к нему юристов, да юристы и не киллеры, может он бы и отбрехался от них как-то. Круги на воде быстро разойдутся, а имя он потерял.

ИТАК, пока что проект API выглядит так:

1. Как-то преобразовать в строку 
2. Аналог format, printf и пр. Хотя в лиспе формат тоже какой-то криптографический и страдает теми же недостатками, что и регулярки. У меня была библиотечка вывода, когда строится дерево cons-ов, содержащее команды, а потом дерево выводится. Медленнее, зато более человечно.

3. Функции из 1С (названия вряд ли уцелеют)

СокрЛП, Лев, Прав, Сред, "подстрока по номерам справа", СтрДлина (а вот мне почему-то не нравится "ываыва".Длина, почему - не могу понять, но может быть и сойдёт). 

найти букву в строке по предикату, возвращая найденную букву или её смещение. 

ВРег, НРег, trim-left, trim-right, pad-left, pad-right .

Поток вывода в строку (with-output-to-string)

split (аналог перлового или split-sequence:split-sequence из лиспа)

заменить кусок текста от и до на такой-то иной кусок. 

поиск с заменой, можно передавать ему предикат для сравнения букв. 

операции конкатенации:

♥ - конкатенация только строк
♥♥ - преобразование в строку любых аргументов и конкатенация полученных строк

Преобразовать строку в односвязный список (а так строка в лиспе это массив). 

Цикл по элементам строки. 
Цикл по подстрокам строки, битой по предикату (например, по литере конца строки)

Пока что дыра в том месте, где регулярные выражения и scanf. Для этой цели, я думаю, нужно проэкспортировать те парсеры, к-рыми я разбираю сам Яр. Это метод рекурсивного спуска с возможностью установки временных закладок (часть потока от самой ранней действительной закладки кешируется в памяти), а также PEG, плюс набор примитивов типа «прочитать число». Опять же, это будет не особо быстро.

Ну и очень удобно работать в программируемом текстовом редакторе, где можно ставить марки (теги) на текст, к-рые ездят после изменений текста. Т.е. можно сначала всё разметить, а потом менять, и марки будут сами ездить. Опять же это может быть медленно, зато очень удобно. Может быть, нужно сделать какой-то объект «буфер с марками», более легковесный, чем буфер редактора.

Извините, много букв получилось, и я уже устал :(