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

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

S>>В определении полиморфизма нет ни слова о времени компиляции и вообще компиляции.

K>Это, конечно, верно. И в языке, на котором нет возможности написать код такого типа, как обсуждаемый здесь (какой-нибудь ML, с оговорками) параметрический полимoрфизм вполне можно реализовать c помощью кодогенерации и анализа всей программы (как в каком-нибудь MLton, с оговорками). Раздельную компиляцию мы потеряем, но иначе как в длительности компиляции это не проявится. Написать код, который вроде бы должен тайпчекаться, при условии что у нас есть ПП, но не тайпчекается мы не можем. А не пойман — не вор. Не будь в C++ сабтайпинга — обнаружить указанную проблему было бы невозможно. По крайней мере таким способом. Ну а проблемы с раздельной компиляцией без каких-то семантических эффектов на уровне языка — это просто детали реализации и говорить о проблемах с ПП повода не дают.
Да. Понятно. Просто увидел много слов на тему компиляции и подумал, что упор на нее.

S>>Т.е. в C# нет ПП потому что джитится?

K>Нет, почему же? В C# ПП есть, а то, что JIT генерирует специализации для value-типов — это деталь реализации. Это просто был контрдовод против утверждения Tonal- (довольно странного), что ПП может работать только при условии динамической компиляции специализаций или интерпретации. Это, разумеется, не верно.
Согласен.
Все-таки, хотелось бы понять, почему вы считаете что в C# ПП есть, а в C++ нет? Предлагаю взять тривиальную функцию id и посмотреть на нее безотносительно времени компиляции/джита в контексте утвреждения

Но в c++ параметрического полиморфизма нет — там не бывает кода для любого типа

Что в C++, что в C#, найдутся типы, для которых id работать (и даже компилироваться) не будет.

Здравствуйте, Паблик Морозов, Вы писали:

ПМ>Старнное заявление в разделе /decl. Вроде у всех более-менее декларативных и функциональны эзыков синтаксис весьма далёк от сишкоподобного. Если, конечно, это не эрзацы вроде Скалы или Менерле.

Дык все эти ваши языки и вымрут как динозавры, не оставив потомства.

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

_>Теперь даже и не знаю где искать новую "серебряную пулю" для фана. Ну а о замене основных инструментов похоже пока даже и речи нет...

Серебряных пуль (панацеи) не бывает.

А для фана можешь попробовать нашу "игрушку". Она и изучается намного легче (людьми пришедшими из императивного мира), и в сто раз более практична.

Для практического использования тебе может не подойти дотнет. Но для изучения оно точно будет полезен. К тому же мы намереваемся сделать язык мультиплатфорным в будущем.

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

VE>>А хард — это ввод-вывод? А USB-вентилятор? А вентилятор внутри системного блока? А нагревательный USB-прибор? А нагревательный прибор "процессор" внутри системного блока?
S>Если программа посылает данные USB вентилятору, то это определенно вывод. Если принимает — определенно ввод. С другими девайсами аналогично.

А если программа посылает данные в оперативную память? А потом принимает. А потом результат получается детерминированный.
А со стороны сидит Вася и смотрит на эту всю чехарду с памятью, наблюдает, как туда-сюда данные бегают. Это ввод-вывод?
А если "оперативная память" находится на удалённом компьютере и мы шлём прямо такие команды "read 0x10", "write 0x10 2", а результат всё равно детерминированный (про подмену значений не надо упоминать, их и в памяти на текущем компе менять можно). Это ввод-вывод?

VE>>Какое-то интуитивное понятие, не формализованное.
S>Да, и что?

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

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

Речь не о детерминированности. Если я рядом напишу математическое доказательство "мамой клянус", что голубь не наврёт, то пусть он будет и детерминированным, но всё равно с вводом-выводом же в твоём понимании, ибо голуби летают туда-суда. Ты ещё скажи, что работа с оперативной памятью ни от чего не зависит, и потому у нас какие-то там гарантии. Зависит от тех же коршунов и погоды, но почему-то не ввод-вывод.
Но тогда в чём отличие от засирании оперативки при вычислении списка? Со стороны это видно, изнутри программы — нет.

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

VD>Дык все эти ваши языки и вымрут как динозавры, не оставив потомства.

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

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

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

