Здравствуйте, alvas, Вы писали:

A>В англоязычной части интернете шустро обсуждают новое ключевое слово pure.
A>Кто может вкратце описать суть по русски?

Мммм... А можно вопрос вдогонку?
Если есть функция:

public A(i: int): IEnumerable[T]
{
   yield i + 1;
   yield i + 2;
}

Так вот, эта функция с побочными эффектами или нет?

Здравствуйте, Flem1234, Вы писали:

F>

F>public A(i: int): IEnumerable[T]
F>{
F>   yield i + 1;
F>   yield i + 2;
F>}
F>

F>Так вот, эта функция с побочными эффектами или нет?

Сама функция — нет. А вот генератор, который она возвращает уже имеет побочные эффекты — автомат состоянии.

Здравствуйте, VladD2, Вы писали:

VD>Отдельный, отдельный. К побочным эффектам приводит не сама функция, а то что ей передают в качестве параметра.
Ты пошол по очень скользкой дорожке.
Ибо глобальные переменные неявно передаются при каждом вызове каждой функции.
Следуя твоей логике мы объявляем все функции чистыми ибо функции не виноваты, а виноваты глобальные переменные которые были переданы функции.

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

VD>Не то что бы реализация без изменения типов будет не качественной. Просто контроль будет происходить на другой стадии — на стадии вызова.
Те проверки времени исполнения и исключения?

Здравствуйте, WolfHound, Вы писали:

VD>>Отдельный, отдельный. К побочным эффектам приводит не сама функция, а то что ей передают в качестве параметра.
WH>Ты пошол по очень скользкой дорожке.
WH>Ибо глобальные переменные неявно передаются при каждом вызове каждой функции.

А причем тут глобальные переменные?

WH>Следуя твоей логике мы объявляем все функции чистыми ибо функции не виноваты, а виноваты глобальные переменные которые были переданы функции.

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

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

Конечно можно запихнуть признак чистоты прямо в систему типов. Но тогда чистую функцию будет вообще нельзя вызвать из нечистого контекста. А это вряд ли то что хотят пользователи. На хрен нам еще один Хаскель?

VD>>Так что достаточно в месте вызова проверить, то что параметры передаваемые чистой функции так же чистые.
WH>А сделать это можно только если добавить в систему типов чистые и грязные функции.

Не только. См. выше.

VD>>Не то что бы реализация без изменения типов будет не качественной. Просто контроль будет происходить на другой стадии — на стадии вызова.
WH>Те проверки времени исполнения и исключения?

Нет. Проверка времени компиляции. Работает простое правило. Если вызывать только чистые функции и передавать им только чистые функции, то и работа выполненная ими будет без побочных эффектов. По-моему — это очевидно.

Здравствуйте, VladD2, Вы писали:

VD>А причем тут глобальные переменные?
При том что это один из способов организовать побочные эффекты.

VD>Вовсе нет. Если функция порождает побочный эффект, то она априори не чистая.
С твоим определением тут возникают неоднозначности.

VD>Чистую функцию можно вызывать из не чистой
Это да.

VD> передавая ей так же не чистую функцию.
А вот тут уже начинаются проблемы.
Ибо чистота функции начинает зависеть от того что в нее передают.
А это само по себе весьма странно.

VD>Нам достаточно гарантировать, что если функция вызывается в контексте не допускающем побочных эффектов, то чтобы все вызванные функции и функции переданные в качестве параметров другим функциям были чистыми. Тогда и вычисления будут чистыми.
Кручу, верчу запутать хочу... Ничего не понял.

VD>Конечно можно запихнуть признак чистоты прямо в систему типов. Но тогда чистую функцию будет вообще нельзя вызвать из нечистого контекста. А это вряд ли то что хотят пользователи. На хрен нам еще один Хаскель?
Наоборот.
Чистою функцию из грязной вызывать можно.
Но грязную из чистой вызывать нельзя.

Ты же настаиваешь на возможности передать в чистую функцию грязную и вызвать ее.

VD>Нет. Проверка времени компиляции. Работает простое правило. Если вызывать только чистые функции и передавать им только чистые функции, то и работа выполненная ими будет без побочных эффектов. По-моему — это очевидно.
Те таки изменение системы типов?

Здравствуйте, WolfHound, Вы писали:

WH>При том что это один из способов организовать побочные эффекты.

Хочешь сказать, что в ней может быть ссылка на функцию и не будет возможности узнать чистая она или нет?

