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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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