VE>>>А хард — это ввод-вывод? А USB-вентилятор? А вентилятор внутри системного блока? А нагревательный USB-прибор? А нагревательный прибор "процессор" внутри системного блока?
S>>Если программа посылает данные USB вентилятору, то это определенно вывод. Если принимает — определенно ввод. С другими девайсами аналогично.

VE>А если программа посылает данные в оперативную память? А потом принимает. А потом результат получается детерминированный.
В википедии все написано. процессор и память процесса считаются внутренностями программы.
VE>А со стороны сидит Вася и смотрит на эту всю чехарду с памятью, наблюдает, как туда-сюда данные бегают. Это ввод-вывод?
Зависит от того, в чью память данные бегают.
VE>А если "оперативная память" находится на удалённом компьютере и мы шлём прямо такие команды "read 0x10", "write 0x10 2", а результат всё равно детерминированный (про подмену значений не надо упоминать, их и в памяти на текущем компе менять можно). Это ввод-вывод?
судя по википедии — да. Во всяком случае для программы, выполняющейся на конкретном компьютере. Если рассматривать систему из множества компьютеров как одну, то обмен данными между ними не будет считаться вводом/выводом. Но это уже я додумываю.

VE>>>Какое-то интуитивное понятие, не формализованное.
S>>Да, и что?

VE>Ну ничаво. Тогда вы до гробовой доски не договоритесь. Я вот включение вентилятора считаю ничем не отличающимся от нагрева проца. Человек видит результат обоих действий, программа — не видит (если нет функции включенЛиВентилятор, например). С т.з. программы и человека между этими действиями отличия нет. Так почему одно ввод-вывод, а другое — нет?
Ни нагрев процессора, ни включение вентилятора не является вводом/выводом в случае, если программа не управляет включением вентилятора посылкой специальных команд.
Если рассмотреть систему, в которой отправка данных во внешний мир осуществляется с помощью включения/выключения вентилятора и аналога азбуки Морзе, то я согласен рассматривать нагревание проца для включения вентилятора вводом/выводом.

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

VE>Речь не о детерминированности. Если я рядом напишу математическое доказательство "мамой клянус", что голубь не наврёт, то пусть он будет и детерминированным, но всё равно с вводом-выводом же в твоём понимании, ибо голуби летают туда-суда.
Окей, ты просто вместо "мамой клянус" напиши что ты вместо обычной детерминированности подразумеваешь голубинную детерминированность и доказывать ничего не надо будет. А если не написал, то по умолчанию под детерминированностью будет считаться то, о чем пишут в википедии, или каком другом общедоступном источнике. Можно поговорить о том, в каком именно источнике описано определение, которое бы тебя устроило.

VE>Ты ещё скажи, что работа с оперативной памятью ни от чего не зависит, и потому у нас какие-то там гарантии. Зависит от тех же коршунов и погоды, но почему-то не ввод-вывод.
VE>Но тогда в чём отличие от засирании оперативки при вычислении списка? Со стороны это видно, изнутри программы — нет.
Память процесса считается внутренним хозяйством программы по википедии, потому обмен данными с ней не считается вводом/выводом. Конечно, если речь не идет об MMF или обменом данными с памятью другого процесса.

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

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

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

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

VE>>А со стороны сидит Вася и смотрит на эту всю чехарду с памятью, наблюдает, как туда-сюда данные бегают. Это ввод-вывод?
S>Зависит от того, в чью память данные бегают.

В обе. Две памяти, одна снаружи, другая внутри. В какую именно полетят данные — решает ОСь, а не программа. Причём внешняя память вся представлена на табло, на которое смотрит Вася.

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

Чем дальше в лес, тем больше придётся додумывать, поэтому это определение непрактично и не нужно. С ним только во флеймы скатываться подобные текущему.

S>Ни нагрев процессора, ни включение вентилятора не является вводом/выводом в случае, если программа не управляет включением вентилятора посылкой специальных команд.

А если вентилятор включается, но по каким-то косвенным причинам? Т.е. программа вычисляет себе список, вдруг бац! Выводится hello, включается вентилятор, но программа этого явно не просила, хотя знала, что такое может произойти (как и выделение памяти), даже программист знал (как и в случае с памятью). Это тогда что?

S>Окей, ты просто вместо "мамой клянус" напиши что ты вместо обычной детерминированности подразумеваешь голубинную детерминированность и доказывать ничего не надо будет.

