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

I>>Не больше. Вспотеешь описывать const все возможные параметры.

_>Вот это аргумент...

Тебе, если в кратце, придется const писать вообще везде и не дай бог ошибиться.

_>Это уже пошло что-то из области яблофанатов, которые говорят "не нужно" на любую фичу, которой у них нет. А потом (когда она через пару лет появляется), называют её ключевой и революционной.

В данном случае от неё уже давно отказались.

_>Представляю реакцию на появление const где-нибудь в JS или C# лет через 5. )))

Она на самом деле нужна, но в основном для девелопера, а не для компилятора.

I>>То есть, ты сомневаешься что лямбда-счисление и подобные вещи это математика ?

_>Ну покажи мне ссылки и указатели в лямбда-исчисление.

Покажи мне, где я утверждаю, что ссылки и указатели это лямбда-счисление

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

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

Точнее — отсутствие гарантий. Твой хвалёный D даже хвостовую рекурсию толком не умеет

I>>Я утверждаю, что ты изобретаешь парадигму, только стесняешься это признать. Вместо этого трактуешь лямбда-счисление так как тебе угодно.

_>Я вообще ничего не изобретаю. Я не автор D и вообще пока ещё не создавал свои языки.

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

I>>Ты путаешь статическую типизацию и ручные аннотации типов и ограничений. Первое даёт гарантии, второе в общем случае не работает.

_>Ну покажи пример того, как они не работают. )

Пример уже был, про модификатор pure. Ты правда стесняешься это признать и строишь теории навроде "нужны объекты значения, иммутабельность это внешний факт" и тд

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

I>Подходит. f(5) всегда будет равно 5 и так все всегда будет f(5).

I>В лямбда счислении нет никаких присваиваний, поэтому f(x) всегда и везде будет f(x), и если x равно 5, то это эквивалентно f(5) и 5, и так независимо ни от чего.

I>Это в С++ ты можешь объявить переменную и переприсвоить, поэтому f(x) != f(x), но это говорит не о том, что функция не чистая, а о том, что твой код не имеет никакого отношения к лямбда-счислению. Чистота функции это растет из лямбда счисления. Нет лямбда-счисления -> чистота не имеет никакого смысла.

Вооот, наконец то до тебя начинает доходить то, о чём я уже давно тут говорю.

Можно работать с функцией (в смысле математики, а не программирования) определённой на поле действительных чисел, а можем продолжить её в область комплексных чисел. Так же и тут. Можно иметь понятие чистой функции только для иммутабельных параметров (как в лямбда-исчисление), а можно расширить это определение, включив и мутабельные. Причём как и в случае с комплексными/действительными числами, ключевым нюансом является то, что в старой области определения должно наблюдаться полное совпадение. Т.е. чистые функции D при работе с иммутабельными данными (напоминаю, что для них в D тоже есть свой модификатор) полностью совпадают с вариантом в Хаскеле (т.е. с классическим лямбда-исчислением).

По сути определение чистых функций в D выглядит как своеобразное аналитическое продолжение определения из Хаскеля. Причём это всё выглядит очень естественно, т.к. продолжение выполнено на область по сути отсутствующую в Хаскеле и естественно полностью отсутствующую в лямбда-исчисление.

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

I>>Подходит. f(5) всегда будет равно 5 и так все всегда будет f(5).

I>>В лямбда счислении нет никаких присваиваний, поэтому f(x) всегда и везде будет f(x), и если x равно 5, то это эквивалентно f(5) и 5, и так независимо ни от чего.

I>>Это в С++ ты можешь объявить переменную и переприсвоить, поэтому f(x) != f(x), но это говорит не о том, что функция не чистая, а о том, что твой код не имеет никакого отношения к лямбда-счислению. Чистота функции это растет из лямбда счисления. Нет лямбда-счисления -> чистота не имеет никакого смысла.

_>Вооот, наконец то до тебя начинает доходить то, о чём я уже давно тут говорю.

Я это повторяю в разной форме уже второй месяц.

_>По сути определение чистых функций в D выглядит как своеобразное аналитическое продолжение определения из Хаскеля. Причём это всё выглядит очень естественно, т.к. продолжение выполнено на область по сути отсутствующую в Хаскеле и естественно полностью отсутствующую в лямбда-исчисление.

По сути чистота в D не имеет никакого отношения к чистоте в лямбда-счислении. Как только параметры становятся мутабельными, весь профит заканчивается.

И теперь совершенно не ясно, на кой ляд нужно такое вот понятие — чистота, если эффекта нет.

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

ARK>Вообще говоря, если у компилятора есть полный исходный код, то ему вроде как и не нужен модификатор pure — он проанализирует тела всех функций и будет знать, какие чистые, а какие нет.

