Здравствуйте, m e, Вы писали:
ME>>>там четко написано "Portability : non-portable (GHC Extensions)", значит ты должен был ответить "мы говорим не о хаскеле, а о GHC Extensions" и не путать меня и окружающих
K>>Думаю, что окружающие в курсе, что "стандартный хаскель с расширениями" называется просто хаскель. А когда говорят о стандартном, всегда явно это указывают: haskell 98 или haskell 2010.
ME>очень, очень любопытно
ME>так хаскелем у тебя называется хаскель с какими расширениями? с расширениями любого из почти 10 компиляторов? или только с расширениями ghс? если так, то какого хрена такая дискриминация?
Учитывая, что ghc разрабатывается основным автором хаскелла и является по сути единственным активно используемым компилятором промышленного качества, то под хаскеллом обычно понимают текущую его реализацию в ghc (если только не говорят прямо haskell 98 / 2010).
Здравствуйте, samius, Вы писали:
VE>>А ты ответь, что понимаешь под semantically observable. S>Семантически обозримые эффекты — изменения, которые обнаружимы средствами языка. Типично для императивных языков — глобальные переменные, любые изменяемые состояния.
Ну осталось выяснить, что есть побочный эффект. Вывод строки функцией, единственной целью которой и является вывод строки, это побочный эффект или основной?
Здравствуйте, VoidEx, Вы писали:
VE>Здравствуйте, samius, Вы писали:
VE>Ну осталось выяснить, что есть побочный эффект. Вывод строки функцией, единственной целью которой и является вывод строки, это побочный эффект или основной?
Основным эффектом вычисления функции является то, что она возвращает в качестве результата. Все остальное — побочный.
Здравствуйте, samius, Вы писали:
VE>>Ну осталось выяснить, что есть побочный эффект. Вывод строки функцией, единственной целью которой и является вывод строки, это побочный эффект или основной? S>Основным эффектом вычисления функции является то, что она возвращает в качестве результата. Все остальное — побочный.
Ну и putStrLn, например, возвращает IO (). Для входного "test" всегда один и тот же. Значит, функция чистая?
Здравствуйте, VoidEx, Вы писали:
VE>Здравствуйте, samius, Вы писали:
S>>Основным эффектом вычисления функции является то, что она возвращает в качестве результата. Все остальное — побочный.
VE>Ну и putStrLn, например, возвращает IO (). Для входного "test" всегда один и тот же. Значит, функция чистая?
В точности так. одно и то же — значит детерминирована. Не портит окружающую среду при выполнении — значит без побочных эффектов. Чистая по формальному определению.
Здравствуйте, samius, Вы писали:
VE>>Ну и putStrLn, например, возвращает IO (). Для входного "test" всегда один и тот же. Значит, функция чистая? S>В точности так. одно и то же — значит детерминирована. Не портит окружающую среду при выполнении — значит без побочных эффектов. Чистая по формальному определению.
Здравствуйте, samius, Вы писали:
V>>Жалко, что ты не понимаешь моих объяснений )
S>Я их понимаю, я их не могу принять.
Так, похоже у нас просто разногласие в определениях.
Если считать, что ф-ия, занимающаяся внешним I/O, нечистая, то какая-нить getLine :: World -> (a, World) будет нечистой. Это твое мнение, исходящее из определения в википедии. Оке, при таком определении, getLine действительно нечистая.
Мое определение чистоты сильно короче. Чистая ф-ия возвращает один и тот же результат на одних и тех же аргументах. Всё. С таким определением getLine становится чистой, т.к. на одном и том же аргументе (мире, где пользователь вводит одну и ту же строку) ф-ия возвращает один и тот же результат, равно как и какой нить putLine на одом и том же мире и строке всегда возвращает один и тот же мир с добавленной строкой.
Т.е., если выбросить из определения детали про I/O, что, похоже, для тебя принципиально важно, то getLine чистая (мое мнение из моего определения чистоты), если же оставить, то грязная (твое мнение из твоего определения).
Здравствуйте, VoidEx, Вы писали:
VE>Здравствуйте, samius, Вы писали:
VE>>>Ну и putStrLn, например, возвращает IO (). Для входного "test" всегда один и тот же. Значит, функция чистая? S>>В точности так. одно и то же — значит детерминирована. Не портит окружающую среду при выполнении — значит без побочных эффектов. Чистая по формальному определению.
VE>А о чём тогда спор?
Спор о чистоте действия, которое возвращает putStrLn.
Моя позиция заключается в том, что действие IO a в общем случае не чисто. Я не исключаю существования чистых IO a, но то что заворачивается в IO a, как правило носит нечистый характер.
Результат getChar :: IO Char недетерминирован, т.к. принимает символ извне
Результат putStrLn :: IO () имеет побочный эффект — портит консоль в реальном мире.
Владимир считает что действия чисты, т.к. работают с World, который якобы представляет собой отражение реального мира. И нечистота этих действий не интересует программу изнутри программы.
Здравствуйте, vshabanov, Вы писали:
V>Здравствуйте, samius, Вы писали:
V>Так, похоже у нас просто разногласие в определениях.
Везет мне на разногласия в определениях.
V>Если считать, что ф-ия, занимающаяся внешним I/O, нечистая, то какая-нить getLine :: World -> (a, World) будет нечистой. Это твое мнение, исходящее из определения в википедии. Оке, при таком определении, getLine действительно нечистая.
(*)
все-таки getLine :: IO String является чистой.
А уж IO String, которая раскрывается в IO a :: World -> (a, World) нечистая. Мне кажется что ты понимаешь, о чем я, просто уточняю на всякий случай.
V>Мое определение чистоты сильно короче. Чистая ф-ия возвращает один и тот же результат на одних и тех же аргументах. Всё. С таким определением getLine становится чистой, т.к. на одном и том же аргументе (мире, где пользователь вводит одну и ту же строку) ф-ия возвращает один и тот же результат, равно как и какой нить putLine на одом и том же мире и строке всегда возвращает один и тот же мир с добавленной строкой.
Вот в этом и проблема. Это только твое определение, или кто-то еще им пользуется? На самом деле я на рсдн не первый раз встречаю форумчан с собственными определениями. И в отношении чистоты уже как минимум двое кроме тебя пользуются схожим с твоим определением чистоты. Но мне кажется что это неправильное определение, т.к. в литературе я его в таком виде не встречал.
V>Т.е., если выбросить из определения детали про I/O, что, похоже, для тебя принципиально важно, то getLine чистая (мое мнение из моего определения чистоты), если же оставить, то грязная (твое мнение из твоего определения).
V>Идет?
С поправкой выше (*) — идет.
V>Учитывая, что ghc разрабатывается основным автором хаскелла и является по сути единственным активно используемым компилятором промышленного качества, то под хаскеллом обычно понимают текущую его реализацию в ghc (если только не говорят прямо haskell 98 / 2010).
для обсуждения на форуме вполне нормально назвать хаскелем скажем ghc7-хаскель
но вот в качестве ответа на вопрос
ME>>ммм... а мы про хаскель говорим или про что?
называть хаскелем скажем ghc7-хаскель уже будет неверно
в мире с++ на аналогичный вопрос ответили бы "мы говорим о с++ с расширениями g++", а не "мы говорим о с++"; если бы кто-то начал выпендриваться, защищая название "с++" для g++, его бы быстро поставили на место
очень жаль, что такой дурной тон апологеты хаскеля пытаются защищать, забывая о стандартах
з.ы. "текущая" реализация -- это тоже недостаточно определенное понятие
Здравствуйте, samius, Вы писали:
S>Спор о чистоте действия, которое возвращает putStrLn.
А какая разница? Хаскель от этого грязнее не становится. А World — это какое-то божество, в Haskell непредставимое, содержащее информацию обо всей вселенной. Ну и сколлапсирует ли волновая функция в одно и то же при одинаковых World — это лишь вопрос веры.
Здравствуйте, VoidEx, Вы писали:
VE>Здравствуйте, samius, Вы писали:
S>>Спор о чистоте действия, которое возвращает putStrLn.
VE>А какая разница? Хаскель от этого грязнее не становится.
Разницы действительно никакой. И хаскель от этого не станет ни чище ни грязнее. Причем, позиция в этом вопросе никак качественно не повлияет на код реальных приложений. Это как в ситуации когда ОО-программисту с 15-летним стажем открывают глаза на тот факт что перегрузка методов тоже есть полиморфизм. Куча охов-ахов, флейма и т.п. Но по сути ничего не меняется.
VE>А World — это какое-то божество, в Haskell непредставимое, содержащее информацию обо всей вселенной. Ну и сколлапсирует ли волновая функция в одно и то же при одинаковых World — это лишь вопрос веры.
Не принимаю мистику в программировании. Я могу понимать что чего-то не понимаю, но заставлять себя думать что там божество не могу и не хочу. Тем более что в случае с World-ом — там лишь одна вывеска.
Здравствуйте, Klapaucius, Вы писали:
K>Нет. MigMit раньше исходил из ошибочного предположения, что в C++ есть параметрический полиморфизм. Но параметрический полиморфизм означает, что forall a. Box a описывает бесконечное кол-во типов. В C++ же кол-во типов всегда конечно, поэтому полиморфизм там только ad-hoc. Выяснив, как дела обстоят на самом деле, MigMit решил предостеречь остальных от следования предположению, которое на практике оказалось ошибочным.
В С++ количество описываемых шаблонами типов бесконечно. Но бесконечно только на этапе компиляции — именно в это время идут вычисления над типами.
На этапе же выполнения остаётся только код скомпилированный для конечного числа типов. Либо компиляция не завершается.
См. мой комментарий
Здравствуйте, m e, Вы писали:
ME>*НО* при этом эмуляция зависимых типов параметрическим полиморфизмом -- это примерно как коленвал ДВС из дерева
Никакие зависимые типы тут не "эмулируются". Типы в этих примерах не зависят от значений.
И, разумеется, для решения реальных задач такое не часто используется. Но это ведь просто иллюстрация проблем, которые в других областях проявлятся будут. Как проблемы с раздельной компиляцией, например.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Tonal-, Вы писали:
T>В С++ количество описываемых шаблонами типов бесконечно.
Это совсем не очевидно, скорее очевидно обратное. Число типов, описываемых шаблоном — это число инстанциаций шаблона с разными типами. Т.е. понятно, что с одинаковым кодом можно как-то бороться, но семантика именно такая — для каждого подстаялемого в шаблон типа — своя реализация. Т.е. это ad-hoc полиморфизм, а не параметрический.
T>Но бесконечно только на этапе компиляции — именно в это время идут вычисления над типами. T>На этапе же выполнения остаётся только код скомпилированный для конечного числа типов. Либо компиляция не завершается.
Рантайм-то тут вообще причем? Обсуждаемые примеры работают на этапе компиляции, что на хаскеле — что на C#. Динамические возможности CLR используются в C# для генерации специализаций для анбоксед-типов (т.е. для оптимизации, на семантику это не влияет). В хаскеле и яве полиморфизм бывает только для боксед, но и тут есть некоторые обходные пути для оптимизации. Понятно, что C++ не может позволить себе полиморфизм ни ценой боксинга всего, ни ценой JIT. Потому-то там параметрического полиморфизма и нет.
T>См. мой комментарий
Здравствуйте, m e, Вы писали:
ME>так хаскелем у тебя называется хаскель с какими расширениями?
Да почему у меня-то? Это позиция авторов языка изложенная в статье по истории разработки хаскеля. Хаскелем называется любое надмножество стандарта 98-го года. Если же речь идет о конкртеном стандарте, то это указывается явно. Но только речь о стандартах 98-го и 10-го года не идет почти никогда, кроме вот такого вот форумного диспута, потому что стандарты эти ни практического ни теоретического интереса не представляют.
ME> с расширениями любого из почти 10 компиляторов? или только с расширениями ghс? если так, то какого хрена такая дискриминация?
С расширениями актуальных версий любого из почти одного компилятора. Если речь пойдет о каком-то особенно новом расширении — укажут версию GHC, все расширения до 7.0 включительно подразумеваются по умолчанию. Это вообще характерно для языков с одной флагманской реализацией. Были, конечно, когда-то времена, когда было две используемых реализации (по той же причине что и у SML сейчас — в одной есть REPL, в другой — нормальный компилятор), но hugs умер где-то в 06-ом и теперь реализация одна (кое-как ведутся работы по превращению компилятора Clean в компилятор хаскеля, что, понятно, единственный шанс на выживание этого компилятора, но вероятность того, что эта реализация все-таки будет кем-то использоваться я считаю призрачной).
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, samius, Вы писали:
S>>Не принимаю мистику в программировании.
K>Тогда откуда это мистическое отличие необнаруживаемого из программы сайд-эффекта с изменением файла от сайд-эффекта с нагревом процессора?
Из определения чистоты.
Здравствуйте, samius, Вы писали:
K>>Тогда откуда это мистическое отличие необнаруживаемого из программы сайд-эффекта с изменением файла от сайд-эффекта с нагревом процессора? S>Из определения чистоты.
И где в этом определении описано, почему одни ненаблюдаемые сайд-эффекты равнее других? По моему, когда говорят о сайд-эффектах, имеют в виду наблюдаемые, с помощью которых можно ссылочную прозрачность нарушить. А ненаблюдаемые сайд-эффекты у любой функции есть.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, samius, Вы писали:
K>>>Тогда откуда это мистическое отличие необнаруживаемого из программы сайд-эффекта с изменением файла от сайд-эффекта с нагревом процессора? S>>Из определения чистоты.
K>И где в этом определении описано, почему одни ненаблюдаемые сайд-эффекты равнее других? По моему, когда говорят о сайд-эффектах, имеют в виду наблюдаемые, с помощью которых можно ссылочную прозрачность нарушить. А ненаблюдаемые сайд-эффекты у любой функции есть.
В определениях не пишут "почему". В определениях пишут о том, что является определяемым понятием, а что — нет. Функции с вводом выводом чистыми не являются по определению.
А вот то, греет функция с вводом выводом процессор, или нет, однозначно и не разобрать. Вполне может и остужать.
