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

ARK>>>>Все же жаль, что не удалось узнать, можно ли кэшировать якобы чистую функцию putStr. Было бы интересно послушать.
S>>>Что мешает попробовать?
ARK>>Не знаю, как это записать. Можешь подсказать, как закешировать вызов, скажем, putStr("qwerty")? Находясь, разумеется, внутри не-IO функции.

S>

S>putStrLn1 = putStrLn "querty"

S>main = do
S>  putStrLn1
S>  putStrLn1
S>

"Находясь, разумеется, внутри не-IO функции."

putStrLn1 — это IO, разве нет?

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

S>>>Это следует из твоего подхода. Ведь не я, а именно ты предлагаешь судить о чистоте функции по выхлопу виртуальной машины. Вот и ответь себе, бывают ли чистые функции при таком подходе к проверке чистоты?
ARK>>Чистых функций, согласно определению из википедии (а не моему подходу), не бывает. Согласно этому определению, говорить можно только чистых ВЫЗОВАХ, а понять чистоту или грязноту самой функции — невозможно.
S>Вау. Других слов нет.



ARK>>Согласно моему подходу, чистые функции — это те функции, которые мы ДЕКЛАРИРОВАЛИ как чистые. Чисты ли будут вызовы таких функций, или не чисты — неважно.
ARK>>Соответственно, "декларативно чистая" функция — это функция, которая задекларирована как чистая. Во всех известных мне языках под "чистыми" функциями понимаются именно "декларативно чистые".
S>Во всех известных мне языках (их не так много) вряд ли пользуются ТВОИМ определением чистоты.

"pure" функция в D может в некоторых случаях делать ввод-вывод. Хотя в википедии написано, что pure function не может делать ввод-вывод.

ARK>>Декларировать чистоту функции можно несколькими способами.
ARK>>1) Сигнатура функции. Самый надежный способ. Встроенные функции имеют сигнатуру, заданную аксиоматически, а построенные поверх них — уже определенную из исходного кода тел этих функций. Варианты сигнатур: ключевое слово "pure" в D, IO-монада в Haskell (декларируется наоборот грязь), "function" в Ada-83 и т.д.
ARK>>2) Документация. Из сигнатуры понять нельзя, но в документации явно указано, что функция чиста (декларативно, разумеется!). Менее надежный способ, т.к. компилятор нам уже ничего не подскажет, если документация устарела.
ARK>>3) Просмотр исходного кода / вера / чуйка / etc. Самый ненадежный способ. Мы имеем некоторые основания предполагать, что функция чиста (опять же, декларативно — ибо никто не запретит нам ее запустить в виртуальной машине и получить ввод-вывод на этой якобы чистой функции). Но эти основания не подкреплены ничем.
S>Какой вообще смысл в проверки чистоты виртуальной машиной, если виртуальная машина может сделать грязным даже пустой файл/лист без функций вовсе?

Это не "проверка чистоты", а демонстрация как минимум неполноты определения чистоты из википедии, если оно претендует на статус формального определения.

S>>>>>Причем тут вера? В евклидовой геометрии параллельными прямыми на плоскости называются непересекающиеся прямые.
ARK>>>>Да. Это задано аксиоматически. То же самое и с чистотой (как минимум на уровне встроенных функций).
S>>>Пардон, я в определении чистоты не видел перечня аксиоматически чистых функций. Можешь указать мне на него?
ARK>>Почему этот перечень должен там быть? Он не часть определения.
S>Если он не часть определения, почему ты опираешься на этот перечень?

Верно, опираюсь, пожалуй. Да, этого списка там нет (хотя есть упоминание его подмножества: "Thus a pure function is a computational analogue of a mathematical function", я трактую это как указание на множество всех математических функций). Но я как раз и говорю о том, что это определение является слишком неформальным.

S>>>Я знаю, потому нет смысла говорить о чистоте всех синусов. Но с процедурой определения чистоты синуса мне как бы все понятно.
ARK>>И каким же образом? Открыл его код, ищешь там функции, которые считаешь грязными (почему ты их считаешь грязными, отдельный вопрос)? Запустил, ожидаешь вывод картинки на принтер или вывод в консоль? Предположим, не увидел ни того, ни другого. Все, после этого ты ВЕРИШЬ, что синус чист? Я правильно описал процедуру определения чистоты?
S>Немного не так. Я смотрю на контракт, чист ли он? Если синус отличается от своего контракта, то это проблема частной реализации синуса, а не контракта. Если это так — возьму другой.

Под словом "контракт" ты понимаешь здесь сигнатуру конкретной функции, описание конкретной функции или что-то иное?

S>>>Вот это хорошо сказал. Ну то есть, всем не пофиг. Сложно пользоваться функций, если не представляешь или не в полной мере представляешь ее контракты. Что она портит, что берет помимо аргументов, от чего зависит результат (не только лишь возвращаемый, но и изменения в окружении). Т.е. еще один способ судить о чистоте функции (не исчерпывающий, разумеется) — анализ чистоты контракта.
ARK>>Кроме контракта, ни о каких вариантах чистоты судить или нет смысла, или невозможно. Контракт может быть задан разными способами (см. выше).
S>Ну как, ты же судишь по виртуальной машине!

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

ARK>>>>Оно не гадит в момент связывания. А гадит, когда "внешний вычислитель" это запустит. В точности, как в хаскеле.
S>>>Передает ли внешний вычислитель при этом управление printf-у? Если да, то грязь появляется до или после возврата управления?
ARK>>Идеологически — не передает, а передает управление action'у, который вернул printf. Ой, а как же напрямую вызвать action, который возвращает printf, как это выразить в коде? Никак. Ровно то же самое, что в хаскеле.
S>А в какой момент action получит строку для вывода, сгенерированную в рантайме?

