Сообщение Re[83]: Мнение: объектно-ориентированное программирование — от 07.11.2019 12:49
Изменено 07.11.2019 12:51 AlexRK
Re[83]: Мнение: объектно-ориентированное программирование — катастрофа на трилли
Здравствуйте, samius, Вы писали:
S>>>Например, я могу создать экшн с помощью вызова putStr, но не встроить результат вызова в main цепочку. Вызов будет, а консоль останется нетронутой этим экшном.
ARK>>Насколько мне известно, этого сделать ты не можешь. Возможно, я ошибаюсь или неправильно тебя понял. Можешь показать код? Вот здесь можно проверить: https://repl.it/@essic/Haskell-playground
S>
Нет, меня интересует именно "putStr". В твоем коде ее нет. Можешь привести пример с putStr?
ARK>>Если ты лезешь в исходный код (предположим, он есть), то ЧТО ты там ищешь? Ты видишь внутри массу других функций, какой признак ты ищешь, чтобы понять, чиста функция или нет?
S>Нужно смотреть, есть ли вызов грязных функций. Причем, вызов, а не возврат "указателя" на них.
А как ты поймешь, какие функции грязные?
S>Можно поковыряться в двоичном коде. Но в общем случае — нет, не понять.
ОК. Значит, в общем случае мы не можем понять, чиста функция или нет.
Полагаю, можно говорить о двух уровнях понимания чистоты: "реальная" (что происходит на самом деле) и "декларируемая" (через сигнатуру или спецификацию). Ясное дело, по факту они могут отличаться — задекларировав функцию чистой, мы можем дернуть изнутри unsafe функцию, и наоборот — задекларировав функцию грязной, мы можем внутри просто сложить 2+2.
В чем польза декларируемой чистоты, я могу понять — мы можем рассуждать о свойствах программы, просто глядя на сигнатуры функций или в документацию, и строя код относительно предполагаемых инвариантов. При чтении кода мы можем обоснованно предполагать, что происходит. Компилятор также работает именно с декларируемой чистотой — оптимизирует код вокруг нее (реальной он в общем случае не знает).
В чем польза и смысл "реальной" чистоты, можешь пояснить? Ты же вроде ратуешь за смысл.
S>>>Но результат вызова putStr "11" можно (например) кэшировать и использовать многократно, как и результат другой чистой функции.
ARK>>Можно сделать то же самое с printf — просто возьми указатель на эту функцию и получишь абсолютно то же самое. Получишь "действие", которое надо выполнить.
S>Да, функция C, возвращающая указатель на функцию printf будет чиста, если она кроме этого не делает ничего грязного сама, разумеется.
Абстрагируйся и представь, что функция printf сама возвращает action. "Вызов" этой функции будет "printf" (без скобок), а вызов action, который она возвращает — "printf()". Все как в хаскеле.
S>>>Например, я могу создать экшн с помощью вызова putStr, но не встроить результат вызова в main цепочку. Вызов будет, а консоль останется нетронутой этим экшном.
ARK>>Насколько мне известно, этого сделать ты не можешь. Возможно, я ошибаюсь или неправильно тебя понял. Можешь показать код? Вот здесь можно проверить: https://repl.it/@essic/Haskell-playground
S>
S>main = do
S> last [putStrLn "a", putStrLn "b"]
S>Нет, меня интересует именно "putStr". В твоем коде ее нет. Можешь привести пример с putStr?
ARK>>Если ты лезешь в исходный код (предположим, он есть), то ЧТО ты там ищешь? Ты видишь внутри массу других функций, какой признак ты ищешь, чтобы понять, чиста функция или нет?
S>Нужно смотреть, есть ли вызов грязных функций. Причем, вызов, а не возврат "указателя" на них.
А как ты поймешь, какие функции грязные?
S>Можно поковыряться в двоичном коде. Но в общем случае — нет, не понять.
ОК. Значит, в общем случае мы не можем понять, чиста функция или нет.
Полагаю, можно говорить о двух уровнях понимания чистоты: "реальная" (что происходит на самом деле) и "декларируемая" (через сигнатуру или спецификацию). Ясное дело, по факту они могут отличаться — задекларировав функцию чистой, мы можем дернуть изнутри unsafe функцию, и наоборот — задекларировав функцию грязной, мы можем внутри просто сложить 2+2.
В чем польза декларируемой чистоты, я могу понять — мы можем рассуждать о свойствах программы, просто глядя на сигнатуры функций или в документацию, и строя код относительно предполагаемых инвариантов. При чтении кода мы можем обоснованно предполагать, что происходит. Компилятор также работает именно с декларируемой чистотой — оптимизирует код вокруг нее (реальной он в общем случае не знает).
В чем польза и смысл "реальной" чистоты, можешь пояснить? Ты же вроде ратуешь за смысл.
S>>>Но результат вызова putStr "11" можно (например) кэшировать и использовать многократно, как и результат другой чистой функции.
ARK>>Можно сделать то же самое с printf — просто возьми указатель на эту функцию и получишь абсолютно то же самое. Получишь "действие", которое надо выполнить.
S>Да, функция C, возвращающая указатель на функцию printf будет чиста, если она кроме этого не делает ничего грязного сама, разумеется.
Абстрагируйся и представь, что функция printf сама возвращает action. "Вызов" этой функции будет "printf" (без скобок), а вызов action, который она возвращает — "printf()". Все как в хаскеле.
Re[83]: Мнение: объектно-ориентированное программирование —
Здравствуйте, samius, Вы писали:
ARK>>Если ты лезешь в исходный код (предположим, он есть), то ЧТО ты там ищешь? Ты видишь внутри массу других функций, какой признак ты ищешь, чтобы понять, чиста функция или нет?
S>Нужно смотреть, есть ли вызов грязных функций. Причем, вызов, а не возврат "указателя" на них.
А как ты поймешь, какие функции грязные?
S>Можно поковыряться в двоичном коде. Но в общем случае — нет, не понять.
ОК. Значит, в общем случае мы не можем понять, чиста функция или нет.
Полагаю, можно говорить о двух уровнях понимания чистоты: "реальная" (что происходит на самом деле) и "декларируемая" (через сигнатуру или спецификацию). Ясное дело, по факту они могут отличаться — задекларировав функцию чистой, мы можем дернуть изнутри unsafe функцию, и наоборот — задекларировав функцию грязной, мы можем внутри просто сложить 2+2.
В чем польза декларируемой чистоты, я могу понять — мы можем рассуждать о свойствах программы, просто глядя на сигнатуры функций или в документацию, и строя код относительно предполагаемых инвариантов. При чтении кода мы можем обоснованно предполагать, что происходит. Компилятор также работает именно с декларируемой чистотой — оптимизирует код вокруг нее (реальной он в общем случае не знает).
В чем польза и смысл "реальной" чистоты, можешь пояснить? Ты же вроде ратуешь за смысл.
S>>>Но результат вызова putStr "11" можно (например) кэшировать и использовать многократно, как и результат другой чистой функции.
ARK>>Можно сделать то же самое с printf — просто возьми указатель на эту функцию и получишь абсолютно то же самое. Получишь "действие", которое надо выполнить.
S>Да, функция C, возвращающая указатель на функцию printf будет чиста, если она кроме этого не делает ничего грязного сама, разумеется.
Абстрагируйся и представь, что функция printf сама возвращает action. "Вызов" этой функции будет "printf" (без скобок), а вызов action, который она возвращает — "printf()". Все как в хаскеле.
UPD. Убрал неправильный вопрос, некорректно код прочитал.
ARK>>Если ты лезешь в исходный код (предположим, он есть), то ЧТО ты там ищешь? Ты видишь внутри массу других функций, какой признак ты ищешь, чтобы понять, чиста функция или нет?
S>Нужно смотреть, есть ли вызов грязных функций. Причем, вызов, а не возврат "указателя" на них.
А как ты поймешь, какие функции грязные?
S>Можно поковыряться в двоичном коде. Но в общем случае — нет, не понять.
ОК. Значит, в общем случае мы не можем понять, чиста функция или нет.
Полагаю, можно говорить о двух уровнях понимания чистоты: "реальная" (что происходит на самом деле) и "декларируемая" (через сигнатуру или спецификацию). Ясное дело, по факту они могут отличаться — задекларировав функцию чистой, мы можем дернуть изнутри unsafe функцию, и наоборот — задекларировав функцию грязной, мы можем внутри просто сложить 2+2.
В чем польза декларируемой чистоты, я могу понять — мы можем рассуждать о свойствах программы, просто глядя на сигнатуры функций или в документацию, и строя код относительно предполагаемых инвариантов. При чтении кода мы можем обоснованно предполагать, что происходит. Компилятор также работает именно с декларируемой чистотой — оптимизирует код вокруг нее (реальной он в общем случае не знает).
В чем польза и смысл "реальной" чистоты, можешь пояснить? Ты же вроде ратуешь за смысл.
S>>>Но результат вызова putStr "11" можно (например) кэшировать и использовать многократно, как и результат другой чистой функции.
ARK>>Можно сделать то же самое с printf — просто возьми указатель на эту функцию и получишь абсолютно то же самое. Получишь "действие", которое надо выполнить.
S>Да, функция C, возвращающая указатель на функцию printf будет чиста, если она кроме этого не делает ничего грязного сама, разумеется.
Абстрагируйся и представь, что функция printf сама возвращает action. "Вызов" этой функции будет "printf" (без скобок), а вызов action, который она возвращает — "printf()". Все как в хаскеле.
UPD. Убрал неправильный вопрос, некорректно код прочитал.