Собственно кроме оптимизации и корректности кода (про которую ниже) ещё возможно введение всяких забавных вкусностей в сам язык. Типа полноценной поддержки ленивости и т.п. К сожалению в D подобное ещё не сделано, так что это только теоретические рассуждения.

ARK>Получается, что pure нужен не только для дополнительных оптимизаций, а скорее для:
ARK>1) облегчения чтения кода программистом (не надо анализировать груду кода, достаточно взглянуть на сигнатуру функции);
ARK>2) облегчения модификации кода программистом (не получим — случайно — побочных эффектов там, где это не ожидается);
ARK>3) создания модульных систем, когда у нас исходников соседнего модуля нет, а есть только бинарник (правда, к D это не факт, что имеет отношение).

Да, согласен, в данный момент как раз в этом основные фичи и заключаются.

ARK>Очевидно, что для пунктов 1 и 2 нужны только "по-настоящему чистые" функции, допускающие только иммутабельные аргументы.
ARK>Иначе мы можем не просто потерять необязательную оптимизацию, но и случайно изменить поведение системы нежелательным образом.
ARK>

ARK>int pure OuterFunc<T>(T param) where T : IMyInterface
ARK>{
ARK>    param.Modify();   // можно ли вызывать? а черт его знает
ARK>    var result = InnerFunc(param);    // InnerFunc тоже "чистая"
ARK>    ...
ARK>}
ARK>

А что здесь не так то? Если Modify не является чистой, то этот код не скомпилируется и всё.

ARK>То есть модификатор pure в D далеко не так полезен, как мог бы быть.

Это да... Там ещё много чего можно улучшать.

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

I>Покажи мне, где я утверждаю, что ссылки и указатели это лямбда-счисление

Ок, покажи в другом разделе математики. )))

I>Точнее — отсутствие гарантий. Твой хвалёный D даже хвостовую рекурсию толком не умеет

Причём тут иммутабельность и хвостовая рекурсия? )

I>Ты изобрёл понятие чистоты, выбросив из него основную вещь, которая следует из базовых принципов лябда счисления

Я изобрёл? ))) Ты считаешь меня автором языка D? )

I>Пример уже был, про модификатор pure. Ты правда стесняешься это признать и строишь теории навроде "нужны объекты значения, иммутабельность это внешний факт" и тд

Примера нарушения гарантий не было. )

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

I>По сути чистота в D не имеет никакого отношения к чистоте в лямбда-счислении. Как только параметры становятся мутабельными, весь профит заканчивается.

I>И теперь совершенно не ясно, на кой ляд нужно такое вот понятие — чистота, если эффекта нет.

Не "не имеет никакого отношения", а определение из лямбда-исчисления является точным подмножеством определения из D. Т.е. по сути является его частным случаем. И соответственно для иммутабельных данных мы будем иметь в точности все законы лямбда-исчисления. А для мутабельных будет уже что-то другое, посложнее... Кстати, тут уже обсуждалось, что и там кое-какие интересные оптимизации возможны.

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

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

I>>По сути чистота в D не имеет никакого отношения к чистоте в лямбда-счислении. Как только параметры становятся мутабельными, весь профит заканчивается.
I>>И теперь совершенно не ясно, на кой ляд нужно такое вот понятие — чистота, если эффекта нет.

_>Не "не имеет никакого отношения", а определение из лямбда-исчисления является точным подмножеством определения из D.

И смысла в этом никакого.

>Т.е. по сути является его частным случаем. И соответственно для иммутабельных данных мы будем иметь в точности все законы лямбда-исчисления. А для мутабельных будет уже что-то другое, посложнее... Кстати, тут уже обсуждалось, что и там кое-какие интересные оптимизации возможны.

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

_>Ну и наконец, прочитай уже внимательно, что тут пишут (не в первый раз и не только я). Бонусы идут не только в виде некой оптимизации кода, но и в виде гарантий. Так вот, эти гарантии одинаково полезны и в случае иммутабельных параметров и в случае мутабельных. Думаю именно по этой причине авторы D решили ввести именно такое определение чистых функций.

Ты слово гарантии понимаешь как то по особому: " для иммутабельных данных мы будем иметь в точности все законы лямбда-исчисления. А для мутабельных будет уже что-то другое, посложнее..."

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

I>>Покажи мне, где я утверждаю, что ссылки и указатели это лямбда-счисление

_>Ок, покажи в другом разделе математики. )))

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

I>>Точнее — отсутствие гарантий. Твой хвалёный D даже хвостовую рекурсию толком не умеет

_>Причём тут иммутабельность и хвостовая рекурсия? )

Просто пример, чего может и чего не может компилятор. С иммутабельностью уже был пример, его достаточно.

I>>Ты изобрёл понятие чистоты, выбросив из него основную вещь, которая следует из базовых принципов лябда счисления

