Яр - какие ф-ии работы со строками включить в стандартную библиотеку?

Иными словами, в каком языке самая лучшая (и при этом маленькая) библиотека работы со строками?

perl

javascript

а що там за библеотека

left-pad.

добавь регексп + свякую мелочь типа тримов и слайсов.

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

strlcpy & strlcat - обожаю эту парочку! жаль, что в линуксе их приходится велосипедить. а на многобайтовые кодировки пофиг, мне и английского хватает

BSD ed

В Allegro был вариант человекочитемых регулярок. И это наверное наверное практичнее чем 100 вариантов «взять эн буковок справа»
ну и sed уже придуман. Перепиши список команд и будет тебе счастье.

И это наверное наверное практичнее чем 100 вариантов «взять эн буковок справа»

Но наверное медленнее.

Иными словами, в каком языке самая лучшая (и при этом маленькая) библиотека работы со строками?

Мне в Python нравится.

И большой вопрос - как русифицировать названия.

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

В CL обычно быстрее. Куски компилятора доступные в рантайме убирают ненужные ветки исполнения. Применительно к чему-то уровня SBCL.

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

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

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, плюс набор примитивов типа «прочитать число». Опять же, это будет не особо быстро.

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

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

awk

Яр

так себе название, я вот «р» не выговариваю, оно оскорбляет мои картавые чувства

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

Посмотри в erlang какие есть функции для вдохновения.

http://erlang.org/doc/search/ => string

Если строка знает о кодировке что-то (какой размер символа в кодировке и постоянный ли он), то нужны методы:

• Длина строки в символах
• Взятие первых/последних N символов.
• Вставка символа/строки в строку, начиная с определенного символа. (если строки неизменяемые, явно указать в документации, что будет создана новая строка)
• Добавление в конец символа/строки. (аналогично)
• Существует ли подстрока в строке.
• Количество вхождений подстроки в строку.
• Символьная позиция первого/последнего/всех вхождения/ий подстроки в строку.
• Размер буфера, необходимого для хранения строки. (размер строки в байтах)

Может что забыл, но вроде все основное есть.

Далее, что в Питоне?

1. Много хороших констант, напиример, ascii_lowercase. Надо сделать.

2. Срезы - это сахар, интересный, но мне значков жаль на него. Можно сделать псевдо-ф-ии.

3. Класс formatter. В принципе интересно, вопрос - насколько это популярно?

4. template - мне не понравилось - слишком убого.

5. интересно: encode,decode,maketrans,translate,endswith,join (надо добавить необязательный параметр «разделитель»),

Спасибо, да, с кодировками тоже есть над чем поработать. Смотрим, что в лиспе есть (babel)

Интересно, почему-то из 1С 8 выпилили функцию «шаблон», к-рая позволяла составлять строки с выражениями. Не верю, что им не хватило ресурсов. Неужели они это сделали с какой-то целью?

В принципе функция Шаблон содержала внутри себя неявный eval. Но ведь можно было выпилить только eval.

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

Там есть также загадочная функция ПолучитьОбласть, про к-рую ничего не нагуглилось. Потому что «получитьобласть» якобы можно, а создать её никак нельзя.

Пока что дыра в том месте, где регулярные выражения и scanf.

Посмотри на http://www.red-lang.org/2013/11/041-introducing-parse.html

Делает всё, что ты хочешь: человекочитемые правила, переменные, отладка.

В принципе функция Шаблон содержала внутри себя неявный eval. Но ведь можно было выпилить только eval.

В документах выпилили eval. В коде программы посчитали, что Шаблон без eval не нужен (в нём синтаксически не видны переменные в момент компиляции). Там где был Шаблон, активно используется ПодставитьПараметрыВСтроку. Получается вроде:

СтроковыеФункцииКлиентСервер.ПодставитьПараметрыВСтроку(НСтр("ru = 'На рабочем сервере %1 не найден кластер %2'"),
		СоединениеСАгентомСервера.ConnectionString,
		ПортКластера)

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

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