"Сгенерированную в рантайме" — это возвращенную в рантайме другим грязным action, который сгенерирован функцией, например, "scanf"? Ну, в соответствующий момент в рантайме и получит. Не очень понял этого вопроса. Все как в хаскеле же.

S>>>Давай попробуем разобраться хотя бы в чистоте контракта State. Нужна ли грязь для его реализации?
ARK>>Ты все же скажи, как ты видишь "грязь в коде".
S>Я смотрю, есть ли там вообще пространство для грязи на уровне контракта, потом дополнительно проверяю вызовы подозрительных функций. В State достаточно посмотреть на вызовы IO внутри. Или unsafe. Ну а зачем, главное? Я прекрасно знаю, как устроен State. Сам его писал. Воткнуть в него вывод можно, но объясни, зачем?

А что такое "подозрительные функции"? И почему ты ищешь IO-функции, они ведь, по-твоему, чистые? Где "корень" чистоты или грязи?

S>>>Нужна ли грязь для его реализации?
ARK>>Нужна, для телеметрии. Я разработчик нового компилятора Haskell и хочу дать пользователям возможность писать такие программы, активность которых можно при желании контролировать удаленно.
S>Интересно, что мешает пользователям контролировать активность без нового компилятора? Но ты, видимо, не только компилятор, а еще и все исходники хочешь переписать. Ну ладно. Успехов.

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

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

S>>>>>Нет, не согласен. См. определение. Принимать IO — еще не грязь.
S>ARK>>>Единственно разумный подход — считать, что это грязь.
S>>>В соответствии с единственным разумных подходом (по твоей версии) выходит, что следующая функция в хаскеле грязная, т.к. может принимать IO:
S>>>

S>>>id x = x
S>>>

ARK>>"Может принимать" и "всегда принимает/возвращает" — разные вещи. Если просто "может" — значит, эта функция ортогональна IO и грязной не является. А вот когда не МОЖЕТ, а ДОЛЖЕН — это уже другое дело.
S>Это юлеж. Постом назад альтернатив и ортогональностей не было, был единственно разумный подход!

Так твоя функция не принимает IO. IO нет в сигнатуре. А под "принимать IO" речь шла именно о сигнатуре ("Функция является грязной, если она принимает IO среди своих аргументов").

S>Ну а почему неотделим-то?
S>Т.е. все, кто кэширует IO, делают это лишь из-за богатого воображения?

Можешь продемонстрировать это?

ARK>>ОК. Давай определимся с критерием. Ты согласен, что физически грязь можно получить, вызвав любую функцию (см. виртуальные машины)? Равно как и наоборот — можно физически НЕ получить грязь, вызвав любую функцию (все зависит от откружения, в котором функция запускается)?
S>С этим я не согласен. Тут уже находились любители измерять грязь по машинному коду. Ты предлагаешь измерять ее по вычислителю. Этого нет смысла, вычислитель может залить все грязью, даже не видя исходник функции. Какой смысл в таком критерии?

Смысл в этом критерии такой: он позволяет отделить зерна от плевел. Понять, где проходит граница чистоты.

ARK>>Что же тогда называть "чистой функцией"? Я предлагаю вариант с ДЕКЛАРАЦИЕЙ чистоты (а не тем, что реально происходит при вызове): http://rsdn.org/forum/philosophy/7589812.1

Автор: AlexRK
Дата: 13.11.19

ARK>>Если такой вариант трактовки чистоты ты считаешь неправильным, то назови с твоей точки зрения правильный. Еще раз напомню, что вариант "чистая функция — которая не делает ввод-вывод" может быть легко фальсифицирован с помощью подделки окружения, в котором эта функция вызывается.
S>Видишь лист бумаги? Думаешь, он белый? А я возьму красный фильтр и докажу что он красный. Именно это ты предлагаешь с фальсификацией окружения. Смысла в этом 0.

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

Однако я вижу, что тебе не нравятся формальные рассуждения, тебе ближе варианты со "здравым смыслом".

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

I>>Именно, плановая, систематическая, цель которой — гарантированное подтверждение. Если ты не достиг цели, о качестве вообще нет смысла говорить. А если достиг, то у тебя есть точные сведения о том, какое именно качество — высокое, низкое, среднее. И если цель не достигнута, то процесс строится так, что бы получить внятное обоснование, где препятствие и как его устранить.
S>Ну, а что если цель достичь подтверждения в 2050-м году?

Значит до того говорить про качество смысла никакого нет. И про бенефиты от парадигмы — тоже

I>>Если вдруг обнаруживается, что цель недостижима, то ты получаешь гарантию — установить качество не представляется возможным.
S>И как ты обнаружишь что цель недостижима? Вот я буду 1 день в году посвящать плановой и систематической деятельности, цель которой — гарантированное подтверждение соответствия. В соответствии с определением — это и есть контроль качества. Но ты еще требуешь достижимости. Вот и доказывай теперь, почему такая деятельность не ведет к достижению.

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

>И почему наличие кадра, который 100% времени будет заниматься тестированием, обязательно приведет к гарантированному подтверждению, даже если кроме этого кадра вообще никто продуктом не занимается? Жду.

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

