[Haskell] простой вопрос

> *Main> f' <- newWithdraw

Я не понял, а что эта запись значит? Всмысле если без репла как оно будет выглядеть?

Точно так же, я выше приводил же код main.

я имею ввиду как выразить это в виде f' = ...

Хм, зачем? Чисто ради синтаксиса?

Чисто ради того, чтобы посмотреть, как это будет выглядеть в коде на хаскеле. Ты же там не сможешь написать

f' <- newWithdraw

f = f' 20

И это, очевидно, не функция ОПа.

Про карринг слышал? В Хаскеле это делается автоматически. ТС сделал карринг руками на Лиспе. Вот и вся разница.

Чего? Это не карринг. Карринг был бы вот:

[code] (define (new-withdraw balance) (let ((balance 100)) (lambda (amount) (if (>= balance amount) (begin (set! balance (- balance amount)) balance) «Недостаточно денег на счете»)))) [/code]

А у ОПа обычное мутабельное замыкание.

Чего? Это не карринг. Карринг был бы вот:

(define (new-withdraw balance)
  (let ((balance 100))
    (lambda (amount)
      (if (>= balance amount)
	  (begin (set! balance (- balance amount))
		 balance)
	  "Недостаточно денег на счете"))))

А у ОПа обычное мутабельное замыкание.

Согласен, был неправ. Карринг используется только в моём последнем варианте.

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

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

Не понял о чем ты вообще. Какие ф-и с двумя аргументами?

[Haskell] простой вопрос (комментарий)

Ты (или не ты, кто вас там, анонимусов, разберёт) привёл функцию с двумя аргументами, и стал утверждать, что именно это и сделано в примерах на Хаскеле.

Ну да, все верно. Здесь второй аргумент - это состояние, и оно во всех вариантах на хаскеле передается (либо явно, либо в монаде), и мы вынуждены следить за его корректной передачей. В варианте ОПа состояние никуда не передается, оно существует только внутри самой ф-и.

и оно во всех вариантах на хаскеле передается (либо явно, либо в монаде)

Так оно тогда в Лиспе тоже передаётся. В переменной.

В варианте ОПа состояние никуда не передается, оно существует только внутри самой ф-и.

Ну дык. Во всех приведённых вариантах на Хаскеле состояние наличествует только внутри замыкания.

В чём разница-то?

Вместо обычной аппликации

Можно перегрузить обычную аппликацию (в динамических языках она именно такая - перегруженная):

class Apply f g | f -> g where
  ($) :: f -> g

instance Apply (a -> b) (a -> b) where
  ($) = (Prelude.$)

instance Functor f => Apply (f (a -> b)) (a -> f b) where
  x $ n = fmap (Prelude.$ n) x

...

> Так оно тогда в Лиспе тоже передаётся. В переменной.

В примере ОПа ничего не передается, в том и дело. На схеме можно сделать вариант с передачей, можно без передачи. На хаскеле - только с передачей.

Ну дык. Во всех приведённых вариантах на Хаскеле состояние наличествует только внутри замыкания.

Нет, в этом и проблема. На хаскеле нет способа «скрыть» состояние - все состояния, грубо говоря, «торчат» кишками наружу. И нам при вызове соответствующих ф-й приходится с этими кишками взаимодействовать.

instance Functor f => Apply (f (a -> b)) (a -> f b)

Не надо.

В примере ОПа ничего не передается, в том и дело.

Как же не передаётся? Вот она, переменная balance. Не видишь суслика, что ли?

На хаскеле нет способа «скрыть» состояние - все состояния, грубо говоря, «торчат» кишками наружу.

Самый первый вариант: [Haskell] простой вопрос (комментарий)

Что тут торчит наружу?

нетривиальные костылики.

там только liftM ($ 20) newWithdraw, если что. Т.е. «суём применение к 20 в монаду».

> (в динамических языках она именно такая - перегруженная):

В динамических языках она как раз обычная.

Можно перегрузить

А еще можно написать компилятор любого другого ЯП.

В динамических языках она как раз обычная.

Как минимум - от переменного количества аргументов, следовательно, уже перегружена.

> Как же не передаётся? Вот она, переменная balance. Не видишь суслика, что ли?

При вызове функции - она не передается.

Что тут торчит наружу?

IO. И при вызове функции мы теперь должны взаимодействовать с этим IO. В варианте на схеме IO спрятано внутри, нам с ним взаимодействовать не надо.

> Как минимум - от переменного количества аргументов, следовательно, уже перегружена.

Это откуда сделан такой вывод? Всмысле тот, что для переменного количества аргументов - перегружена?

Вместо обычной аппликации приходится вертеть нетривиальные костылики.

А ты не слушай тех, кто вертит нетривиальные костылики.

Я не понял, а что эта запись значит? Всмысле если без репла как оно будет выглядеть?

Да точно так же.

main = do
  f' <- newWithdraw
  let f = f' 40
  f
  f
  f
  return ()

Всмысле тот, что для переменного количества аргументов - перегружена?

