Что делать с жунами , Что делать с жунами

[applegame]

Цитата D_KEY @ 29.04.21, 19:58

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

Да ваще, код поменялся до неузнаваемости:

main =
    putStrLn "str1" >>
    putStrLn "str2"

Добавлено 29.04.21, 20:08
Кстати в Erlang/Elixir нет мутабельных переменных, но полно функций с побочными эффектами. Значит таки можно писать императивно (по вашему определению) без мутабельных переменных?

Сообщение отредактировано: applegame - 29.04.21, 20:23

[korvin]

applegame,

main = myMain $ do
  myPutStrLn "first"
  myPutStrLn "second"
  myPutStrLn "third"

third
second
first

impl

import Control.Applicative
 
data MyCoolIO a = MCIO (IO a)
 
instance Functor MyCoolIO where
  fmap f (MCIO xIO)  =  MCIO $ fmap f xIO
 
instance Applicative MyCoolIO where
  pure = MCIO . pure
  (MCIO fIO) <*> (MCIO xIO)  =  MCIO $ fIO <*> xIO
 
instance Monad MyCoolIO where
  return = pure
 
  (MCIO xIO) >>= f          =  MCIO $ xIO >>= \x -> (let (MCIO r) = f x in r)
  (MCIO xIO) >> (MCIO yIO)  =  MCIO $ yIO >>= \y -> (xIO >> return y)
 
myPutStrLn :: String -> MyCoolIO ()
myPutStrLn s = MCIO $ putStrLn s
 
myMain :: MyCoolIO () -> IO ()
myMain (MCIO io) = io

— https://ideone.com/9nbY5V

Давай, расскажи ещё про порядок в do-выражении.

Добавлено 29.04.21, 20:36

Цитата applegame @ 29.04.21, 20:03

Значит таки можно писать императивно (по вашему определению) без мутабельных переменных?

В нашем определении есть изменяемое состояние, а не «мутабельные переменные».

Добавлено 29.04.21, 20:38

Цитата applegame @ 29.04.21, 19:46

Последний - ИП, первые два ФП.

Не угадал.

Добавлено 29.04.21, 20:42

Цитата applegame @ 29.04.21, 19:46

Откуда такой вывод? Почему все, если я говорил о хаскельном IO, в том числе и о монаде IO?

Оттуда, что do-нотация работает с любой монадой, а не только монадой IO.

Цитата applegame @ 29.04.21, 19:46

Раз возможно IO, значит возможны функции с побочными эффектами.

В Хаскелле нет функций с побочными эффектами.

Цитата applegame @ 29.04.21, 19:46

Потому что парадигма не может измениться если не меняется код Очевидно же.

Попробуй ещё раз поразмыслить над фразой «синтаксис != семантика».

Цитата applegame @ 29.04.21, 19:46

Пример чего?

Пример использования do-нотации с «чистыми» (не-IO) монадами.

Цитата applegame @ 29.04.21, 19:46

В чистой ФП-композиции порядок может быть любым, уже обсуждали и ты вроде согласился. Опять по кругу?

По-моему, это ты согласился, что (foo . bar) и (bar . foo) — не одно и то же. Или ты так и не понял, что это значит?

Цитата applegame @ 29.04.21, 19:46

Ага, а то что эти критерии коррелируют с порядком стейтментов в do-нотации - это просто совпадение?

Не коррелируют.

[applegame]

Цитата korvin @ 29.04.21, 20:35

Пример использования do-нотации с «чистыми» (не-IO) монадами.

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

Цитата korvin @ 29.04.21, 20:35

Давай, расскажи ещё про порядок в do-выражении.

А что тут рассказывать? Меняем первую и вторую строчку местами:

main = myMain $ do
  myPutStrLn "second"
  myPutStrLn "first"
  myPutStrLn "third"

И, ой! Как такое могло случиться? Результат тоже поменялся:

third
first
second

Чудеса, монада не поменялась, а порядок поменялся.
А ведь они ваще