I>>А что по твоему есть "гарантированное подтверждение" ?
S>Ты хочешь сказать, что гарантированное подтверждение это есть обещание? Ну я тогда не понимаю, обещать можно без тестирования. Все что угодно. И заплатить рубль в качестве гарантии, если выяснится, что соответствия требованием не выполнены. Чем тогда это не "гарантированное подтверждение"? И это дешевле, чем держать человека на 100% оклада.

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

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

I>>Наоборот. Когда ожидания адекватные, разумные, то достижение цели становится возможным. В этом случае при правильном процессе или достигаешь цель, или находишь препятствие, которое необходимо устранить.
S>Достижение цели становится возможным — это отъезд. Ты говорил о гарантиях достижения.

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

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

I>>Там много чего нет, это очевидно. Постановка цели сама собой подразумевает, что делаться это будет не абы как, а рационально, и цель будет адекватной условиям задачи.
S>У тебя постановка цели = обещание, или я что-то путаю?

Путаешь. Цель — гарантированое подтверждение соответствия требованиям. То есть, нечто вида "в ходе испытаний установлено, что степень соответствия требованиям (надежности, производительности, функциональным и тд) высокая"
Если ты такое получил, и использовал для этого методику, которую признает кастомер, прошел, скажем, сертификацию по этой методике, доказал, что дейтсвительно ей следуешь, то твои обещания будут принимать направо-налево.

I>>Ок, то есть, сказать нечего.
S>Я как раз сказал. Тебе ответить нечего.

В таком случае ты продемонстрировал что не можешь скриптануть некий неучтенный фактор, который заранее не может быть учтен, например потому, что вовсе неизвестен заранее.

S>>>Когда будут известны требования

I>>Ты ведь сказал — что можешь заскриптовать неизвестное. Покажи пример одного единственного фактора, неизвестного на момент скриптования(расширения, дополнения).
S>Я не говорил, что могу заскриптовать неизвестное. Цитату. Может быть ты подразумевал, что можешь проверить руками что-то неизвестное. Но я про заскриптовать такое не говорил.

Я говорю про неизвестные, неожиданные, неучтенные по какой либо причине факторы(например — фактор заранее неизвестен). И ты уверяешь, что:

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

Вот мне и интересно, каким образом ты можешь учесть то, чего учесть заранее никак нельзя.

I>>Всегда. Я всем говорю, что в софте гарантированно есть неожиданные баги. Чем слабее тестирование, тем выше шанс на них нарваться.

S>С твоих слов выходит, что контроль качества — бессмысленная затея, т.к. цель недостижима.

Очевидно, ты понимаешь "качественный" как такой, в котором баги отсутствуют. С т.з.качества это верх некомпетентности сказать, что баги отсутствуют.
Другой пример — безопасность, с этой точки зрения верх некомпетентности сказать, что уязвимости отсутствуют.

Поэтому "гарантии соответствия" это не "багов нет", а "мы делаем всё лучшем виде, см. рекомендации ведущих собаководов, перечень прилагается"

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

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

ARK>>>Не знаю, как это записать. Можешь подсказать, как закешировать вызов, скажем, putStr("qwerty")? Находясь, разумеется, внутри не-IO функции.

S>>

S>>putStrLn1 = putStrLn "querty"

S>>main = do
S>>  putStrLn1
S>>  putStrLn1
S>>

ARK>"Находясь, разумеется, внутри не-IO функции."

ARK>putStrLn1 — это IO, разве нет?
это IO, но это не функция. А как ты хотел кэшировать результат putStr, если результат IO? Если я создам список элементов типа IO, полегчает?

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

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

S>>Во всех известных мне языках (их не так много) вряд ли пользуются ТВОИМ определением чистоты.

ARK>"pure" функция в D может в некоторых случаях делать ввод-вывод. Хотя в википедии написано, что pure function не может делать ввод-вывод.
Ну и может, что из этого? Это не значит, что твое определение известно разработчикам D.

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

ARK>Это не "проверка чистоты", а демонстрация как минимум неполноты определения чистоты из википедии, если оно претендует на статус формального определения.
Какое отношение к чистоте функции имеет твоя демонстрация грязного вычислителя?

ARK>>>Почему этот перечень должен там быть? Он не часть определения.
S>>Если он не часть определения, почему ты опираешься на этот перечень?

ARK>Верно, опираюсь, пожалуй. Да, этого списка там нет (хотя есть упоминание его подмножества: "Thus a pure function is a computational analogue of a mathematical function", я трактую это как указание на множество всех математических функций). Но я как раз и говорю о том, что это определение является слишком неформальным.
А это уже и не определение, а пояснение.

S>>Немного не так. Я смотрю на контракт, чист ли он? Если синус отличается от своего контракта, то это проблема частной реализации синуса, а не контракта. Если это так — возьму другой.

ARK>Под словом "контракт" ты понимаешь здесь сигнатуру конкретной функции, описание конкретной функции или что-то иное?
В том числе сигнатуру, описание, не портит ли функция GetLastError()?

S>>Ну как, ты же судишь по виртуальной машине!

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

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

S>>А в какой момент action получит строку для вывода, сгенерированную в рантайме?

ARK>"Сгенерированную в рантайме" — это возвращенную в рантайме другим грязным action, который сгенерирован функцией, например, "scanf"? Ну, в соответствующий момент в рантайме и получит. Не очень понял этого вопроса. Все как в хаскеле же.
Нет, не как в хаскеле. В хаскеле генерация действия отделена от его выполнения. Это и позволяет кэшировать результаты IO функций, и потом выполнять их.