Список (точнее динамический массив) строк и есть. Для больших документов необходим, так как добавить 100 символов в конец 100-мегабайтного документа в нём гораздо дешевле, чем если эти 100 мегабайт — строка.

Там есть также загадочная функция ПолучитьОбласть, про к-рую ничего не нагуглилось. Потому что «получитьобласть» якобы можно, а создать её никак нельзя.

Она в макете создаётся. А макет в конфигураторе. http://helpme1c.ru/kak-sozdavat-tekstovyj-maket-v-1s

Про Область и шаблон ясно, спасибо! Ладно, что-то такое типа буфера нужно сделать. Формат видимо делать всё равно придётся (ужас).

Насчёт red - выглядит похожим на то, что надо, другое дело, что нужно найти что-то уже готовое и похожее на лиспе, дабы не тратить силы на переписывание. Был meta-parse, но я его как раз недавно закончил выпиливать, и впиливать его обратно нет желания. Тупая процедурщина больше пришлась ко двору.

regexp'ы лучше отдать на волю библиотекописателей. Пусть сторонней библиотекой реализуют, проблем быть не должно (сами решат, какие регекспы им лучше).

Кстати, забыл про получение символа по его позиции в символах (не байтах).

Жесть этот ваш 1С. Каждый раз смотрю на него и глаза на лоб лезут.

ТС, не делай только как в C++. Худшей работы со строками и юникодом тяжело представить. Лучше уж как в C#, если ориентируешься на языки, которые от C часть синтаксиса переняли.

Ладно, буду иметь в виду. А что особо страшного в 1С?

Смесь кириллицы и латиницы.

Про 1С - спасибо (я мнения собираю).

• Существует ли подстрока в строке.
• Количество вхождений подстроки в строку.
• Символьная позиция первого/последнего/всех вхождения/ий подстроки в строку.

Здесь что-то явно лишнее. Например, позиция всех вхождений. Лучше уж позиция первого, но начиная с позиции эн.

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

То. Мне почему то именоо Allegro вспомнился. Они чуть понятнее подали эту идею. А ppcre у меня всегдя ассациировался с нечитаемыми закорючками:(

Смесь кириллицы и латиницы.

Так она в любом языке с Unicode есть, если программист русскоязычный. В нормальной программе на 1С никакой смеси — только кириллица. В примере ConnectionString — поле внешнего COM-объекта.

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

Можно сделать такую функцию, чтобы правильно расставляла ться/тся и не с глаголами?

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

Это работа для регулярных выражений.

Это парсеры на комбинаторах, если я правильно понял. Вот здесь перечислены недостатки этого подхода. Правда написана или нет?

Можно сделать такую функцию, чтобы правильно расставляла ться/тся и не с глаголами?

Я нашёл один сайт http://how-to-all.com, написанный на лиспе, к-рый предоставляет такой сервер. Если автор не подарит мне код, то я смогу только написать клиента для этого сайта. Ну или нужно искать другую библиотеку, к-рая это реализует, и прикручивать. В целом - да, такое нужно, спасибо!

Это работа для регулярных выражений.

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

Так она в любом языке с Unicode есть, если программист русскоязычный

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

Смотри сам по голове не получи :)

если в проект не чисто русскоязычный и не разрабатывается исключительно русскоязычными разработчиками.

... и не касается русскоязычных терминов. Тогда да.