Не, предположим, я математически доказал, что голубь никогда не допустит ошибки (это ж всё же пример), и будет такая математическая детерминированность.

S>Память процесса считается внутренним хозяйством программы по википедии, потому обмен данными с ней не считается вводом/выводом. Конечно, если речь не идет об MMF или обменом данными с памятью другого процесса.

Ну если разобрать компьютер и разложить всё на ковре, то что является внутренностью? Вставленная в мать память — внутренняя, а подсоединённая через USB — уже нет? А в чём разница? Допустим, внутри программы мы не знаем, какой памятью пользуемся, там мы просто вычисляем список.

S>Видишь, я практически ничего не выдумываю и призываю оппонентов к тому же. Тем не менее, у каждого второго на rsdn свое понимание и определение чистоты. А один даже считает чистыми функции, которые явно изменяют свои мутабельные аргументы.

Поэтому я и написал, что определение чистоты бессмысленно. Есть referential transparency, его и надо использовать.

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

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

VE>>>А со стороны сидит Вася и смотрит на эту всю чехарду с памятью, наблюдает, как туда-сюда данные бегают. Это ввод-вывод?
S>>Зависит от того, в чью память данные бегают.

VE>В обе. Две памяти, одна снаружи, другая внутри. В какую именно полетят данные — решает ОСь, а не программа. Причём внешняя память вся представлена на табло, на которое смотрит Вася.
Можно развести такую же философию вокруг темы "являются ли внутренние органы внутренними, если мы можем их наблюдать снаружи".
Я полагаю, что имеет значение то, взаимодействует ли программа с данными вне ее, а не то, видим ли мы внутреннее состояние памяти программы или нет.

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

VE>Чем дальше в лес, тем больше придётся додумывать, поэтому это определение непрактично и не нужно. С ним только во флеймы скатываться подобные текущему.
Такое ощущение, что из всего моего ответа ты увидел лишь слово "додумываю".

S>>Ни нагрев процессора, ни включение вентилятора не является вводом/выводом в случае, если программа не управляет включением вентилятора посылкой специальных команд.

VE>А если вентилятор включается, но по каким-то косвенным причинам? Т.е. программа вычисляет себе список, вдруг бац! Выводится hello, включается вентилятор, но программа этого явно не просила, хотя знала, что такое может произойти (как и выделение памяти), даже программист знал (как и в случае с памятью). Это тогда что?
Я же ответил. Могу еще раз. Косвенное включение вентилятора при нагреве процессора/чего хочешь не является посылкой данных вовне. Естественно, без специальных оговорок по поводу обратного. Хочешь рассматривать включение вентилятора сайд эффектом — пожалуйста. Только не забудь сказать об этом коллегам.

VE>Не, предположим, я математически доказал, что голубь никогда не допустит ошибки (это ж всё же пример), и будет такая математическая детерминированность.
Если ты доказал такое, то осталось еще доказать что обмен данными с голубем не является вводом/выводом. Хотя, можно не доказывать, можно просто задекларировать такое. Заяви что голубь — такая же внутренность программы, как регистр процессора или ячейка памяти.

S>>Память процесса считается внутренним хозяйством программы по википедии, потому обмен данными с ней не считается вводом/выводом. Конечно, если речь не идет об MMF или обменом данными с памятью другого процесса.

VE>Ну если разобрать компьютер и разложить всё на ковре, то что является внутренностью? Вставленная в мать память — внутренняя, а подсоединённая через USB — уже нет? А в чём разница? Допустим, внутри программы мы не знаем, какой памятью пользуемся, там мы просто вычисляем список.
Я же написал про память процесса. Память процесса может быть размазана по туче реальных девайсов, в том числе USB. Любые кэши, влоть до кэша винта, все что отвечает за работу программы — будет иметь отношение к памяти процесса. Но не в полном объеме. Т.е. сейчас программу обслуживают адреса такие, через секунду — другие. Впрочем, для программы это обычно прозрачно, и она не указывает системе, какие адреса ей нужны. Потому, довольно легко понять, что является посылкой данных вовне, а что — нет. У меня, во всяком случае, вопросов нет.

S>>Видишь, я практически ничего не выдумываю и призываю оппонентов к тому же. Тем не менее, у каждого второго на rsdn свое понимание и определение чистоты. А один даже считает чистыми функции, которые явно изменяют свои мутабельные аргументы.