S>>Я смотрю, есть ли там вообще пространство для грязи на уровне контракта, потом дополнительно проверяю вызовы подозрительных функций. В State достаточно посмотреть на вызовы IO внутри. Или unsafe. Ну а зачем, главное? Я прекрасно знаю, как устроен State. Сам его писал. Воткнуть в него вывод можно, но объясни, зачем?

ARK>А что такое "подозрительные функции"? И почему ты ищешь IO-функции, они ведь, по-твоему, чистые? Где "корень" чистоты или грязи?
Выполнение IO действий может приводить к грязи, разумеется.

S>>Интересно, что мешает пользователям контролировать активность без нового компилятора? Но ты, видимо, не только компилятор, а еще и все исходники хочешь переписать. Ну ладно. Успехов.

ARK>Ты рассуждаешь с позиций некоего "здравого смысла", а я рассуждаю формально.
Для рассуждающего формально, ты слишком далеко оторвался от определения.

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

ARK>>>>Не знаю, как это записать. Можешь подсказать, как закешировать вызов, скажем, putStr("qwerty")? Находясь, разумеется, внутри не-IO функции.
S>>>

S>>>putStrLn1 = putStrLn "querty"
S>>>main = do
S>>>  putStrLn1
S>>>  putStrLn1
S>>>

ARK>>"Находясь, разумеется, внутри не-IO функции."
ARK>>putStrLn1 — это IO, разве нет?

S>это IO, но это не функция.

Как это не функция? Это самая обыкновенная функция. Ты просто создал обертку вокруг putStr. То же самое я могу сделать и с printf / Console.WriteLine / etc.

S>А как ты хотел кэшировать результат putStr, если результат IO?

Я это хотел выяснить у Sinclair, он ведь считает putStr чистой. Я не знаю способов кеширования putStr (отличных от способов "кеширования" printf).

S>Если я создам список элементов типа IO, полегчает?

Это будет просто список функций — вызовов putStr с частично примененным аргументом.
То же самое можно сделать с printf.

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

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

ARK>>>"Может принимать" и "всегда принимает/возвращает" — разные вещи. Если просто "может" — значит, эта функция ортогональна IO и грязной не является. А вот когда не МОЖЕТ, а ДОЛЖЕН — это уже другое дело.
S>>Это юлеж. Постом назад альтернатив и ортогональностей не было, был единственно разумный подход!

ARK>Так твоя функция не принимает IO. IO нет в сигнатуре. А под "принимать IO" речь шла именно о сигнатуре ("Функция является грязной, если она принимает IO среди своих аргументов").
Функция id принимает все, что угодно, в том числе IO. Т.е. на ответ, принимает ли она IO, можно смело кивать.

S>>Ну а почему неотделим-то?
S>>Т.е. все, кто кэширует IO, делают это лишь из-за богатого воображения?

ARK>Можешь продемонстрировать это?
Демонстрировал последним примером.

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

ARK>Смысл в этом критерии такой: он позволяет отделить зерна от плевел. Понять, где проходит граница чистоты.
В твоем критерии не понять, где проходит граница, т.к. можно сделать чистым и грязным даже отсутствие функции. Т.е. это не зависит от наличия функции. Остается понять, причем тут вообще функция и ее чистота?

S>>Видишь лист бумаги? Думаешь, он белый? А я возьму красный фильтр и докажу что он красный. Именно это ты предлагаешь с фальсификацией окружения. Смысла в этом 0.

ARK>И ты совершенно прав. Белый, красный, чистый, грязный — это неформальные ощущения. Квалиа, как любит говорить один местный гражданин. А формально другое — длина волны, частота излучения и т.п. И даже там на самом низком уровне приходится прибегать к аксиоматике — потому что в любом случае ты упираешься в базовые понятия, которые не выразимы ни через что.

ARK>Однако я вижу, что тебе не нравятся формальные рассуждения, тебе ближе варианты со "здравым смыслом".
Не вижу смысла уделять время формальным рассуждениям за гранью смысла. Если тебе нравится рассуждать о такой чистоте, когда любая функция может быть и чиста и грязна одновременно, включая тождественную, то и оставлю тебя с этими рассуждениями.

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

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

S>>Ну, а что если цель достичь подтверждения в 2050-м году?

I>Значит до того говорить про качество смысла никакого нет. И про бенефиты от парадигмы — тоже

Ок, на сим завяжем.

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

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

ARK>>>"Находясь, разумеется, внутри не-IO функции."
ARK>>>putStrLn1 — это IO, разве нет?

S>>это IO, но это не функция.
Формально — нет. Что такое функция? Грубо — соответствие между элементами двух множеств. Здесь мы имеем ровно один элемент, который не соответствует ничему.

ARK>Как это не функция? Это самая обыкновенная функция. Ты просто создал обертку вокруг putStr. То же самое я могу сделать и с printf / Console.WriteLine / etc.

S>>А как ты хотел кэшировать результат putStr, если результат IO?

ARK>Я это хотел выяснить у Sinclair, он ведь считает putStr чистой. Я не знаю способов кеширования putStr (отличных от способов "кеширования" printf).
И я putStr считаю чистой. И тоже не назову других способов. Так что не так с кэшированием?

S>>Если я создам список элементов типа IO, полегчает?

ARK>Это будет просто список функций — вызовов putStr с частично примененным аргументом.
Нет, это будет список IO, полученных в результате абсолютно полного применения аргументов putStr. Сигнатуру putStr напомнить?
ARK>То же самое можно сделать с printf.
Никто не утверждал обратного. Можно завернуть printf с параметрами в лямбду и кэшировать. Но это не делает саму printf чистой, разумеется. Обертка может быть чиста.

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

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