Цитата korvin @ 29.04.21, 20:35

Не коррелируют.

В общем зря ты мучался, выводил инструкции задом наперед. Давай теперь программу, которая фигачит инструкции в рандомном порядке. Правда функция генерации СЧ сама будет с побочными эффектами. Придется еще сложнее мудрить код.
Впрочем, подозреваю, что это таки возможно. Я даже в чистом императивном коде на D или Nim могу провернуть подобную фигню Правда хз, что это докажет.

Добавлено 29.04.21, 20:47
Ладно, плевать на монады, нотации, и прочую ересь. Надоело.

Вот:

Цитата applegame @ 29.04.21, 20:03

Кстати в Erlang/Elixir нет мутабельных переменных, но полно функций с побочными эффектами. Значит таки можно писать императивно (по вашему определению) без мутабельных переменных?

Опровергайте.

Сообщение отредактировано: applegame - 29.04.21, 21:00

[korvin]

Цитата applegame @ 29.04.21, 20:44

И, ой! Как такое могло случиться? Результат тоже поменялся:
Чудеса, монада не поменялась, а порядок поменялся.

какой же ты, всё-таки, тупой.

import Control.Applicative
import Data.Time.Clock.POSIX (getPOSIXTime)
 
data MyCoolIO a = MCIO (IO a)
 
instance Functor MyCoolIO where
  fmap f (MCIO xIO)  =  MCIO $ fmap f xIO
 
instance Applicative MyCoolIO where
  pure = MCIO . pure
  (MCIO fIO) <*> (MCIO xIO)  =  MCIO $ fIO <*> xIO
 
instance Monad MyCoolIO where
  return = pure
 
  (MCIO xIO) >>= f          =  MCIO $ xIO >>= \x -> (let (MCIO r) = f x in r)
  (MCIO xIO) >> (MCIO yIO)  =  MCIO $ do
    now <- getPOSIXTime
    if even (round now) then xIO >> yIO
    else yIO >>= \y -> (xIO >> return y)
 
myPutStrLn :: String -> MyCoolIO ()
myPutStrLn s = MCIO $ putStrLn s
 
myMain :: MyCoolIO () -> IO ()
myMain (MCIO io) = io
 
main = myMain $ do
  myPutStrLn "first"
  myPutStrLn "second"
  myPutStrLn "third"

Добавлено 29.04.21, 21:23

Цитата applegame @ 29.04.21, 20:44

Опровергайте.

Что опровергать? Ты даже не читаешь, что тебе пишут.

Добавлено 29.04.21, 21:26

Цитата applegame @ 29.04.21, 20:44

Правда хз, что это докажет.

Это доказывает, что ты
1) не читаешь, что тебе пишут
2) не пытаешься понять, что тебе пишут
3) не разбираешься в том, о чём пишешь
4) продолжаешь с завидным упорством игнорировать факты

[applegame]

Цитата korvin @ 29.04.21, 21:22

какой же ты, всё-таки, тупой.

Лентяй. second-то все время посередине. Все ещё зависит от порядка инструкций.
Ты просто выкинь вообще результат do-нотации, и напечатай что попало. Вот это будет супер-доказательство твоей правоты: вообще ничего не будет коррелировать.

Добавлено 29.04.21, 21:34

Цитата korvin @ 29.04.21, 21:22

Это доказывает, что ты
1) не читаешь, что тебе пишут
2) не пытаешься понять, что тебе пишут
3) не разбираешься в том, о чём пишешь
4) продолжаешь с завидным упорством игнорировать факты

Этот корвин порвался, несите другого.

Сообщение отредактировано: applegame - 29.04.21, 21:45

[korvin]

applegame, ясно-понятно, ты таки достиг уровня Серёжи. Не планируешь в Израиль переехать?

[applegame]

Вот сам написал:

myMain x = print "VICTORY!"
 
main = myMain $ do
  print "first"
  print "second"
  print "third"

Вообще никакой корреляции между порядком и вообще инструкциями и результатом. И намного проще. Учись у мастера, пока он жив.

