Бойко Банчев - Язык РЕФАЛ - взгляд со стороны (обсуждение)
Знакомство с языком Рефал полезно программисту хотя бы потому, что этот функциональный язык не похож ни на один из других - среди них он занимает особое место и по возрасту, и по происхождению, и по назначению, и по стилю. Достойно сожаления то что, несмотря на свои качества, язык не очень популярен
( Read more... )
Reply
и какой ее частью надо жертвовать?
Reply
Reply
ответов (на вопросы) нет.
пролог ведь тьюринг-полный? декларативный.
"Скорее всего этот опыт и привёл меня в итоге к функциональным языкам."
Reply
2. Язык при этом не должен быть Тьюринг-полным. Поэтому, например, у него скорее всего не должно быть переменных, возможности эти переменные модифицировать, возможности вызывать функции, не должно быть глобально модифицируемого состояния. Inheritance с модификацией переменных наследуемой среды - ещё куда ни шло.
3. Формальной модели того, чего "достаточно" или "необходимо" иметь в языке у меня нет, поэтому отсутствие тьюринг-полноты - это ограничение "сверху" - чтобы язык конфигурации был "не экспрессивнее" чем любой сколько-либо простой язык программирования.
Вопрос "какой частью тьюринг-полноты надо жертвовать" я не понял.
Reply
OK.
FP, вроде под это тоже подходит, или я чего не понимаю?
Поэтому, например, у него скорее всего не должно быть переменных
спорно.
но если с
возможности эти переменные модифицировать
то переменные, которые нельзя пмодифицировать допустимы или нет?
возможности вызывать функции
спорно.
для, скажем конфига RADIUS-сервера, как сказать, что session-timeout есть функция от направления, баланса и тарифа?
не должно быть глобально модифицируемого состояния.
ок
Вопрос "какой частью тьюринг-полноты надо жертвовать" я не понял.
ну я темный, сиволапый. потому, когда говорят "отсутсвие тьюринг-полноты" - для меня звучит как "что-то от тьюринг-полноты должно отсутсвовать".
Reply
Скорее нет, чем да. Вот \x -> x + 1 - это fp или нет? FP. Но это не то, что я считаю декларативным описанием. Лямбды какие-то, эта-редукции...
> то переменные, которые нельзя пмодифицировать допустимы или нет?
Неизменяемые атрибуты и key/value - конечно допустимы. Это же основа конфигурации вообще-то.
> для, скажем конфига RADIUS-сервера, как сказать, что session-timeout есть функция от направления, баланса и тарифа?
Как-как, описанием декларативно:
session-timeout "timeout1" {
type "constant";
value "42";
}
session-timeout "timeout1" {
type "js-function";
value "function(env) { return env.direction + env.balance - env.tariff + 13; }";
}
Бенефит: сайд-эффекты не расползаются по коду конфига. Контаминейшн тьюринг-полнотой ограничен конкретным микро-углом конфигурации. Язык имплементации функций не фиксирован, и может быть каким угодно (список по выбору). Сам по себе язык конфигурации фиксирован и не меняется - хорошо для поддержки легаси компонентов, ( ... )
Reply
Вот $ENV{USER} или $HOME -- это ж переменная. но не атрибут или key/value.
Как-как, описанием декларативно:
какое ж это декларативно! это мало того что многозначно, так еще и с функциями!
Бенефит: сайд-эффекты не расползаются по коду конфига.
ну да, пока ты первый и второй вариант не разнес мегабайтом конфига.
Сам по себе язык конфигурации фиксирован и не меняется - хорошо для поддержки легаси компонентов, которые знать не знают, что для какого-то соседнего компонента session-timeout теперь можно записывать через функцию.
просто компоненты должны делать вызов "дай session-timeout для текущего контекста"
Это бинарь вообще-то. Или полнота есть, или её нет. Как именно полнота достигается - вопрос совершенно отдельный. В некоторых языках достаточно циклов, памяти, и условных переходов. В других - лямбда-абстракций. Как-то так.ну вот там для лямбда абстракций тоже, если сделать А, но не делать Б -- то тьюринг-полноты не будет (нет, не помню ( ... )
Reply
Это ты правильно подловил - я сначала написал полностью декларативный вариант, затем заменил его на встроенную функцию. Текст вверху оставил.
> просто компоненты должны делать вызов "дай session-timeout для текущего контекста"
Это в любом случае нужно, если правильно дизайнить. В каких-то системах тебе библиотека конфигурации может дать таймаут, вытащив нужную ей свору зависимостей из pre-shared глобального контекста, если ей это нужно и описывается конфигурацией, но это макароны.
ну или из циклов, памяти и условных переходов выкинем память -- будет ОК?
"ОК" будет так, как я показал в той своей статье.
Reply
и в мыслях ловить не было.
это я конфигами испорчен и подумал, что ты проказал стандартную ситуацию -- дефолтное константное значение и в отдельных случаях функция.
В каких-то системах тебе библиотека конфигурации может дать таймаут, вытащив нужную ей свору зависимостей из pre-shared глобального контекста, если ей это нужно и описывается конфигурацией, но это макароны.
что такое макароны и почему макароны?
"ОК" будет так, как я показал в той своей статье.
если это так, как ты тут в примерах показываешь -- то это заметание мусора по ковер, поскольку вопрос языка относится во-первых "на потом", во-вторых для каждого компонента он может оказаться индивидуальным, а в третьих если будет нужна связь между параметрами/компонентами -- то что делать?
Reply
Почему макароны - это потому что мы фактически не пишем конфигурацию, а пишем программу. Теперь представим некий веб-интерфейс с кнопочками и попапчиками, который эту конфигурацию-программу меняет. Представили? Нет? Вот и я нет - делать интерфейсы к декларативным инструментам проще, чем делать интерфейсы к языку, который может содержать произвольную сложность, в том числе вычислительно сложную. Что если нужно матрицы считать, чтобы таймаут выяснить? Это не должно быть частью конфига, а должно описываться конфигом, что "надо-бы тут матрицу посчитать; как именно - ты знаешь, или вот тебе функция, которой ты знаешь, как пользоваться".
Reply
чего там представлять? видел я такое и пользовался.
ну не веб, а gui на жабе, но что в лоб, что по лбу.
редактор сценариев для cisco callcenter express.
и не скажу, что это был больший ад и пиздец, чем веб-интерфейс к конфигу роутера. такое же неудобное говно.
в реальных условиях попытка скрестить ежа с ужом для конфига радиус-сервера приводит к фэйлу для декларативного конфига.
Reply
Это практика и реальные условия.
Обрати внимание, что конфигурация и сценарии - это вообще разные вещи. Я не предлагаю писать сценарии на декларативном языке, а именно конфигурацию, в которой, например, могут быть ссылки на сценарии.
Reply
а конфиг а радиус-сервера в декларативных терминах в мои потребности не укладывается никак, без всяких сценариев.
Reply
Если у тебя другие требования и другой опыт - было бы интересно обстоятельно обсудить его в твоём журнале, в комментариях к твоей статье, этот опыт описывающей.
Reply
опыта имплементации нет (надюсь, что только пока нет. в любом случае я сначала лекции дослушаю).
но прежде чем бросаться сломя голову имплементировать что попало разложить по полочкам.
да, я понимаю твои аргументы. но, кмк, это идеально в том случае, если все подсистемы -- рездельны и независимы. а если надо таскать параметры из одной подсистемы в другую, или даже результаты из одной подсистемы в другую -- то натыкаемся на ограничения.
Reply
Leave a comment