A>>Главным в этом вопросе является то, что "мир" передается явно и все функции, взаимодействующие с миром, принимают и возвращают его.
S>putStr не принимает мир и не возвращает его. Она принимает string и возвращает трансформацию мира, не сам мир.
Трансформатор мира это функция, явно принимающая мир и возвращающая новый, имененный мир.
Хотя согласен, слово "явно" тут неоднозначно. То, что "IO a" это обертка для такой функции, как раз спрятано, чтобы нельзя было сохранять World в переменной.

A>>Еще полезным было бы как-то на уровне системы типов сделать трюк, запрещающий сохранение текущего состояния мира в переменной с последующим переиспользованием. На сколько понимаю, именно для этого сделали, что "IO a" это тип функций, взаимодействующих с миром, а не тип, хранящий сам мир. "Инстанс" мира глубоко спрятан и недоступен.
S>Переменных в языке нет, "инстанс" мира — абстрактный тип. Какие еще трюки нужны?
Термин "переменная" все же используется и для именованных констант.
Если бы "IO a" был определен как

type IO a  =  World -> (a, World)

то можно было бы делать такое:

main world0 = let (a, world1) = putStr "Hello" world0
                  (b, world2) = putStr "World" world1
                  (c, world3) = putStr "Rsdn" world1 -- world1!
              in ((), world3)

с неочевидным поведением.
Впринципе, раз world2 не нужен для вычисления world3, который мы возвращаем, то и выполнять вторую строчку не требуется, так что результатом работы программы должен бы быть вывод "Hello Rsdn".
Функциональной чистоты мы не нарушим, если World сделать доступным. Но все же было бы полезно такое запретить.

Еще "IO a" мог бы быть просто контейнером для мира

type IO a  =  (a, World)

Тогда тип putStr был бы String -> IO a -> IO ()
Тип main был бы IO () -> IO ()
Никакой "отложенности выполнения с возвратом якобы грязной лямбды, принимающей на вход грязный мир" бы небыло, но функция main, тем не менее, была бы чистой.

Фишка в том, что функции, взаимодействующие с миром (putStr, getChar и т.п.) на самом деле формально являются чистыми. И оставались бы чистыми, даже если World передавался явно, даже первым параметром.

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

S>>>Во всех известных мне языках (их не так много) вряд ли пользуются ТВОИМ определением чистоты.
ARK>>"pure" функция в D может в некоторых случаях делать ввод-вывод. Хотя в википедии написано, что pure function не может делать ввод-вывод.
S>Ну и может, что из этого? Это не значит, что твое определение известно разработчикам D.

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

S>>>Какой вообще смысл в проверки чистоты виртуальной машиной, если виртуальная машина может сделать грязным даже пустой файл/лист без функций вовсе?
ARK>>Это не "проверка чистоты", а демонстрация как минимум неполноты определения чистоты из википедии, если оно претендует на статус формального определения.
S>Какое отношение к чистоте функции имеет твоя демонстрация грязного вычислителя?

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

S>>>Немного не так. Я смотрю на контракт, чист ли он? Если синус отличается от своего контракта, то это проблема частной реализации синуса, а не контракта. Если это так — возьму другой.
ARK>>Под словом "контракт" ты понимаешь здесь сигнатуру конкретной функции, описание конкретной функции или что-то иное?
S>В том числе сигнатуру, описание, не портит ли функция GetLastError()?

Функций в мире много. Ты всегда проверяешь все инварианты всех функций? Соответствует ли название функции тому, что она делает? Не перепутаны ли местами x и y в функции DrawPoint?
Или, может, ты доверяешь сигнатуре и/или документации?

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

Это окружение, а не вычислитель. Если бы это был вычислитель, то и в С все функции были бы чистыми. Окружение "работает" всегда, и до вычислителя (если он есть), и во время, и после.

S>>>А в какой момент action получит строку для вывода, сгенерированную в рантайме?
ARK>>"Сгенерированную в рантайме" — это возвращенную в рантайме другим грязным action, который сгенерирован функцией, например, "scanf"? Ну, в соответствующий момент в рантайме и получит. Не очень понял этого вопроса. Все как в хаскеле же.
S>Нет, не как в хаскеле. В хаскеле генерация действия отделена от его выполнения. Это и позволяет кэшировать результаты IO функций, и потом выполнять их.

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

UPD. ОК, я подумал и соглашусь, что отделение в каком-то смысле есть. Но, на мой взгляд, это отделение эквивалентно созданию обертки и по форме, и по сути — просто обертка создается внутри, а не снаружи.

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

ARK>>>>"Может принимать" и "всегда принимает/возвращает" — разные вещи. Если просто "может" — значит, эта функция ортогональна IO и грязной не является. А вот когда не МОЖЕТ, а ДОЛЖЕН — это уже другое дело.
S>>>Это юлеж. Постом назад альтернатив и ортогональностей не было, был единственно разумный подход!

ARK>>Так твоя функция не принимает IO. IO нет в сигнатуре. А под "принимать IO" речь шла именно о сигнатуре ("Функция является грязной, если она принимает IO среди своих аргументов").
S>Функция id принимает все, что угодно, в том числе IO. Т.е. на ответ, принимает ли она IO, можно смело кивать.

Sinclair написал конкретное определение чистоты в его понимании (которое совпадает с моим, кстати):

1. Функция является грязной, если она принимает IO среди своих аргументов.
2. Функция, вызывающая грязную, является грязной.
Всё. Все остальные функции — чистые.