Добавлено 29.04.21, 21:44

Цитата korvin @ 29.04.21, 21:43

applegame, ясно-понятно, ты таки достиг уровня Серёжи. Не планируешь в Израиль переехать?

Нет, я же за Палестину.

Сообщение отредактировано: applegame - 29.04.21, 21:45

[korvin]

Цитата applegame @ 29.04.21, 21:43

Вообще никакой корреляции между порядком и вообще инструкциями и результатом

Молодец. И нахрена ты три страницы утверждал обратное?

Добавлено 29.04.21, 21:48

Цитата applegame @ 29.04.21, 21:43

Нет, я же за Палестину.

Тоже неплохой вариант. Даже лучше.

[applegame]

Цитата korvin @ 29.04.21, 21:47

Молодец. И нахрена ты три страницы утверждал обратное?

Да вот, теперь сам удивляюсь.

Добавлено 29.04.21, 22:00
Тут еще удивительное открытие.
Оказывается в императивных языках с побочными эффектами, от порядка инструкций тоже ничего не зависит. Как так?!

https://glot.io/snippets/fy5bbbksrd

import std.stdio;
 
alias myMain = x => writeln("VICTORY!!!");
 
void main() {
    myMain({
        writeln("first");
        writeln("second");
        writeln("third");
    });
}

[korvin]

Цитата applegame @ 29.04.21, 21:48

Оказывается в императивных языках с побочными эффектами, от порядка инструкций тоже ничего не зависит.

Т.е. твоё «определение», что ИП — это порядок инструкций и ничего более, оказалось несостоятельным. Поздравляю.

Сообщение отредактировано: korvin - 29.04.21, 22:35

[applegame]

Цитата korvin @ 29.04.21, 22:33

Т.е. твоё «определение», что ИП — это порядок инструкций и ничего более, оказалось несостоятельным. Поздравляю.

Хуже. Твое тоже оказалось несостоятельным. Так что и себя поздравь. И D_KEY-я не забудь. Да вообще всех поздравь, ничьё определение не оказалось состоятельным. Программирования не существует, особенно если инструкции закомментировать. ПА-БЕ-ДААА!

Сообщение отредактировано: applegame - 30.04.21, 04:28

[korvin]

Цитата applegame @ 30.04.21, 04:21

Хуже. Твое тоже оказалось несостоятельным. Так что и себя поздравь. И D_KEY-я не забудь. Да вообще всех поздравь, ничьё определение не оказалось состоятельным. Программирования не существует, особенно если инструкции закомментировать. ПА-БЕ-ДААА!

[OpenGL]

Я правильно понимаю, что ваш спор сводится к тому, считать ли набор локальных переменных у функции состоянием, или нет? Если это состояние, то в определении ИП по applegame состояние никуда не девается, просто оно автоматически следует из
последовательности инструкций, и, следовательно, не обязательно в явном виде подчёркивать его наличие. А если это не состояние, то тогда тем более нет никаких проблем с его определением.

[Qraizer]

Цитата applegame @ 29.04.21, 14:19

Так не нужно. Вот если бы можно было так:

auto z = []{ return y() + 2; };
auto y = []{ return x() + 1; };
auto x = []{ return 3; };

то было бы нунифигасебе.

Следующий наводящий вопрос. А так?

std::function<int()> x, y, z;
 
z = []{ return y() + 2; };
y = []{ return x() + 1; };
x = []{ return 3; };

Добавлено 30.04.21, 11:31

Цитата scrambrella @ 29.04.21, 19:46

На С/С++ легко писать функционально.

Не очень легко. Но в целом запросто.

Добавлено 30.04.21, 11:35

Цитата applegame @ 29.04.21, 20:44

Давай теперь программу, которая фигачит инструкции в рандомном порядке.

Пффф. Даже язык такой есть.

Добавлено 30.04.21, 11:41
Нет, OpenGL. Они пытаются определить чёткие грани между двумя парадигмами, не понимая, что их нет.