VE>Поэтому я и написал, что определение чистоты бессмысленно. Есть referential transparency, его и надо использовать.
То что оно бессмысленно — ты пиши не мне, а тем, кто им активно пользуется. В том числе авторам кучи книжек. Я не собираюсь спорить с тобой по поводу пользы этого определения. Я сам много лет не подозревал о его существовании, и ничего, пока жив.
Что касается referential transparency. Ну что же, давай обсудим referential transparency действий хаскеля, но не их комбинирования. Только для начала предлагаю ознакомиться с определениями, вики и т.п.
Например, тут определения нет, но понимание этого термина автора жестко завязано на side effect-ы, которые для твоего понимания представляют проблему.

Как я понимаю, основным определением является возможность замены выражения значением с сохранением поведения (yielding a program that has the same effects and output on the same input). Если есть другие предложения — давай рассмотрим их. Что касается этого определения referential transparency — не вижу повода считать, что действия в хаскеле прозрачны. Например, действие, полученное в результате writeFile мы можем заменить кортежем со значением мира после этого действия. Но я протестую против того, что бы считать файл на диске (который должен образоваться) частью этого значения. Т.е. при такой замене эффекты не сохраняются, значит действие, полученное из writeFile, не ссылочно прозрачно. Однако, комбинирование действий обладает такой прозрачностью.

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

VD>А для фана можешь попробовать нашу "игрушку". Она и изучается намного легче (людьми пришедшими из императивного мира), и в сто раз более практична.

VD>Для практического использования тебе может не подойти дотнет. Но для изучения оно точно будет полезен. К тому же мы намереваемся сделать язык мультиплатфорным в будущем.

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

Для дела же мне сейчас больше всего нравятся императивные языки с возможностями функциональности, метапрограммирования и т.п. Типа C++11, а лучше D и т.п.

Немерле посмотрю. ) Хотя пока не понял его ориентированность. Т.е. понятно что везде можно извернуться, но допустим на Питоне мы пишем скрипты (внутренние и серверные), но не большие проекты. А на C++ скрипты не пишем, хотя это возможно в теории.. Вот для чего Немерле лучше?

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

_>Для дела же мне сейчас больше всего нравятся императивные языки с возможностями функциональности, метапрограммирования и т.п. Типа C++11, а лучше D и т.п.

Дык в этом случае Nemerle идеален. Развитое ФП, императивность и мощный метапрограмминг. Уж явно лучше C++, D и т.п.

_>Вот для чего Немерле лучше?

Для всего он лучше, чем C++ и D с учётом .Net

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

S>Все-таки, хотелось бы понять, почему вы считаете что в C# ПП есть, а в C++ нет? Предлагаю взять тривиальную функцию id и посмотреть на нее безотносительно времени компиляции/джита в контексте утвреждения

В языке с ПП id имеет тип forall a. a -> a множество типов, к которым мы можем применить такое выражение (потенциально) бесконечно. В случае C++ это не так. Множество конечно. Для того, чтоб наблюдать на практике отличия между этими случаями нужно иметь возможность организовать тайплевел-вычисления, которые тут обсуждаются.

S>Но в c++ параметрического полиморфизма нет — там не бывает кода для любого типа

S>Что в C++, что в C#, найдутся типы, для которых id работать (и даже компилироваться) не будет.

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

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

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

S>>Все-таки, хотелось бы понять, почему вы считаете что в C# ПП есть, а в C++ нет? Предлагаю взять тривиальную функцию id и посмотреть на нее безотносительно времени компиляции/джита в контексте утвреждения

K>В языке с ПП id имеет тип forall a. a -> a множество типов, к которым мы можем применить такое выражение (потенциально) бесконечно. В случае C++ это не так. Множество конечно.
Конечно потому что ... ?
Я не понимаю. Я могу (потенциально) написать id в foo.h и использовать его в бесконечном количестве программ по одному разу. Где конечность? Почему это конечнее, чем в haskell?

K>Для того, чтоб наблюдать на практике отличия между этими случаями нужно иметь возможность организовать тайплевел-вычисления, которые тут обсуждаются.
Практика — это хорошо, но определение ПП не требует тайплевел-вычислений в рантайме.

K>

S>>Но в c++ параметрического полиморфизма нет — там не бывает кода для любого типа

S>>Что в C++, что в C#, найдутся типы, для которых id работать (и даже компилироваться) не будет.

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