Твоя функция id НЕ удовлетворяет описанию грязной функции из этого определения.

S>>>Ну а почему неотделим-то?
S>>>Т.е. все, кто кэширует IO, делают это лишь из-за богатого воображения?
ARK>>Можешь продемонстрировать это?
S>Демонстрировал последним примером.

Ты продемонстрировал создание обертки. Смотри, я тоже так могу:

void putStrLn1() { Console.WriteLine("querty"); }

void Main()
{
    putStrLn1();
    putStrLn1();
}

Look ma, я закешировал Console.WriteLine!

UPD. Я понимаю, что это немного другое. Но суть та же — результатом "кеширования" putStr является отложенное действие.

S>>>С этим я не согласен. Тут уже находились любители измерять грязь по машинному коду. Ты предлагаешь измерять ее по вычислителю. Этого нет смысла, вычислитель может залить все грязью, даже не видя исходник функции. Какой смысл в таком критерии?
ARK>>Смысл в этом критерии такой: он позволяет отделить зерна от плевел. Понять, где проходит граница чистоты.
S>В твоем критерии не понять, где проходит граница, т.к. можно сделать чистым и грязным даже отсутствие функции. Т.е. это не зависит от наличия функции. Остается понять, причем тут вообще функция и ее чистота?

Мой критерий НЕ зависит от окружения. Вообще. Даже если совсем НЕТ никакого окружения, даже если нет ни компилятора, ни даже компьютера — мой критерий дает четкое определение, чиста функция или нет.

S>>>Видишь лист бумаги? Думаешь, он белый? А я возьму красный фильтр и докажу что он красный. Именно это ты предлагаешь с фальсификацией окружения. Смысла в этом 0.
ARK>>И ты совершенно прав. Белый, красный, чистый, грязный — это неформальные ощущения. Квалиа, как любит говорить один местный гражданин. А формально другое — длина волны, частота излучения и т.п. И даже там на самом низком уровне приходится прибегать к аксиоматике — потому что в любом случае ты упираешься в базовые понятия, которые не выразимы ни через что.
ARK>>Однако я вижу, что тебе не нравятся формальные рассуждения, тебе ближе варианты со "здравым смыслом".
S>Не вижу смысла уделять время формальным рассуждениям за гранью смысла. Если тебе нравится рассуждать о такой чистоте, когда любая функция может быть и чиста и грязна одновременно, включая тождественную, то и оставлю тебя с этими рассуждениями.

Мне нравится такое определение, которое не требует внешних зависимостей от окружения.

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

ARK>>>>"Находясь, разумеется, внутри не-IO функции."
ARK>>>>putStrLn1 — это IO, разве нет?
S>>>это IO, но это не функция.
S>Формально — нет. Что такое функция? Грубо — соответствие между элементами двух множеств. Здесь мы имеем ровно один элемент, который не соответствует ничему.

Функция из unit в unit?

ARK>>Я это хотел выяснить у Sinclair, он ведь считает putStr чистой. Я не знаю способов кеширования putStr (отличных от способов "кеширования" printf).
S>И я putStr считаю чистой. И тоже не назову других способов. Так что не так с кэшированием?

Тогда эти функции эквивалентны в разрезе кеширования.

ARK>>То же самое можно сделать с printf.
S>Никто не утверждал обратного. Можно завернуть printf с параметрами в лямбду и кэшировать. Но это не делает саму printf чистой, разумеется. Обертка может быть чиста.

Не вижу отличий между кешированием завернутой в лямбду printf и вызовом putStr. Оно есть? Если нет, то получается, что кеширование не может быть признаком чистоты?

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

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

S>>putStr не принимает мир и не возвращает его. Она принимает string и возвращает трансформацию мира, не сам мир.
A>Трансформатор мира это функция, явно принимающая мир и возвращающая новый, имененный мир.
A>Хотя согласен, слово "явно" тут неоднозначно. То, что "IO a" это обертка для такой функции, как раз спрятано, чтобы нельзя было сохранять World в переменной.

S>>Переменных в языке нет, "инстанс" мира — абстрактный тип. Какие еще трюки нужны?
A>Термин "переменная" все же используется и для именованных констант.
A>Если бы "IO a" был определен как
A>

A>type IO a  =  World -> (a, World)
A>

A>то можно было бы делать такое:
A>

A>main world0 = let (a, world1) = putStr "Hello" world0
A>                  (b, world2) = putStr "World" world1
A>                  (c, world3) = putStr "Rsdn" world1 -- world1!
A>              in ((), world3)
A>

A>с неочевидным поведением.
A>Впринципе, раз world2 не нужен для вычисления world3, который мы возвращаем, то и выполнять вторую строчку не требуется, так что результатом работы программы должен бы быть вывод "Hello Rsdn".
Согласен.

A>Функциональной чистоты мы не нарушим, если World сделать доступным. Но все же было бы полезно такое запретить.

A>Еще "IO a" мог бы быть просто контейнером для мира
A>

A>type IO a  =  (a, World)
A>

A>Тогда тип putStr был бы String -> IO a -> IO ()
A>Тип main был бы IO () -> IO ()
A>Никакой "отложенности выполнения с возвратом якобы грязной лямбды, принимающей на вход грязный мир" бы небыло, но функция main, тем не менее, была бы чистой.

A>Фишка в том, что функции, взаимодействующие с миром (putStr, getChar и т.п.) на самом деле формально являются чистыми. И оставались бы чистыми, даже если World передавался явно, даже первым параметром.
Ну т.е. IO на функторе, вместо монады. Я думаю, что это возможно, но сложнее было бы связывать вычисления.

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

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

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

