>> У меня есть некоторый опыт разработки DSL на Ocaml.
> У меня тоже есть, но толку-то? Основная проблема с заменой sh -
> это то, что нужно хорошо поставить задачу, описать этот самый язык.
> А интерпретатор много кто может написать.
> Я много раз это обсуждал - решительно непонятно, что конкретно нужно делать
> с типами. Т.е. с одной стороны, скриптовый движок должен быть типизирован
> (т.к. bash уже есть), с другой стороны, нужна поддержка grep/sed -
> т.е. операций над строковыми данными. Нужно, чтобы скрипт мог без выпадения
> обрабатывать потоки данных с ошибками.Вот мне тоже не понятно, куда там типизацию втыкать. Основное применение shell - это вызов внешних команд. А их коды возврата - это обычно int. И где мы там типизацию втыкать собрались...
Нужна ли поддержка grep/sed в самом языке - это конечно вопрос интересный. Чтобы как в perl не ставить лишнюю экранировку - может быть, было бы удобно. Но возможно легче было бы в bash привнести что-то вроде двойных-тройных кавычек для этого дела?
Но вот если Вы предлагаете регэкспы компилировать языком, то я считаю это однозначно плохой вещью. Пусть уж лучше sed разбирает строку, которую мы ему передали и сигналит об ошибке кодом возврата, как и раньше.
Потом, начнём мы типы вводить. Какие мы сможем ввести-то? И для чего? Я смекаю, что только для определяемых функций. У нас будет тип exit_code, который будет либо Ok, когда программа вернула нуль, и Error of int, когда программа вернула не нуль. У нас будут преобразования exit_code в bool и в int. Надо поработать со строками обязательно. Где мы сможем использовать типизацию? Пожалуй, только в функциях, которые мы определяем в самом языке. Повсеместно будут требоваться преобразования кода возврата во что-нибудь. Для каждого действия со внешними командами придётся писать типизированную обёртку. Скрипты довольно-таки разрастутся.
Если на то пошло, у меня похоже получается один-в-один Ocaml, который дёргает внешние команды. Но сам Ocaml использовать нельзя, потому что у него слишком большой рантайм. Нам нужно что-нибудь легковесное, что уместится килобайт в 20 против 170кб для hello_world для Ocaml.
> Вот что в bash'е круто:
> 1) Работа со файловыми именами без кавычек. Ну и вообще минимум кавычек.
В большинстве случаев всё равно оборачиваю в кавычки всё, с чем работаю, чтобы в случае наличия пробелов трактовалось как один параметр.
> 2) Ленивость конвееров как Хаскелле, позволяет обрабатывать не влезающие в ОЗУ объёмы
> данных потоковым образом.
Ленивость конвееров - это собственно не фишка самого shell, а фишка unix-системы в целом. Он же создаёт детей и связывает их каналами, так что распараллеливание, оно на уровне ядра, а не shell-а.
> 3) Распараллеливаемость всего и всея - программы, входящие в конвеер работают параллельно.
Аналогично п.2
>> Для начала обсудим, что за проблемы со скриптами, и как подобные проблемы
>> sysvinit решены в других инитах. Я лично с проблемами в скриптах
>> не сталкивался (стабильный дебиан всё-таки), поэтому мне трудно судить, чего именно
>> не хватает.
> Инит скрипты уже более-менее вылизаны. Ну, а что плохо - if'ы, передача
> параметров скриптам, передача кодов ошибок и т.д.
А что там с if-ами? Не соображу никак. Если есть желание cond, так elsif в принципе та же фигня. Да и case в наличии.
Передача параметров - возможно. В принципе аналоги labeled & optional parameters для скриптов можно было бы обязательным предварительным getopt-разбором. Хотя если честно, мне понравилось, как параметры разбираются в zsh. Получается примерно так:
zparseopts -a opts \
v+ -version \
d -debug \
h -help -usage \
s:=server -server:=server \
-src:=source -source:=source \
-dst:=destination -destination:=destination \
p:=project -project=project \
a:=action -action:=action \
u:=user -user:=user
