Я думаю, что исчерпывающая документация должна содержать в себе ту же информацию, что и тип, только компилятор и IDE не смогут ей воспользоваться для помощи программисту.
да и не может проверить по достаточно очевидным причинам
По каким?
Насколько я понял, он проверяет и заставляет громко поклясться мамой (unsafeperformio) что легко отличимо на code review либо не использовать.
Насколько я знаю, есть раcширение Safe Haskell в GHC которое позволяет отличать тех кто клянется мамой от тех кто использует чужие клятвы мамой и выбирать доверять этим клятвам или нет.
Во-вторых, "проверяет" не то же самое, что "проверяет и дает 100% гарантию". 100% гарантии нигде нет.
Я так понимаю, что в микросервисах огранисения типа агрегатов DDD — нельзя например передавать ссылки, на что-то внутренне а только value object. Пакеты это никак не ограничивают.
сли такой договор есть и мы верим, что человек, который ф-ю писал, ему следует — то надо, с-но, посмотреть на имя функции/тип/документацию и выяснить, вызывает она внутри print или нет.
Если договоренность есть, то можно написать инструмент, который будет проверять это. Если договоренности нет, то придется исследовать все дерево вызовов.
Язык программирования вообще это договоренность. Наши рассуждения для времени выполнения программы справедливы лишь настолько насколько разработчики компилятора и рантайма соблюдают свои договоренности.
100% гарантии никогда нет — бывают ошибки в компиляторах или рантаймах.
Если же договоренности нет (или веры нет) — только тело смотреть, других вариантов не остается.
Т.е. есть разница между наличием и отсутствием договоренностей?
Причем этот ризонинг делаться будет совершенно одинаково что в хаскеле, что на сишке.
Это касается абсолютно всех программ программ на хаскеле или только того подмножества где есть только монада IO и ни одной функции не использующей этой монады?
А можно — как "композиция ф-й Stack -> Stack", никаких сайд-эффектов, чистая функциональщина.
Можно предложить разделение на формально-функциональную и функциональную по духу программу.
Последняя отличается тем, что там не используются модели состояний, которые не нужны в предметной области. Например, для сложения двух чисел не нужно понятие стека. Можно написать в state monad эмулятор программы на форте вычисляющей математическое выражение и программа будет формально функциональной, но не функциональной по духу.
Прок от формальной функциональности в том, что императивный стековый мирок там будет изолирован.
А код — это не только поведение. Код — это еще и восприятие человеком. Для людей нужны названия переменных, комментарии, разбиение на функции для понятности и так далее.
Еще мне интересно как вы автолифтанете reflection. Я не очень во все этих монадах. Но мне кажется, что тогда из семантики языка придется убрать всякие int и прочее и оставить только IO int либо думать о что MethodInfo.GetParameterType возвращает анлифченный тип параметра.
Это только если вы придумаете свой язык с синтаксисом, допустим C#, и будете приписывать ко всем функциям IO (назовем его, допустим IO#). В реальном языке C# никакого IO, его нет в документации библиотеках и reflection. Язык — это договоренность относительно того, что, что означает.
Как только вы придумаете такой язык, он будет бессмысленным, так как там будет две категории функций — те, к которым осмысленно приписано IO типа Console.WriteLine и те, к которым бессмысленно приписано IO типа String.Concat и нет никакого способа не приписывать IO к функциям и от этого приписывания нет никакой выгоды.
Т.е. вы можете мысленно транслировать C# на очень похожий бессмысленный язык IO# но
это будет другой язык, так как то, что считать параметром а что считать возвращаемым значением уже определено в спецификации C#
это будет бессмысленный язык так как на нем не будет возможности не приписывать IO к функциям.
Представьте себе, что в условном C IO написано просто везде, поэтому, чтобы не захламлять программу, договорились его нигде не писать явно — компилятор проставит
Если компилятор проставит, то это значит изменение типа — т.е. я смогу например в своей функции мемоизации проверить не содержит ли тип IO и принять решение могу ли я мемоизировать эту функцию или нет.
Рассуждения Druu верны если отбросить то, что у библиотек, компиляторов, IDE, RTTI и других людей уже есть некоторое соглашение о том, что является типом и аргументами функции а что — нет.
То, что мы мысленно можем преобразовать любую императивную программу в вырожденный случая чисто функциональной программы не означает, что императивная и чисто функциональная программа — одно и то же.
С моей точки зрения она всегда чистая (я не очень силен
монадах). Просто когда вы ее выполняете внутри монады завернут RealWorld (состояние мира) и оно всегда разное, а способов его генерировать запоминать и не возвращать не бывает.
Функция чистая не тогда когда у нее нет эффектов, а когда нет побочных эффектов — т.е. чего-то не являющимся возвращаемым значением. Если представить состояние всего мира как аргумент и
возвращаемое значение (типа такая особенная гигантская стейт монада) то это чистая функция — она не делает ничего что не является трансформацией аргумента в результат, т.е. нет побочных эффектов.
Как модератор, я хочу создать новую игру, введя название и необязательное описание.
Или же:
Я хочу создать новую игру, введя название и необязательное описание.
Неужели небо рухнуло?
Если я сисадмин, я могу сделать это скриптом — мне нужна автоматизируемость, если я модератор, у меня должен быть удобный интерфейс. Если я игрок, у меня могут быть урезанные права, например.
Допустим вы воспринимаете программу на C как синтаксический сахар для программы на haskell, где все функции подняты в IO.
Однако, такая программа частично будет состоять из функций, которые подняты в IO, но никак этот факт не используют.
Т.е. все функции поделятся на два типа, которые декларируют использование IO и его на самом деле используют и те, которые декларируют использование IO но его не используют.
Как только вы мысленно уберете IO из типа этих функций у вас будут ошибки мысленной компиляции.
Т.е. восприятие программы как чисто функциональной подтолкнет к разделению частей, которые общаются со внешним миром и тех которые не общаются и позволит использовать вам и инструментам некоторые механизмы
для рассуждения о них.
Не является ли это разновидностью статической типизации?
А как они должны описываться?
Я думаю, что исчерпывающая документация должна содержать в себе ту же информацию, что и тип, только компилятор и IDE не смогут ей воспользоваться для помощи программисту.
Почему нельзя проверить и выдать результат "если core реализован корректно, то эта функция ничего не выводит на консоль"?
По каким?
Насколько я понял, он проверяет и заставляет громко поклясться мамой (unsafeperformio) что легко отличимо на code review либо не использовать.
Насколько я знаю, есть раcширение Safe Haskell в GHC которое позволяет отличать тех кто клянется мамой от тех кто использует чужие клятвы мамой и выбирать доверять этим клятвам или нет.
Во-вторых, "проверяет" не то же самое, что "проверяет и дает 100% гарантию". 100% гарантии нигде нет.
В приткладном — свой мир со своими бизнес правилами. Пользователю нельзя давать выстрелить себе в ногу. И не только себе.
следить за соблюдением каких правил?
А что-то автоматическое?
Я так понимаю, что в микросервисах огранисения типа агрегатов DDD — нельзя например передавать ссылки, на что-то внутренне а только value object. Пакеты это никак не ограничивают.
Интересно, не придумал ли кто-то способа энфорсить слабо связанную архитектуру, не заставляя маршалить данные и взаимодействовать по сети?
Если договоренность есть, то можно написать инструмент, который будет проверять это. Если договоренности нет, то придется исследовать все дерево вызовов.
Язык программирования вообще это договоренность. Наши рассуждения для времени выполнения программы справедливы лишь настолько насколько разработчики компилятора и рантайма соблюдают свои договоренности.
100% гарантии никогда нет — бывают ошибки в компиляторах или рантаймах.
Т.е. есть разница между наличием и отсутствием договоренностей?
Это касается абсолютно всех программ программ на хаскеле или только того подмножества где есть только монада IO и ни одной функции не использующей этой монады?
Можно предложить разделение на формально-функциональную и функциональную по духу программу.
Последняя отличается тем, что там не используются модели состояний, которые не нужны в предметной области. Например, для сложения двух чисел не нужно понятие стека. Можно написать в state monad эмулятор программы на форте вычисляющей математическое выражение и программа будет формально функциональной, но не функциональной по духу.
Прок от формальной функциональности в том, что императивный стековый мирок там будет изолирован.
А код — это не только поведение. Код — это еще и восприятие человеком. Для людей нужны названия переменных, комментарии, разбиение на функции для понятности и так далее.
Еще мне интересно как вы автолифтанете reflection. Я не очень во все этих монадах. Но мне кажется, что тогда из семантики языка придется убрать всякие int и прочее и оставить только IO int либо думать о что MethodInfo.GetParameterType возвращает анлифченный тип параметра.
Это только если вы придумаете свой язык с синтаксисом, допустим C#, и будете приписывать ко всем функциям IO (назовем его, допустим IO#). В реальном языке C# никакого IO, его нет в документации библиотеках и reflection. Язык — это договоренность относительно того, что, что означает.
Как только вы придумаете такой язык, он будет бессмысленным, так как там будет две категории функций — те, к которым осмысленно приписано IO типа Console.WriteLine и те, к которым бессмысленно приписано IO типа String.Concat и нет никакого способа не приписывать IO к функциям и от этого приписывания нет никакой выгоды.
Т.е. вы можете мысленно транслировать C# на очень похожий бессмысленный язык IO# но
это будет другой язык, так как то, что считать параметром а что считать возвращаемым значением уже определено в спецификации C#
это будет бессмысленный язык так как на нем не будет возможности не приписывать IO к функциям.
Я так понимаю, что когда она интерпретируется то тоже нет сайд эффектов, так как состояние мира передается как RealWorld
Еще мысль — можем ли мы договориться считать сайд эффект здесь ненаблюдаемым, как допустим изменение температуры ЦП в результате выполнения функции.
Как если мы запретим другим частям программы, например, читать этот лог, но мы получим ссылочную прозрачность и можем считать эту функцию чистой.
Если компилятор проставит, то это значит изменение типа — т.е. я смогу например в своей функции мемоизации проверить не содержит ли тип IO и принять решение могу ли я мемоизировать эту функцию или нет.
Рассуждения Druu верны если отбросить то, что у библиотек, компиляторов, IDE, RTTI и других людей уже есть некоторое соглашение о том, что является типом и аргументами функции а что — нет.
То, что мы мысленно можем преобразовать любую императивную программу в вырожденный случая чисто функциональной программы не означает, что императивная и чисто функциональная программа — одно и то же.
С моей точки зрения она всегда чистая (я не очень силен
монадах). Просто когда вы ее выполняете внутри монады завернут RealWorld (состояние мира) и оно всегда разное, а способов его генерировать запоминать и не возвращать не бывает.
Функция чистая не тогда когда у нее нет эффектов, а когда нет побочных эффектов — т.е. чего-то не являющимся возвращаемым значением. Если представить состояние всего мира как аргумент и
возвращаемое значение (типа такая особенная гигантская стейт монада) то это чистая функция — она не делает ничего что не является трансформацией аргумента в результат, т.е. нет побочных эффектов.
Тут битая ссылка
Если я сисадмин, я могу сделать это скриптом — мне нужна автоматизируемость, если я модератор, у меня должен быть удобный интерфейс. Если я игрок, у меня могут быть урезанные права, например.
Допустим вы воспринимаете программу на C как синтаксический сахар для программы на haskell, где все функции подняты в IO.
Однако, такая программа частично будет состоять из функций, которые подняты в IO, но никак этот факт не используют.
Т.е. все функции поделятся на два типа, которые декларируют использование IO и его на самом деле используют и те, которые декларируют использование IO но его не используют.
Как только вы мысленно уберете IO из типа этих функций у вас будут ошибки мысленной компиляции.
Т.е. восприятие программы как чисто функциональной подтолкнет к разделению частей, которые общаются со внешним миром и тех которые не общаются и позволит использовать вам и инструментам некоторые механизмы
для рассуждения о них.