Здравствуйте, Arsen.Shnurkov, Вы писали:
AS>Логично было бы описать синтаксис командной строки при помощи EBNF. AS>Ну EBNF — это стандарт, а теория компиляции у нас вообще одна — если не регэкспы, так БНФ.
У обычных програм синтаксис командной строки слишком простой, чтобы имело смысл париться с BNF.
Если у вашей программы он настолько сложный, спросите себя, а осилят ли его пользователи вашей программы.
Re: Теория компиляции и разбор параметров командной строки
Не видели.
Если у вашей программы такие хитрые параметры командной строки, что хочется бежать за EBNF / пилить парсер, то вы явно намутили там лишнего.
Лучше выкините весь разбор параметров, делайте полноценный API или принимайте формализованное описание задания (допустим xml).
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Re: Теория компиляции и разбор параметров командной строки
Здравствуйте, Arsen.Shnurkov, Вы писали:
AS>Логично было бы описать синтаксис командной строки при помощи EBNF. AS>Ну EBNF — это стандарт, а теория компиляции у нас вообще одна — если не регэкспы, так БНФ.
Это никому не нужно — люди пользуются готовыми парсерами.
Например, boost program options умеет кучу всякого: и параметры, и через переменные окружения, и через response-файлы
Здравствуйте, Arsen.Shnurkov, Вы писали:
AS>Пока вы тут смайлы ставите, продуктивные индусы ирландцы изобрели язык для описания параметров: AS>http://docopt.org/ AS>и написали компилятор(ы) для него под разные технологии: AS>https://github.com/docopt/docopt.net
Ура! N+1-я библиотека для парсинга командной строки!
Но ты ведь ею все равно пользоваться не будешь, ибо "Вот оно, общество потребителей" (с)
Логично было бы описать синтаксис командной строки при помощи EBNF.
Ну EBNF — это стандарт, а теория компиляции у нас вообще одна — если не регэкспы, так БНФ.
Тем не менее, я нигде не видел, чтобы к разбору аргументов командной строки подходили именно таким способом
(то есть формально описывая грамматику с обработкой ошибок
и генерируя парсер, который выдаёт внятную диагностику)
Не страшно, может другие люди видели.
VTT>Если у вашей программы такие хитрые параметры командной строки, что хочется бежать за EBNF / пилить парсер, то вы явно намутили там лишнего. VTT>Лучше выкините весь разбор параметров, делайте полноценный API или принимайте формализованное описание задания (допустим xml).
Во-первых, command line interface — это вполне себе интерфейс, а программа вполне себе прикладная. Так что параметры командной строки могут считаться API.
Во-вторых, какая разница как формализовано описание — в XML или в параметрах? Главное чтобы было формализовано как-нибудь.
В третьих, парсеров уже напиленных — пачками: https://github.com/gsscoder/commandline https://github.com/fschwiet/ManyConsole
И если у ваших программ такие хитрые параметры командной строки, что вам надо каждый раз писать кастомный парсер, то... вы зря тратите деньги заказчиков.
Я просто хотел бы найти такой парсер, который мне было бы легче и понятнее учить, потому что он основывается на понятной мне терминологии.
В четвёртых, уводить тему в офтопик невежливо (это я про непрошенный совет переделать по-другому. Вдруг программа не моя? Вдруг есть неотменяемые требования по совместимости?).
Хотите обсудить именно передачу данных в принципе, и проагитировать за XML — создайте ветку рядом, я увижу.
Re[3]: Теория компиляции и разбор параметров командной строк
Здравствуйте, Arsen.Shnurkov, Вы писали:
AS>Во-первых, command line interface — это вполне себе интерфейс, а программа вполне себе прикладная. Так что параметры командной строки могут считаться API.
Интерфейс командной строки — это компромисс тех времен, когда единственным вариантом взаимодействия с пользователем был текстовый терминал.
Компромисс в том плане, что такой подход позволил одновременно реализовать интерфейс для пользователя (человеко пригодный) и для взаимодействия с другими программами.
Но как и любой компромисс, он имеет недостатки по сравнению с отдельными средствами для каждого из этих случаев.
AS>Во-вторых, какая разница как формализовано описание — в XML или в параметрах? Главное чтобы было формализовано как-нибудь.
Разница огромная.
Xml (ну или json, если вам так не нравится xml) — это известный, стандартизованный и готовый к применению формат для использования которого есть все необходимое.
AS>И если у ваших программ такие хитрые параметры командной строки, что вам надо каждый раз писать кастомный парсер, то... вы зря тратите деньги заказчиков. AS>Я просто хотел бы найти такой парсер, который мне было бы легче и понятнее учить, потому что он основывается на понятной мне терминологии.
Хитрый самопальный синтаксис параметров командной строки(пусть парсящийся готовым парсером) — вот зряшная трата денег заказчика.
А если изучение этого синтаксиса его сильно напряжет, то можно вообще остаться и без заказчика.
AS>Я просто хотел бы найти такой парсер, который мне было бы легче и понятнее учить
Так надо было с этого начинать.
AS>Вдруг программа не моя? Вдруг есть неотменяемые требования по совместимости?
Опять же, использование такой стандартной вещи, как xml, в плане совместимости несравненно лучше собственного велосипеда.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, Arsen.Shnurkov, Вы писали:
AS>Тем не менее, я нигде не видел, чтобы к разбору аргументов командной строки подходили именно таким способом AS>(то есть формально описывая грамматику с обработкой ошибок AS>и генерируя парсер, который выдаёт внятную диагностику)
Если структура настройки слишком сложная, то судя по моему опыту работы с программами используют файлы конфигурации. Вспомнить хотя бы серверные приложения, службы (демоны) и тому подобное. А так языки программирования описываются схожим образом. Командную строку обычно делают гораздо проще, чтобы было удобно использовать, потому там хоть и можно записать всё в виде EBNF, но нет необходимости.
Опять же то, что понятно парсеру, может быть очень непонятно человеку, а командная строка предназначена именно для людей. Здесь вопрос скорее в логике, то есть анализе и синтезе. К примеру, принцип построения большинства командных строк один и тот же, так почему бы не использовать единый графический интерфейс для выбора нужных параметров.
Re[4]: Теория компиляции и разбор параметров командной строк
AS>>Вдруг программа не моя? Вдруг есть неотменяемые требования по совместимости? VTT>Опять же, использование такой стандартной вещи, как xml, в плане совместимости несравненно лучше собственного велосипеда.
Блин, ну не интересен мне ваш XML, если так чешется — пойдите убедите всех сайтописателей
перестать использовать их языки шаблонов и начать использовать XSLT
Re[2]: Теория компиляции и разбор параметров командной строки
Конечно не буду, но по другой причине. Она не уважает моё право использовать любой язык (например русский).
Ну то есть локализация там не очень продумана.