Так и в 1С, если не про русскую бухгалтерию, то код выглядит так (из 1C:Hotel):

	If Not ValueIsFilled(pGuestGroup) Then
		Return;
	EndIf;
	
	// Accounting customer, contract, hotel, company, currency should be filled before calling Fill() method
	ParentDoc = Undefined;
	GuestGroup = pGuestGroup;
	
	// Get customer language
	vLanguage = Undefined;
	If ValueIsFilled(AccountingCustomer) Then
		vLanguage = AccountingCustomer.Language;
	EndIf;
	
	// Reset totals
	Sum = 0;
	VATSum = 0;
	CommissionSum = 0;
	
	// Clear tabular part Services
	Services.Clear();
	
	// Get all folio current accounts receivable services with balances per end of time
	vCharges = cmGetCurrentAccountsReceivableChargesWithBalances(?(ValueIsFilled(CloseOfPeriod), New Boundary(CloseOfPeriod.Date + 1, BoundaryType.Excluding), '39991231235959'), AccountingCustomer, AccountingContract, , GuestGroup, AccountingCurrency, Hotel);
	
	// Fill services tabular part
	pmFillServices(vCharges, vLanguage);
	
	// Fill totals
	Sum = Services.Total("Sum");
	VATSum = Services.Total("VATSum");
	CommissionSum = Services.Total("CommissionSum");
	
	// Fill list of payments
	pmFillListOfPayments();

Строки как понятие не нужно. Это слово вообще не пойми что обозначает. Английское String имеет куда больше смысла как «нить» и отсюда только начинает вытекать понимание проблем со словом «строка». String как таковой это контейнер, способ хранения при котором составляющие контейнера располагаются строго друг за другом и одна из основных операций это привязывание одной нити к другой. Это практически единственное, что отличает её от массива, в котором обычно операция «+» вообще не определена. Другими словами, в String должны быть определены те-же методы, что и в массивах плюс контатенация. String не должен делать никаких предположений о смысле «букв», которые в нём хранятся, в каком виде бы они не были в него записаны — байты, слова, double. Это просто контейнер.

Для операций над текстом должен быть тип Text. Он уже должен уметь считать количество букв (не «символов» в String), переводить себя в верхний/нижний регистр, лексографический поиск, возможно даже стемминг и тому подобное.

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

И да, локали. Это, очевидно, свойство текста, показывающее, как нужно интерпретировать содержимое нитей. От них было бы неплохо полностью избавится, но реальные задачи иногда требуют специальной обработки нитей. Типичной задачей локали является задача сортировки букв, которая, к примеру, должна помещать букву ё между «е» и «ж». Больше эту информацию взять неоткуда, стандартом Юникода лучше просто подтереться. вторая задача локали это взаимное превращение нити в «стандартной» локали и некоторой специальной, то есть правила uconv.

Ещё одним понятием является «code point». Пришло из юникода, очевидно, но по видимому от него уже не выйдет избавится, поскольку теперь у нас есть всякие эмоджи и прочий RTL. Возможно, для него вообще не нужна отдельная сущность, поскольку основные задачи, которые производятся над кодпоинтами это классификация и сравнение.

В результате мы имеем вонючую жижу, из которой ничего хорошего сделать уже нельзя, спасибо историческому наследию и действиям комитета Unicode. Возможно, грамотная архитектура текста, строк, локалей и прочей чуши куда важнее вопроса «какие функции должны быть у String», особенно если сам String не имеет смысла как такового. Я лично если честно куда больше заинтересован в вопросе архитектуры текста, чем в вопросе функций, функции это наживное.

Строки как понятие не нужно. ... Для операций над текстом должен быть тип Text.

Зачем по-русски называть текстом то, что все называют строкой. Текст в русском языке состоит из строк, а не из букв.

Типичной задачей локали является задача сортировки букв, которая, к примеру, должна помещать букву ё между «е» и «ж». Больше эту информацию взять неоткуда, стандартом Юникода лучше просто подтереться.

Юникод как раз и определяет локали.

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

Основная задача кодпоинта — что удалять по кнопке Backspace. Классифицировать имеет смысл только глифы или хотя бы нормализованные кодпоинты. Сравнивать кодпоинты по кодам вообще бессмысленно.

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

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

Завёл новую тему

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