WH>Ибо чистота функции начинает зависеть от того что в нее передают.
WH>А это само по себе весьма странно.

Это не верное трактование. Функция не становится не чистой если в нее передать не чистую функцию. Вот вычисление созданное на базе смеси чистых и не чистых функций действительно становится не чистым.

VD>>Нам достаточно гарантировать, что если функция вызывается в контексте не допускающем побочных эффектов, то чтобы все вызванные функции и функции переданные в качестве параметров другим функциям были чистыми. Тогда и вычисления будут чистыми.
WH>Кручу, верчу запутать хочу... Ничего не понял.

Очень простая формула. Вычисление будет чистым если в нем используются только чистые функции. Это относится как к взовам, так и к ссылкам на функции. Если мы можем гарантировать, что, скажем, в теле функции нет обращений к не чистым функциям (т.е. известно, что все использованные функции (в том числе и по ссылке) чистые), то тело функции, а значит и вся функция тоже является чистой.

WH>Чистою функцию из грязной вызывать можно.
WH>Но грязную из чистой вызывать нельзя.

Иногда нужно делать то что нельзя. По мне так можно просто ограничиться явной декларацией ранушения чистоты. Скажем если мы передаем в чистую функцию не чистую в качестве параметра, то надо выразить это явно.

WH>Ты же настаиваешь на возможности передать в чистую функцию грязную и вызвать ее.

Ну, дык это иногда нужно. Скажем для логирования.

VD>>Нет. Проверка времени компиляции. Работает простое правило. Если вызывать только чистые функции и передавать им только чистые функции, то и работа выполненная ими будет без побочных эффектов. По-моему — это очевидно.
WH>Те таки изменение системы типов?

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

Здравствуйте, VladD2, Вы писали:

AB>>а такая?
AB>>def isItPure( act : void->int ) { act(); 1; }
AB>>?

VD>А эта чистая. Только бессмысленная, так как возвращаемое значение act теряется. Учитывая, что для общей чистоты act обязана так же быть чистой функцией, приведенный код является глупостью.

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

вот например

def A(act : int->int) { act(5)+2; }
def B(act : int->int) { A(act); }