Уверен?

https://tour.dlang.org/tour/en/gems/functional-programming

Думаешь, запрет на изменение глобального состояния касается лишь переменных?

ARK>>>Это не "проверка чистоты", а демонстрация как минимум неполноты определения чистоты из википедии, если оно претендует на статус формального определения.
S>>Какое отношение к чистоте функции имеет твоя демонстрация грязного вычислителя?

ARK>Это не демонстрация грязного вычислителя. Это демонстрация влияния окружения. Отношение к определению чистоты оно имеет самое прямое, поскольку это определение непосредственно опирается на эффекты окружения.

Прости, конечно, но разве в D исключены эффекты окружения, введенные вычислителем?

S>>>>Немного не так. Я смотрю на контракт, чист ли он? Если синус отличается от своего контракта, то это проблема частной реализации синуса, а не контракта. Если это так — возьму другой.
ARK>>>Под словом "контракт" ты понимаешь здесь сигнатуру конкретной функции, описание конкретной функции или что-то иное?
S>>В том числе сигнатуру, описание, не портит ли функция GetLastError()?

ARK>Функций в мире много. Ты всегда проверяешь все инварианты всех функций? Соответствует ли название функции тому, что она делает? Не перепутаны ли местами x и y в функции DrawPoint?
ARK>Или, может, ты доверяешь сигнатуре и/или документации?
Смысл проверять чистоту DrawPoint, если она меняет canvas? И если возвращает новый, оставляя старый нетронутым по декларации, то тоже какой смысл?

S>>Так это лишь пример того, что чистота функции не распространяется автоматом на вычислитель.

ARK>Это окружение, а не вычислитель. Если бы это был вычислитель, то и в С все функции были бы чистыми. Окружение "работает" всегда, и до вычислителя (если он есть), и во время, и после.
Ну или окружение. Тут синус, понимаешь, вычисляется, а здесь кофе пролили на клаву. Мухи налетели.

S>>Нет, не как в хаскеле. В хаскеле генерация действия отделена от его выполнения. Это и позволяет кэшировать результаты IO функций, и потом выполнять их.

ARK>Ты пока не продемонстрировал этого отделения. То, что ты продемонстрировал, может быть повторено на любом грязном императивном языке.
Так я и не утверждал, то хаскель делает что-то, что нельзя повторить на любом грязном и императивном языке. Я даже демонстрировал, как putStr мог бы выглядеть на C#.

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

ARK>Sinclair написал конкретное определение чистоты в его понимании (которое совпадает с моим, кстати):

ARK>

ARK>1. Функция является грязной, если она принимает IO среди своих аргументов.
ARK>2. Функция, вызывающая грязную, является грязной.
ARK>Всё. Все остальные функции — чистые.

Sinclair имел ввиду "Функция является грязной, если она принимает Мир среди своих аргументов.", он не посмотрел сигнатуру putStr и думал, что IO это контейнер для Мира, а не его транформатор.
Но если функция принимает Мир, но не возвращает новое состояние Мира, то эта функция никак не сможет изменить этот Мир, т.е. никакого ввода-вывода она на самом деле делать не сможет. Функция main возвращает конечное состояние Мира и вычислятся будет только то, от чего оно зависит. Если вышеупомянутая функция не возвращает Мир, то ее ветка модификаций Мира не сможет быть выполнена.

Формально в Хаскеле все I/O функции являются чистыми.
"Но мы-то знаем (C)", что это всего лишь хитрый математический трюк, позволяющий представить функции, взаимодействующие с изменяемым миром, в виде чистых функций.

Если учесть то, что "мы-то знаем" и переопределить "грязность" функции как ее возможность иметь побочные эффекты в виде транформации Мира либо если результат ее вычисления зависит от состояния Мира, то в Хаскелях будет возможно такое определение:
1. Функция НЕ является "грязной", если она не возвращает IO
Все остальные функции потенциально "грязные".

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

ARK>>Ну, разработчики D как минимум не используют определение чистоты из википедии.
ARK>>На мой взгляд, тот подход, который у них, вполне соответствует моему пониманию чистоты. Впрочем, я не настаиваю, это для меня не очень важно. Важнее отказ от википедийного определения.
S>Уверен?

Угу: https://dlang.org/spec/function.html#pure-functions

As a concession to practicality, a pure function can also:

read and write the floating point exception flags
read and write the floating point mode flags, as long as those flags are restored to their initial state upon function entry
perform impure operations in statements that are in a ConditionalStatement controlled by a DebugCondition.

ARK>>>>Это не "проверка чистоты", а демонстрация как минимум неполноты определения чистоты из википедии, если оно претендует на статус формального определения.
S>>>Какое отношение к чистоте функции имеет твоя демонстрация грязного вычислителя?
ARK>>Это не демонстрация грязного вычислителя. Это демонстрация влияния окружения. Отношение к определению чистоты оно имеет самое прямое, поскольку это определение непосредственно опирается на эффекты окружения.
S>Прости, конечно, но разве в D исключены эффекты окружения, введенные вычислителем?

D не полагается на вычислитель при определении чистоты. В D функция чиста, если имеет модификатор "pure".