Так же и в C# есть типы, с которыми полиморфизм не работает. Кайндов нет, а типы, с которыми ПП не работает, есть . Тем не менее, C# считается ПП языком.

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

S>Я могу (потенциально) написать id в foo.h и использовать его в бесконечном количестве программ по одному разу.

Нет. Не в (потенциально) бесконечном кол-ве программ. Так разницу не обнаружить. А в одной программе для (потенциально) бесконечного кол-ва типов. Как в примере выше.

K>>Для того, чтоб наблюдать на практике отличия между этими случаями нужно иметь возможность организовать тайплевел-вычисления, которые тут обсуждаются.
S>Практика — это хорошо, но определение ПП не требует тайплевел-вычислений в рантайме.

Ну да, не требует. Да и практика не требует тайплевел-вычислений в рантайме. Какой тайплевел в рантайме? Может вы тоже считаете, что обсуждаемый тут код на haskell/java/c# в рантайме тайпчекается?

S>Так же и в C# есть типы, с которыми полиморфизм не работает. Кайндов нет, а типы, с которыми ПП не работает, есть .

Кайнды в C#, разумеется, есть. Например value-type и ref-type.

S>Тем не менее, C# считается ПП языком.

Потому, что число конкретных типов, которые работают с полиморфным определением (потенциально) бесконечно.

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

S>Что за чудеса? Мир — внутренний объект программы, файл — внешний.

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

S>этак можно сказать что fprintf принимает неявно внешний мир и возвращает длину строки и новый мир с файлом.

Можно, только без возможности сохранить уникальность мира — толку от этого нет и использовать это никак нельзя.

S>Речь о том, что акция может не быть чистой не потому что уникальность мира, а потому что она делает ввод/вывод.

Но если она делает ввод/вывод не нарушая прозрачность по ссылкам — она может быть чистой. И не просто может — она такая и есть.

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

VE>Дык в этом случае Nemerle идеален. Развитое ФП, императивность и мощный метапрограмминг. Уж явно лучше C++, D и т.п.

Остались ещё требования: быстродействие (в разумных пределах), доступ к системным функциям, возможность подключения (или наличие большого числа биндингов как у Питона) к C/C++ библиотекам.

_>>Вот для чего Немерле лучше?

VE>Для всего он лучше, чем C++ и D с учётом .Net

.Net в моих глазах — это недостаток. Для дела естественно, a для "фана" пофиг. Но вроде бы же говорят что планируется Немерле для нейтива.

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

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

S>>Я могу (потенциально) написать id в foo.h и использовать его в бесконечном количестве программ по одному разу.

K>Нет. Не в (потенциально) бесконечном кол-ве программ. Так разницу не обнаружить. А в одной программе для (потенциально) бесконечного кол-ва типов. Как в примере выше.
Определение ПП не требует (потенциально) бесконечного кол-ва типов. Оно требует лишь отсутствия кода специализации, (либо кода, который уже специализирован) для любого типа (наверное, с оговорками).

K>>>Для того, чтоб наблюдать на практике отличия между этими случаями нужно иметь возможность организовать тайплевел-вычисления, которые тут обсуждаются.
S>>Практика — это хорошо, но определение ПП не требует тайплевел-вычислений в рантайме.

K>Ну да, не требует. Да и практика не требует тайплевел-вычислений в рантайме. Какой тайплевел в рантайме? Может вы тоже считаете, что обсуждаемый тут код на haskell/java/c# в рантайме тайпчекается?
Нет. Тут я о возможности получать экземпляры типов, которые не были инстанциированы при компиляции.

S>>Так же и в C# есть типы, с которыми полиморфизм не работает. Кайндов нет, а типы, с которыми ПП не работает, есть .

K>Кайнды в C#, разумеется, есть. Например value-type и ref-type.
Не понимаю, какое отношение value-type и ref-type имеют к кайндам.

S>>Тем не менее, C# считается ПП языком.

K>Потому, что число конкретных типов, которые работают с полиморфным определением (потенциально) бесконечно.
Чем оно бесконечнее, чем в C++? И где в определении ПП упоминается бесконечность? Еще раз, там об отсутствии специализации для конкретных типов.

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

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

S>>Что за чудеса? Мир — внутренний объект программы, файл — внешний.