main() { 
    ArrayList ar = ArrayList();
    B(x => x*2);              
    B(x => { ar.Add(x); x*2; }
}

а вот теперь ответь на вопрос. Функция A чистая или нет?
А как ты это определил? А каким алгоритмом пользовался?

Здравствуйте, AngeL B., Вы писали:


AB>вот например

AB>

AB>def A(act : int->int) { act(5)+2; }
AB>def B(act : int->int) { A(act); }

AB>main() { 
AB>    ArrayList ar = ArrayList();
AB>    B(x => x*2);              
AB>    B(x => { ar.Add(x); x*2; }
AB>}
AB>

AB>а вот теперь ответь на вопрос. Функция A чистая или нет?

Да. А вот лямбда "x => { ar.Add(x); x*2; }" — нет. Стало быть второй вызов функции B недопустим. Точнее допустим только если передаваемую в него лямбду пометить неким специальным образом. Например, поместить в некий макрос. Такая пометка будет выключать проверку осуществляемую компилятором и тем самым позволять программисту создавать условно-чистые функции (т.е. проблемы от некорректной работы которых программист будет брать на себя).

AB>А как ты это определил? А каким алгоритмом пользовался?

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

Здравствуйте, VladD2, Вы писали:

VD>Да. А вот лямбда "x => { ar.Add(x); x*2; }" — нет. Стало быть второй вызов функции B недопустим. Точнее допустим только если передаваемую в него лямбду пометить неким специальным образом. Например, поместить в некий макрос. Такая пометка будет выключать проверку осуществляемую компилятором и тем самым позволять программисту создавать условно-чистые функции (т.е. проблемы от некорректной работы которых программист будет брать на себя).
А вот и const_cast... здравствуй дырявый С++...

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

Здравствуйте, VladD2, Вы писали:

VD>Хочешь сказать, что в ней может быть ссылка на функцию и не будет возможности узнать чистая она или нет?
Как вариант.
Вообще в любом случае любое обращение к глобальной переменной делает функцию грязной.

VD>Это не верное трактование. Функция не становится не чистой если в нее передать не чистую функцию. Вот вычисление созданное на базе смеси чистых и не чистых функций действительно становится не чистым.
Тут все еще веселее.
Функция становится грязной если в нее передают любые грязные данные.
Причем не важно что это за данные. Хешьтаблица, грязная функция или неявно передаваемые глобальные переменные.

В тоже время функция остается чистой если в нее не передают грязные данные даже если внутри происходят грязные вычисления. См ниже.

VD>Очень простая формула. Вычисление будет чистым если в нем используются только чистые функции. Это относится как к взовам, так и к ссылкам на функции. Если мы можем гарантировать, что, скажем, в теле функции нет обращений к не чистым функциям (т.е. известно, что все использованные функции (в том числе и по ссылке) чистые), то тело функции, а значит и вся функция тоже является чистой.
А вот скажи вот эта функция чиcтая или нет:

factorial(n : int) : int
{
    mutable res = 1;
    for (mutable i = 1; i <= n; ++i)
        res *= i;
    res;
}

Согласно твоему определению она грязная. Но по факту она чистая.

Более того даже если использовать грязные структуры данных внутри функции в которую не передают грязные данные то функция всеравно останется чистой.

Таким образом мы приходим к тому что чистота функции определяется исключительно сигнатурой функции.

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

VD>Иногда нужно делать то что нельзя. По мне так можно просто ограничиться явной декларацией ранушения чистоты. Скажем если мы передаем в чистую функцию не чистую в качестве параметра, то надо выразить это явно.
Так я же и говорю привет const_cast...

VD>Ну, дык это иногда нужно. Скажем для логирования.
Зачем тебе логирование внутри чистой функции?

VD>Изменение системы типов позволит упростить определение того чистая функция или нет для ссылок на функции. Но в принципе это будет работать и без изменения системы типов.
Не будет.
Ты просто сделаешь эти изменения неявными.

Здравствуйте, WolfHound, Вы писали:

WH>Те чистота функции зависит от деталей реализации?

От своего сдержимого.

WH>Тебе не кажется это несколько странным в статически типизированном языке?

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

Но эту информацию можно положить в те самые переменные.

ЗЫ

Ладно. Это разговор не о чем. Лично я эту фичу для первой версии немерла реализовывать не буду. А другие или не в силах будут сделать (как Эмпфирон) или так же не возьмутся от лени (как ты).

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

А пока что ты бы лучше помог бы товарищу para в работе над PegParser-ом. Там нужно не мало ума приложить в области дизайна чтобы получить быстрый и удобный макрос.

Здравствуйте, VladD2, Вы писали:

VD>Да. А вот лямбда "x => { ar.Add(x); x*2; }" — нет. Стало быть второй вызов функции B недопустим.
чем дальше тем веселее обсуждать
а если код вот такой

def pure A(act : int->int) { act(5)+2; }  //pure
def B(act : int->int) { A(act); }         //не pure

main() { 
    ArrayList ar = ArrayList();
    B(x => x*2);              
    B(x => { ar.Add(x); x*2; }
}

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

AB>>А как ты это определил? А каким алгоритмом пользовался?
VD>В ней не используется операторов которые могут изменить состояние.
эмммм?? то есть вызов внешней функции, которая непонятно что содержит, это уже не оператор "который может изменить состояние"?

Здравствуйте, WolfHound, Вы писали:

WH>Вообще в любом случае любое обращение к глобальной переменной делает функцию грязной.

Да ну? Даже если переменная не изменяемая и указывает на неизменяемое значение?

WH>Функция становится грязной если в нее передают любые грязные данные.
WH>Причем не важно что это за данные. Хешьтаблица, грязная функция или неявно передаваемые глобальные переменные.

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

Но на практике это как раз не проблема. Проблема отследить тонны кода в котором проблему может вызвать любой оператор. А "контролируемая грязь" — это как раз даже хорошо. Без этого не всегда можно добиться оптимальной производительности.

WH>В тоже время функция остается чистой если в нее не передают грязные данные даже если внутри происходят грязные вычисления. См ниже.

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

WH>А вот скажи вот эта функция чиcтая или нет:
WH>

WH>factorial(n : int) : int
WH>{
WH>    mutable res = 1;
WH>    for (mutable i = 1; i <= n; ++i)
WH>        res *= i;
WH>    res;
WH>}
WH>

Чистая, так как выход зависит от входа. А то что внтури есть изменяемая локальная переменная ни на что не влияет.

WH>Более того даже если использовать грязные структуры данных внутри функции в которую не передают грязные данные то функция всеравно останется чистой.

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

WH>Таким образом мы приходим к тому что чистота функции определяется исключительно сигнатурой функции.

Чушь. Если в функции меняется, скажем, поле класса или глобальная перменная, то она грязная.

WH>Но тут под ногами начинают путаться глобальные переменные.
WH>Они собаки такие передаются неявно и везде не оставляя следов в сигнатуре функции.

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

VD>>Иногда нужно делать то что нельзя. По мне так можно просто ограничиться явной декларацией ранушения чистоты. Скажем если мы передаем в чистую функцию не чистую в качестве параметра, то надо выразить это явно.
WH>Так я же и говорю привет const_cast...

const_cast позволяет сделать редактируемым не редактируемое значение. Тут же речь идет о том, что пользователь берет на себя ответственность за то, что некая структура данных не будет изменена во то время когда она используется чистой функцией. Не вижу в этом проблемы. А вот const_cast — это нарушение гарантий системы типов который исключает оптимизации и легко приводит к ошибкам.

VD>>Ну, дык это иногда нужно. Скажем для логирования.
WH>Зачем тебе логирование внутри чистой функции?

Для отладки. Это только в сказках ФП и чистые мат.вычисления делают не нужной отладку.

VD>>Изменение системы типов позволит упростить определение того чистая функция или нет для ссылок на функции. Но в принципе это будет работать и без изменения системы типов.
WH>Не будет.
WH>Ты просто сделаешь эти изменения неявными.

Ну, называй как хочешь только в печку не ставь.

Ладно. Я эту дискуссию завязал. Практического смысла в ней пока нет.

Здравствуйте, AngeL B., Вы писали:

AB>а если код вот такой
AB>

AB>def pure A(act : int->int) { act(5)+2; }  //pure
AB>def B(act : int->int) { A(act); }         //не pure

AB>main() { 
AB>    ArrayList ar = ArrayList();
AB>    B(x => x*2);              
AB>    B(x => { ar.Add(x); x*2; }
AB>}
AB>

AB>тогда что?

Тогда в последней строчке ошибка будет.

AB>предложишь запретить вызов чистых из грязных?

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

def ar = List();
B(MrkAsPure(x => { ar.Add(x); x * 2; }))

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

AB>и заодно грязных из чистых?

А вот грязные из чистых действительно вызвать нельзя. Допустимо только изменение локальных переменных. Собственно пометка данных как чистые и есть возможность вызвать грязные функции из чистых на страх и риск программиста.

AB>после чего код разваливается на два непересекающихся множества, каждое из которых не может вызывать друг друга.

Пока в языке нет ленивости и перестройки хода вычислений проблем взаимодействия двух миров не будет. Но взаимодействие должно иметь четкую границу. Иначе в этом просто нет смысла.

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

AB>эмммм?? то есть вызов внешней функции, которая непонятно что содержит, это уже не оператор "который может изменить состояние"?

Нет, конечно. Из чистых функций можно вызвать только чистые функции или помеченные как чистые.

Здравствуйте, VladD2, Вы писали:

VD>Да ну? Даже если переменная не изменяемая и указывает на неизменяемое значение?
Тогда это не переменная, а именованная константа.
ИМХО разница существенная.

VD>Еще раз функция от этого грязнее не становится. Она как порождала одно и то же значение для одного и того же набора параметров, так и будет порождать. Другое дело, что если входные данные меняются во время исполнения, то конечно вычисление будет грязным.
Проблема в том что с твоим подходом мы не можем это проконтролировать.

VD>Но на практике это как раз не проблема. Проблема отследить тонны кода в котором проблему может вызвать любой оператор. А "контролируемая грязь" — это как раз даже хорошо. Без этого не всегда можно добиться оптимальной производительности.
Контролируемая грязь это когда грязь не может пересечь границу функции.
А если грязь явно (параметры) или не явно (глобальные переменные) пересекает гранциу функции то это уже не контролируемая грязь.

VD>Я не знаю что значит грязные вычисления, но если функция меняет состояние чего-то за пределами своего тела (т.е. что-то кроме локальных переменных), то эта функция никак не будет чистой.
Если в функцию не были переданы грязные данные то она ничего не может изменить.
Глобальные переменные это частный случай передачи грязи в функцию.

WH>>Более того даже если использовать грязные структуры данных внутри функции в которую не передают грязные данные то функция всеравно останется чистой.
VD>Функция — несомненно. Вычисление — может стать грязным. Но вина в том не функции, а какой-то другой функции.
Чушь! Если в функцию не передали грязь то она не может стать грязной никак и ни когда.

WH>>Таким образом мы приходим к тому что чистота функции определяется исключительно сигнатурой функции.
VD>Чушь. Если в функции меняется, скажем, поле класса или глобальная перменная, то она грязная.
Так я про то и говорю. Если мы в функцию передали грязь то она грязная.

VD>Никаких проблем в них нет, если они указывают на неизменяемые структуры данных или если пользователь сам пометил их как безопасные.
Ты говоришь ровно как С++ники. У них тоже ни с чем проблем нет... А на практике решето.

VD>const_cast позволяет сделать редактируемым не редактируемое значение. Тут же речь идет о том, что пользователь берет на себя ответственность за то, что некая структура данных не будет изменена во то время когда она используется чистой функцией. Не вижу в этом проблемы. А вот const_cast — это нарушение гарантий системы типов который исключает оптимизации и легко приводит к ошибкам.
Ты сам то веришь в то что сказал?
Вот это код явно посылает гарантии системы типов

B(MrkAsPure(x => { ar.Add(x); x * 2; }))

и исключает оптимизиции ибо мы не можем оптимизировать код вида

    def a = act(1);
    def b = act(1);

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

WH>>Зачем тебе логирование внутри чистой функции?
VD>Для отладки. Это только в сказках ФП и чистые мат.вычисления делают не нужной отладку.
Если отладка это единственная причина то специально для отладки можно встроить в платформу хак.

VD>Ладно. Я эту дискуссию завязал. Практического смысла в ней пока нет.
Если мы говорим про язык плотно интегрированный в .NET то в этом вообще смысла нет.
Ибо там везьде тонны грязи и все пронизано глобальными переменными.

Здравствуйте, VladD2, Вы писали:

WH>>Те чистота функции зависит от деталей реализации?
VD>От своего сдержимого.
Решето.

VD>Ладно. Это разговор не о чем. Лично я эту фичу для первой версии немерла реализовывать не буду. А другие или не в силах будут сделать (как Эмпфирон) или так же не возьмутся от лени (как ты).
Я за эту фичу не возьмусь ибо в рамках .НЕТ ее невозможно качественно реализовать.

VD>А пока что ты бы лучше помог бы товарищу para в работе над PegParser-ом. Там нужно не мало ума приложить в области дизайна чтобы получить быстрый и удобный макрос.
Я уже тебе сказал что либо нужно проектировать сразу с блекджеком и шлюхами либо не делать вообще.
То чем занимается товарищь пустая трата времени.

Здравствуйте, VladD2, Вы писали:

почему просто не потребовать, чтоб на вход чистой функции подавались чистые делегаты:

def pure B(act : pure int->int) { A(act); }

чистый делегат можно создать из чистой функции лимбо из лямбды
А макрос MrkAsPure — проверяет чистоту лямбды и возвращает чистый делегат

def ar = List();
B(MrkAsPure(x => { ar.Add(x); x * 2; }))

да и наверняка, можно сделать это автоматически без явного вызова MrkAsPure

Здравствуйте, WolfHound, Вы писали:

AB>>>а такая?
AB>>>def isItPure( act : void->int ) { act(); 1; }
AB>>>?
A>>И такая тоже нет
WH>Это зависит от того является ли act pure или нет.
WH>А чтобы четко отделить мух от катлет нам придется завести 2 типа функций...

В D так и сделано, жестко разделено, например такое:

int Tst(int delegate () f) pure
{
    return f();
}

Выдаст ошибку компиляции:

Error: pure function 'Tst' cannot call impure delegate 'f'

А такое:

int Tst(int delegate () pure f) pure
{
    return f();
}

нормально скомпилируется.

Здравствуйте, WolfHound, Вы писали:

VD>>Хочешь сказать, что в ней может быть ссылка на функцию и не будет возможности узнать чистая она или нет?
WH>Как вариант.
WH>Вообще в любом случае любое обращение к глобальной переменной делает функцию грязной.

Если глобальная переменная не мутабельная можно спокойно обращаться, в D так и сделано.

Здравствуйте, para, Вы писали:

P>Здравствуйте, VladD2, Вы писали:

P>почему просто не потребовать, чтоб на вход чистой функции подавались чистые делегаты:
P>

P>def pure B(act : pure int->int) { A(act); } 
P>

а вот зачем ты меняешь написанное? Функция B у меня в примере грязная. И в этом все дело.
она получает грязный делегат, и вызывает чистую функцию.