Тогда это просто функция от типа Object (супертип всех типов), или <Object>_n (кортеж, который тоже : Object). Ну или apply : {n : Nat} -> (<Object>_n -> Object) -> <Object>_n -> Object.

> Да точно так же.

Ну ты засунул внутрь do, предполагается что тебе этот f' надо использовать в нескольких других функциях.

> Тогда это просто функция от типа Object (супертип всех типов), или <Object>_n (кортеж, который тоже : Object). Ну или apply : {n : Nat} -> (<Object>_n -> Object) -> <Object>_n -> Object.

Ну и в чем проблема?

Ну и в чем проблема?

Всё ок, я соглашаюсь. При условии, что у нас есть Object.

> Всё ок, я соглашаюсь. При условии, что у нас есть Object.

Речь шла о ЯП с динамической типизацией. Там определенно есть Object, не так ли?

предполагается что тебе этот f' надо использовать в нескольких других функциях.

Да liftM это, обычный liftM. Он же fmap, в данном случае.

Там определенно есть Object, не так ли?

Точно.

Это понятно, но тебя реально не смущает ситуация, когда надо делать lifrM ($ 20) f вместо f 20?

При вызове функции - она не передается.

И на Хаскеле не передаётся.

IO.

Ну дык это несколько другое дело. Состояние наружу не торчит, мы не можем снаружи до него достучаться.

И при вызове функции мы теперь должны взаимодействовать с этим IO. В варианте на схеме IO спрятано внутри, нам с ним взаимодействовать не надо.

IO - как раз такая вещь, которая не может быть спрятана внутри. Если бы оно было спрятано внутри, то последовательные вызовы давали бы один и тот же результат. Тот факт, что они таки дают разные результаты - это и есть «торчащее наружу IO».

> Ну ты засунул внутрь do, предполагается что тебе этот f' надо использовать в нескольких других функциях.

Ну так передай им то, что им нужно использовать. Проведи декомпозицию.

тебя реально не смущает ситуация, когда надо делать lifrM ($ 20) f вместо f 20?

== «тебя реально не смущает статическая типизация?»

предполагается что тебе этот f' надо использовать в нескольких других функциях.

В чём проблема-то?

a f' =
  do let f = f' 40
     f
     f
     return ()

b f' =
  do f' 30
     return ()

main =
  do f' <- newWithdraw
     a f'
     b f'

> Ну дык это несколько другое дело. Состояние наружу не торчит, мы не можем снаружи до него достучаться.

Мы видим снаружи, по крайней мере, что некоторое состояние есть. И что мы должны корректно с ним взаимодействовать и учитывать его наличие. Грубо говоря - мы видим наличие некоего черного ящика и вынуждены писать код с учетом его наличия. Этот черный ящик и торчит наружу. А на схеме он - внутри.

Тот факт, что они таки дают разные результаты - это и есть «торчащее наружу IO».

«Торчащее наружу ИО» - это когда нам приходится писать код, учитывающий особенности взаимодействия с этим ИО. По крайней мере - такого мое понимание.

Ну вот, приходится f' явно передавать :) Собственно, уже же написано вариант с liftM - это и есть то, что требовалось.

делать lifrM ($ 20)

Кстати, в таких ситуациях можно не играть в point-free, а расписать do-нотацию (псевдо-императивно), чтобы было всё понятно.

> == «тебя реально не смущает статическая типизация?»

Ну здесь статическая типизация не при чем, если в динамике повторить семантику ИО, то получится такой же код.

Ну здесь статическая типизация не при чем, если в динамике повторить семантику ИО, то получится такой же код.

Имеется ввиду, конечно, статическая типизация языка с разделением чистого / эффектного кода. f 20 в данном случае не пройдёт самого базового тайпчека.

Так дело тут именно в разделении кода, а не в типизации. В динамике с подобным разделением тайпчек пройдет (потому что тайпчека и нет), но даст ошибку в рантайме.

> Ну вот, приходится f' явно передавать :)

Если не передавать f' явно, то это будет называться «глобальной переменной».

«Торчащее наружу ИО» - это когда нам приходится писать код, учитывающий особенности взаимодействия с этим ИО. По крайней мере - такого мое понимание.

Так нам приходится. В любом языке. Мы не можем, например, закэшировать результат - нам нужно выполнять функцию не один раз.

Ну вот, приходится f' явно передавать

Гм. А как ты собираешься использовать нечто (результат new-witdraw) в нескольких разных функциях, не передавая это явно?

> Так нам приходится. В любом языке.

В варианте схемке не приходится, например.

Гм. А как ты собираешься использовать нечто (результат new-witdraw) в нескольких разных функциях, не передавая это явно?

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

В варианте схемке не приходится, например.

Дочитай до конца то, на что отвечаешь. Приходится.

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

Да. Перечитай ещё раз вопрос.

Или ты таки имеешь в виду «сделать глобальную переменную»?

> Дочитай до конца то, на что отвечаешь. Приходится.

Дочитал. При чем тут возможность закешировать результат? Не приходится.

Или ты таки имеешь в виду «сделать глобальную переменную»?

А с этим есть какие-то проблемы?