K>Ох... файл в программе такой же в точности "внутренний объект", что и мир.
файла в программе нет. как объекта, во всяком случае. а "мир"-а нет снаружи.

K> Почему этот модельный "мир" такие странные вопросы вызывает? Ну пусть будет не мир, допустим, а TimeStamp и уникальность нужна для сохранения "безпарадоксальной" истории, без всяких временных петель. Так лучше?
Потому что есть четкое представление о том что этот "модельный мир" это не модель и не мир. TimeStamp — лучше, но тот хотя бы несет информацию о времени, а функция мира — лишь служить эстафетной палочкой при вызове действий.
Но это не важно. Важно в контексте обсуждения то, что чем бы ни был мир внутри программы, файл снаружи программы (или улетевшие байты по сети) частью программы не являются, а значит программа осуществляет взаимодействие с внешним по отношению к программе миром. Раз так, то это input/output и плакала чистота.
Но я не понимаю, зачем нужно строить какие-то иллюзии вокруг модели мира внутри программы, если отсутствие чистоты действий не компрометирует хаскель как чистый язык?

S>>этак можно сказать что fprintf принимает неявно внешний мир и возвращает длину строки и новый мир с файлом.

K>Можно, только без возможности сохранить уникальность мира — толку от этого нет и использовать это никак нельзя.
уникакльность мира сама по себе не является целью. мир нужен только для организации последовательности выполнения действий. В C++ с этим никаких вопросов нет, т.к. последовательность обеспечивается ";".

S>>Речь о том, что акция может не быть чистой не потому что уникальность мира, а потому что она делает ввод/вывод.

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

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

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

Вообще говоря, мы можем запустить вычисление функции f от 10 в потоке, и в другом потоке мониторить выделенную память, тем самым определяя, вычисляется ли что-то реально, или подставляется готовое значение. При этом f чистая, а реализация вольна мемоизировать по своему усмотрению.
Если f использует всякие newSTRef, то она всё равно останется чистой, и вряд ли можно сказать, что компилятор не имеет права в (f 10, f 10) вычислить её лишь один раз. При этом мы таки можем при желании организовать возможность определить это, но на чистоту f это никак не влияет.

Поэтому я склонен считать, что даже если f посылает данные в сеть, но остается прозрачной по ссылкам (гарантированно, насколько это возможно), то её можно считать чистой и заменять на вычисленное значение.
Да, мы можем определить, шлёт ли она данные. Да, в ответ может прийти не то (как и в память могут подложить свинью).
Но посылка данных не её основная задача. Она именно что вычисляет факториал, а уж то, что она при этом делает, — неважно.

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

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

S>Определение ПП не требует (потенциально) бесконечного кол-ва типов.

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

S>Нет. Тут я о возможности получать экземпляры типов, которые не были инстанциированы при компиляции.

А где обсуждалась такая возможность? Когда они еще могут "инстанциироваться" (когда говорят о параметрических типах, правильнее все-таки говорить "применяются") если не при компиляции?

S>Не понимаю, какое отношение value-type и ref-type имеют к кайндам.

Прямое. Это типы типов.

S>Чем оно бесконечнее, чем в C++?

Тем, что обсуждаемый код с (потенциально) бесконечным числом типов на C# работает, а на C++ нет.

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

K>>Ох... файл в программе такой же в точности "внутренний объект", что и мир.
S>файла в программе нет. как объекта, во всяком случае.

Как нет? А во что вы пишете/ что читаете?

S>а "мир"-а нет снаружи.

Вот это да! Как же его, нет, когда есть. По крайней мере мне он в ощущениях задан.

S>Потому что есть четкое представление о том что этот "модельный мир" это не модель и не мир.

Почему не модель? От мира нам требуется только модель времени. Время (точнее, только упорядоченность событий) и моделируется.

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

Чем лучше? Названием?

S>Но я не понимаю, зачем нужно строить какие-то иллюзии вокруг модели мира внутри программы, если отсутствие чистоты действий не компрометирует хаскель как чистый язык?

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

S>>>этак можно сказать что fprintf принимает неявно внешний мир и возвращает длину строки и новый мир с файлом.

S>уникакльность мира сама по себе не является целью. мир нужен только для организации последовательности выполнения действий. В C++ с этим никаких вопросов нет, т.к. последовательность обеспечивается ";".

Не обеспечивается. Она неявная, никакими ; в коде не определяется.

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

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