По ссылке описания нескольких багов, найденных в реализации перла во время работы над cl-ppcre. Семантические отличия там не описаны.

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

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

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

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

Это плата за возможность компактно написать целый конечный автомат для разбора строки. Реализация через аналоги strtok будет длиннее и непонятнее. В лиспе, кстати, не составит труда ввести оператор q{} из перла, который сводит дополнительное экранирование к нулю. cl-interpol упрощает сборку строк, если не нравится format.

5. В обычной жизни всегда есть «отладка принтами».

В перле есть use re 'debugcolor', который делает ровно то, что ты хочешь. Запили в своей реализации.

По пунктам 2 и 3 --- масштабируемость, подпрограммы и сложность --- посмотри на грамматики в perl6. У меня нет опыта работы с ними, но, судя по описанию, они снимают твои возражения. Если сможешь перенести их в Яр (или в CL), будет круто.

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

Спасибо. Думаю, если это «баги» в перле, то они являются де-факто стандартом и нужна багосовместимость.

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

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

Касаемо perldebug, уклониться от сложности тут не выходит:

use re 'debug' enables you to see the gory details of how the Perl regular expression engine works. In order to understand this typically voluminous output, one must not only have some idea about how regular expression matching works in general, but also know how Perl's regular expressions are internally compiled into an automaton. These matters are explored in some detail in Debugging Regular Expressions in perldebguts.

Сразу начинает казаться, что это некий «неуправляемый trace», который потом ещё нужно фильтровать. Т.е. всё равно не слишком хороший отладчик (возможно, я придираюсь).

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

За cl-interpol спасибо, посмотрю.

Думаю, если это «баги» в перле, то они являются де-факто стандартом и нужна багосовместимость.

Там какие-то крайние случаи, вряд ли ими кто-то пользуется. Я думаю, лучше ориентироваться на документацию.

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

Набор функций типа trim-left и pad-right не прокатит в качестве такого механизма. Грамматики Perl6 или встроенные комбинаторные парсеры --- может быть, но их сделать сложнее регулярных выражений, для которых уже есть готовая библиотека. Вообще, большие задачи требуют индивидуального подхода, и сделать хороший универсальный инструмент сложно.

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

Грамматики (встроенные) появились только в Perl6, который вышел относительно недавно. Perl5 и Perl6 это два разных языка, как C и C++. Я ещё не успел поработать с Perl6, хотя у меня есть одна идея, для которой он неплохо подходит. В Perl6 нет классических регэкспов, но грамматики, насколько я понял, с ними частично совместимы. Так что в Perl6 придётся начинать с грамматик.

Сразу начинает казаться, что это некий «неуправляемый trace», который потом ещё нужно фильтровать.

Там действительно довольно много текста, но разобраться в нём несложно, достаточно вспомнить, что регулярные выражения строят конечный автомат. Найти ошибку с такой подробной выдачей не составляет труда. Если вы будете делать свою реализацию, то можно добавить управление над выдачей с помощью локальных биндингов динамических переменных. (Хм, интересно, можно ли отлаживать регулярные выражения, вызывая trace на внутренние функции cl-ppcre...).

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

Это должно быть просто в использовании. Сложно представить что-то проще чем /^\s*$/ для проверки пустых строк. Мелкие задачи редко требует контекстно-свободной грамматики, регулярной вполне достаточно.

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

Не уверен. Сам пока не разобрался (в планах). Но ракетовскую либу markdown использую и как слон доволен. // Регулярки сам не люблю, но что поделать.

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

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

Набор функций типа trim-left и pad-right не прокатит в качестве такого механизма.

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

Найти ошибку с такой подробной выдачей не составляет труда

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

Сложно представить что-то проще чем /^\s*$/ для проверки пустых строк

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

Не уверен. Сам пока не разобрался (в планах).

А мне кажется, похоже на правду (про недостатки комбинаторов)