_>Я изобрёл? ))) Ты считаешь меня автором языка D? )

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

I>>Пример уже был, про модификатор pure. Ты правда стесняешься это признать и строишь теории навроде "нужны объекты значения, иммутабельность это внешний факт" и тд

_>Примера нарушения гарантий не было. )

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

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

_>А что здесь не так то? Если Modify не является чистой, то этот код не скомпилируется и всё.

Да, я тут лажанул. Имелось в виду — не вызов param.Modify, а что-то типа "param.field = 23;" — так же ведь можно сделать, если T мутабельный?
Правда, в таком случае параметр уже не может быть шаблонного типа, тип явно будет мутабельным. Поэтому вопрос отпадает.

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

ARK>Да, я тут лажанул. Имелось в виду — не вызов param.Modify, а что-то типа "param.field = 23;" — так же ведь можно сделать, если T мутабельный?
ARK>Правда, в таком случае параметр уже не может быть шаблонного типа, тип явно будет мутабельным. Поэтому вопрос отпадает.

Проблема не в том, можно ли менять унутре, а что будет, если менять снаружи. Т.е. насколько легко можно комбинировать чистый код с сайд-эффектами.

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

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

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

Прошу прощения, не понял.
Для какого значения компилер не сможет установить, что оно иммутабельное?
Можно коротенький псевдокод?

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

ARK>Прошу прощения, не понял.
ARK>Для какого значения компилер не сможет установить, что оно иммутабельное?
ARK>Можно коротенький псевдокод?

x = f(a)
...
y = f(a)

Компилятор должен установить, как вариант, что a иммутабельное, что бы выяснить, что x эквивалентно y

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

I>

I>x = f(a)
I>...
I>y = f(a)
I>

I>Компилятор должен установить, как вариант, что a иммутабельное, что бы выяснить, что x эквивалентно y

А разве компилятору неизвестен тип "a"? Если это мутабельный тип, и если сигнатура f ожидает мутабельный аргумент, то очевидно, что в данном случае нельзя сказать, что "x эквивалентно y" (во всяком случае, не заглядывая в тело f).

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

I>>Компилятор должен установить, как вариант, что a иммутабельное, что бы выяснить, что x эквивалентно y

ARK>А разве компилятору неизвестен тип "a"? Если это мутабельный тип, и если сигнатура f ожидает мутабельный аргумент, то очевидно, что в данном случае нельзя сказать, что "x эквивалентно y" (во всяком случае, не заглядывая в тело f).

Как узнать что тип мутабельный ?

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

I>Компилятор не сможет узнать по иммутабельность, так что профита не будет.

С чего это не сможет? А модификатор типов immutable на что?

I>Ты слово гарантии понимаешь как то по особому: " для иммутабельных данных мы будем иметь в точности все законы лямбда-исчисления. А для мутабельных будет уже что-то другое, посложнее..."

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

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

I>Уже показывали. Правда оказалось, что у тебя свой взгляд и на то, что считать математикой.

Ты покажи не математическое моделирование ссылок и указателей, а покажи наличие их самих в математике. )

I>Просто пример, чего может и чего не может компилятор. С иммутабельностью уже был пример, его достаточно.

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

I>У тебя уникальное понимание функциональщины. Именно ты хочешь применять часть оптимизаций для части кода и игнорируешь любые аргументы, почему это работать не может и не работает. Именно по этой причине тебе нравится D — в нем реализован подход, с которым ты согласен. Собственно дело не в D, а твоих уникальных взглядах на любую из обсуждавшихся областей.

Хы, да просто ты пока ещё думаешь, что в мире есть только действительные числа, а я уже оперирую комплексными.

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

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

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

http://www.rsdn.ru/forum/philosophy/5549436

Автор: alex_public
Дата: 08.04.14

— в продолжение дискуссии... ) Забавно было бы взглянуть на попытки создание подобного на других языках.

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

I>Как узнать что тип мутабельный ?

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

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

I>>Компилятор не сможет узнать по иммутабельность, так что профита не будет.

_>С чего это не сможет? А модификатор типов immutable на что?

Это ручной контроль, неинтересно.

I>>Ты слово гарантии понимаешь как то по особому: " для иммутабельных данных мы будем иметь в точности все законы лямбда-исчисления. А для мутабельных будет уже что-то другое, посложнее..."

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

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

Мы говорим про чистоту, а не гарантии отсутствия побочных эффектов. Чистота это отсутствие побочных эффектов + детерминизм. pure означает первое, а pure + параметры immutable — второе.

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

I>>Как узнать что тип мутабельный ?

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

То есть, всё сводится к ручному контролю. А раз так, то чистая функция это не pure, а pure у которой аргументы immutable, то есть, те самые значения про которые говорит alex_public.