S>>>>>Немного не так. Я смотрю на контракт, чист ли он? Если синус отличается от своего контракта, то это проблема частной реализации синуса, а не контракта. Если это так — возьму другой.
ARK>>>>Под словом "контракт" ты понимаешь здесь сигнатуру конкретной функции, описание конкретной функции или что-то иное?
S>>>В том числе сигнатуру, описание, не портит ли функция GetLastError()?
ARK>>Функций в мире много. Ты всегда проверяешь все инварианты всех функций? Соответствует ли название функции тому, что она делает? Не перепутаны ли местами x и y в функции DrawPoint?
ARK>>Или, может, ты доверяешь сигнатуре и/или документации?
S>Смысл проверять чистоту DrawPoint, если она меняет canvas? И если возвращает новый, оставляя старый нетронутым по декларации, то тоже какой смысл?

Я не про чистоту DrawPoint, а в общем — про контракты функций. Чистота — один частный случай. Вопрос был — ты что, проверяешь вообще всё, все аргументы и все эффекты всех функций? Если нет, то почему тебе недостаточно просто сигнатуры и/или документации для того, чтобы рассуждать о чистоте функции?

S>>>Так это лишь пример того, что чистота функции не распространяется автоматом на вычислитель.
ARK>>Это окружение, а не вычислитель. Если бы это был вычислитель, то и в С все функции были бы чистыми. Окружение "работает" всегда, и до вычислителя (если он есть), и во время, и после.
S>Ну или окружение. Тут синус, понимаешь, вычисляется, а здесь кофе пролили на клаву. Мухи налетели.

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

S>>>Нет, не как в хаскеле. В хаскеле генерация действия отделена от его выполнения. Это и позволяет кэшировать результаты IO функций, и потом выполнять их.
ARK>>Ты пока не продемонстрировал этого отделения. То, что ты продемонстрировал, может быть повторено на любом грязном императивном языке.
S>Так я и не утверждал, то хаскель делает что-то, что нельзя повторить на любом грязном и императивном языке. Я даже демонстрировал, как putStr мог бы выглядеть на C#.

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

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

A>Sinclair имел ввиду "Функция является грязной, если она принимает Мир среди своих аргументов.", он не посмотрел сигнатуру putStr и думал, что IO это контейнер для Мира, а не его транформатор.

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

A>Формально в Хаскеле все I/O функции являются чистыми.
A>"Но мы-то знаем (C)", что это всего лишь хитрый математический трюк, позволяющий представить функции, взаимодействующие с изменяемым миром, в виде чистых функций.

Вокруг этого трюка весь сыр-бор. Формально можно точно так же утверждать, что в С все функции тоже чистые, просто имеют неявный скрытый параметр "мир" на входе (или, аналогично хаскелю, возвращают IO-действия). Просто в хаскеле IO — это подмножество всех функций, а в С — это будут вообще все функции, без исключения. Ура, язык С — чист, как хаскель.

A>Если учесть то, что "мы-то знаем" и переопределить "грязность" функции как ее возможность иметь побочные эффекты в виде транформации Мира либо если результат ее вычисления зависит от состояния Мира, то в Хаскелях будет возможно такое определение:
A>1. Функция НЕ является "грязной", если она не возвращает IO
A>Все остальные функции потенциально "грязные".

Да, на мой взгляд все верно. Но samius с этим не согласится.

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

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

S>>Функция id принимает все, что угодно, в том числе IO. Т.е. на ответ, принимает ли она IO, можно смело кивать.

ARK>Sinclair написал конкретное определение чистоты в его понимании (которое совпадает с моим, кстати):

ARK>

ARK>1. Функция является грязной, если она принимает IO среди своих аргументов.
ARK>2. Функция, вызывающая грязную, является грязной.
ARK>Всё. Все остальные функции — чистые.

С этим я не согласен, т.к. пункт 1 делает id грязным.

ARK>Твоя функция id НЕ удовлетворяет описанию грязной функции из этого определения.
Удовлетворяет, т.к. принимает IO. Но она чистая. Привести пример на хаскеле о том, что id принимает IO?

А вот, кстати, putStr этому определению не удовлетворяет, т.к. 1) не принимает IO. 2) не вызывает грязные функции. Следовательно, мне непонятно, почему ты называешь ее грязной даже по своему определению.

S>>Демонстрировал последним примером.

ARK>Ты продемонстрировал создание обертки. Смотри, я тоже так могу:
Никакой обертки я не создавал. Я взял значение типа IO() и дал ему имя.

ARK>

ARK>void putStrLn1() { Console.WriteLine("querty"); }

ARK>void Main()
ARK>{
ARK>    putStrLn1();
ARK>    putStrLn1();
ARK>}
ARK>

ARK>Look ma, я закешировал Console.WriteLine!
Но это не есть закэшировал. Это именно что обертка. Аналог хаскеля был бы таким

Action putStrLn1 = () => Console.WriteLine("query");

ARK>UPD. Я понимаю, что это немного другое. Но суть та же — результатом "кеширования" putStr является отложенное действие.
Но у тебя оно именно что не отложенное.

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

ARK>Мой критерий НЕ зависит от окружения. Вообще. Даже если совсем НЕТ никакого окружения, даже если нет ни компилятора, ни даже компьютера — мой критерий дает четкое определение, чиста функция или нет.

да, четкое. Пример — id.

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

ARK>Мне нравится такое определение, которое не требует внешних зависимостей от окружения.
А разве определение в википедии требует? Разве оно как-то намекает на то, что оператор сложения стал грязным от того, что грязное окружение фиксирует изменения регистров процессора? Или что если консоль перенаправили в dev/null, то это сделало любой консольный вывод чистым?
По-моему это плоды твоих формальных рассуждений. И только лишь.