Здравствуйте, Gaperton, Вы писали: G>Ты почти прав. Только ты упустил главное из ООП-шного инструментария. Что такое "объект"? G>Объект = АДТ (абстрактный тип данных) + состояние G>АДТ = тип данных, определяющийся набором операций над ним. С этим у ФЯ все в порядке.
G>Объект же не просто АДТ — он имеет состояние и "идентити" — т.е. в системе могут существовать два одинаковых по состоянию объекта с разным идентити. В ОО языках роль "идентити" играет указатель. Идентити — непременный атрибут изменяемого состояния и ООП.
Мне кажется, ты тоже упускаешь из виду, что а) многие ОО-паттерны (типа Стратегии) сичтаются архи-важными и архинужными и при этом не используют состояния б) в чистом Хаскеле можно при желании писать императивный код в IO- или ST- монаде, засунув состояние куда-нибудь в IORef.
Re[5]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, Константин Л., Вы писали:
КЛ>А разве map возвращает фукнцию? Вы тут все приводите "лажевые" примеры. Я не про эти случаи говорил
Во-первых, таки да, map возвращает функцию (т.к. у map 2 аргумента, см. карринг). Во-вторых, функция высшего порядка может не только возвращать функции, но и принимать их как аргументы. Какой у map первый аргумент?
Re[6]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, palm mute, Вы писали:
PM>Здравствуйте, Константин Л., Вы писали:
КЛ>>А разве map возвращает фукнцию? Вы тут все приводите "лажевые" примеры. Я не про эти случаи говорил PM>Во-первых, таки да, map возвращает функцию (т.к. у map 2 аргумента, см. карринг). Во-вторых, функция высшего порядка может не только возвращать функции, но и принимать их как аргументы. Какой у map первый аргумент?
1. какую функцию возвращает map?
2. как наличие 2х аргументов может коррелировать с тем, что map возвращает функцию
3. Я уже в курсе, что такое фвп и этот пример был для меня понятен
Re[8]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, Константин Л., Вы писали:
КЛ>1. какую функцию возвращает map? КЛ>2. как наличие 2х аргументов может коррелировать с тем, что map возвращает функцию
addOneToAllItems = map (+1)
Re[6]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, Константин Л., Вы писали:
Л>1. какую функцию возвращает map? КЛ>2. как наличие 2х аргументов может коррелировать с тем, что map возвращает функцию КЛ>3. Я уже в курсе, что такое фвп и этот пример был для меня понятен
let memorize f =
let hash = hash.create ....
\arg ->
try hash arg
with hash_fail -> hash.add f arg; hash arg;
let process_data file = .....
let process_data_m = memorize process_data;
Is it clear?
Re[9]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, Quintanar, Вы писали:
Q>Здравствуйте, Константин Л., Вы писали:
Л>>1. какую функцию возвращает map? КЛ>>2. как наличие 2х аргументов может коррелировать с тем, что map возвращает функцию КЛ>>3. Я уже в курсе, что такое фвп и этот пример был для меня понятен
Q>
Q>let memorize f =
Q> let hash = hash.create ....
Q> \arg ->
Q> try hash arg
Q> with hash_fail -> hash.add f arg; hash arg;
Q>let process_data file = .....
Q>let process_data_m = memorize process_data;
Q>
Q>Is it clear?
no, it is not completely clear for me, but i've caught basic idea
Re[7]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, Mamut, Вы писали:
КЛ>>А разве map возвращает фукнцию?
M>Мне достаточно уже того, что оно принимает функцию в качестве параметра
КЛ>>Вы тут все приводите "лажевые" примеры. Я не про эти случаи говорил
M>А про какие? Такие http://rsdn.ru/Forum/Message.aspx?mid=2458010&only=1
Здравствуйте, palm mute, Вы писали:
PM> в чистом Хаскеле можно при желании писать императивный код в IO- или ST- монаде, засунув состояние куда-нибудь в IORef.
Хм... А зачем вообще писать императивный код на Хаскеле? Не прощели сделать интероп с теми языками, где императивность — родная парадигма?
... << RSDN@Home 1.2.0 alpha rev. 672>>
Re[10]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, konsoletyper, Вы писали:
PM>> в чистом Хаскеле можно при желании писать императивный код в IO- или ST- монаде, засунув состояние куда-нибудь в IORef. K>Хм... А зачем вообще писать императивный код на Хаскеле? Не прощели сделать интероп с теми языками, где императивность — родная парадигма?
Во-первых, я говорил о принципиальной возможности. Т.е., как и говорил, все для реализации ООП, включая identity и изменяемое состояние, в Хаскеле есть.
Во-вторых, весь ввод-вывод через интероп и сделан. Фокус в том, что у foreign-вызовов такой тип, что императивный по сути код формально остается чисто функциональным.
Re[11]: Надо посты перечитывать перед отправкой, блин
Здравствуйте, Mamut, Вы писали:
M>Для человека, знающего, что такое map, второй код будет намного читабильнее. И таких примеров можно придумать много (как и котрпримеров, кстати )
Жаль, правда, что код не идентичный.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Mamut, Вы писали:
M>>Для человека, знающего, что такое map, второй код будет намного читабильнее. И таких примеров можно придумать много (как и котрпримеров, кстати )
VD>Жаль, правда, что код не идентичный.
Почему?
<< RSDN@Home 1.1.4 stable SR1 rev. 568>>
Сейчас играет Blind Guardian — And The Story Ends
Re[9]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, palm mute, Вы писали:
PM>Здравствуйте, Gaperton, Вы писали: G>>Ты почти прав. Только ты упустил главное из ООП-шного инструментария. Что такое "объект"? G>>Объект = АДТ (абстрактный тип данных) + состояние G>>АДТ = тип данных, определяющийся набором операций над ним. С этим у ФЯ все в порядке.
G>>Объект же не просто АДТ — он имеет состояние и "идентити" — т.е. в системе могут существовать два одинаковых по состоянию объекта с разным идентити. В ОО языках роль "идентити" играет указатель. Идентити — непременный атрибут изменяемого состояния и ООП.
PM>Мне кажется, ты тоже упускаешь из виду, что а) многие ОО-паттерны (типа Стратегии) сичтаются архи-важными и архинужными и при этом не используют состояния
Я такие паттерны, и паттерны вообще упускаю из вида вполне намеренно — так как считаю, что они к делу не особенно относятся. Эти паттерны, не требующие состояния, тебе не особо помогут объектную декомпозицию выполнить, если ты не можешь в объект состояние завернуть. Как и вообще-паттерны. Я это между прочим на примере показал, где проблема будет
б) в чистом Хаскеле можно при желании писать императивный код в IO- или ST- монаде, засунув состояние куда-нибудь в IORef.
Попробуй решить проблему в моем примере. Кольцо из объектов, измени состояние. Посмотрим, что у тебя получится, и насколько это будет практично. К слову — пока ни у кого не получалось . Что не удивительно — получиться это не может.
Re[11]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, palm mute, Вы писали:
PM>Здравствуйте, konsoletyper, Вы писали:
PM>>> в чистом Хаскеле можно при желании писать императивный код в IO- или ST- монаде, засунув состояние куда-нибудь в IORef. K>>Хм... А зачем вообще писать императивный код на Хаскеле? Не прощели сделать интероп с теми языками, где императивность — родная парадигма? PM>Во-первых, я говорил о принципиальной возможности. Т.е., как и говорил, все для реализации ООП, включая identity и изменяемое состояние, в Хаскеле есть.
Ты до сих пор не показал, как ты сделаешь из всего этого объект. А ты попробуй. Многие до тебя говорили, что мол ерунда, но ни у кого это сделать не получалось.
Это я так вежливо формулирую свою мысль, которая состоит в том, что ты в корне неправ, и это сделать невозможно. Объяснения я уже привел выше. Предлагаю возразить мне примером.
PM>Во-вторых, весь ввод-вывод через интероп и сделан. Фокус в том, что у foreign-вызовов такой тип, что императивный по сути код формально остается чисто функциональным.
Одно дело ввод-вывод, и совсем другое — объектная декомпозиция (не паттерны, а именно декомпозиция — подход к моделированию состояния сложной системы). Сие есть радикально разные вещи, имеющие мало общего.
Re[6]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Mamut, Вы писали:
M>>Для человека, знающего, что такое map, второй код будет намного читабильнее. И таких примеров можно придумать много (как и котрпримеров, кстати )
VD>Жаль, правда, что код не идентичный.
А мы его немного не то чтобы изменим, а слегка дополним...
inline template< class F, class A >
A& map( A &arr, F some_func )
{
for(i = 0; i < arr.length; i++)
{
some_func(arr[i]);
}
return arr;
}
versus //?!
arr = [1, 2, 3, 4];
map(arr, some_func);
Теперь вроде как идентичен
Re[10]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, Gaperton, Вы писали:
G>б) в чистом Хаскеле можно при желании писать императивный код в IO- или ST- монаде, засунув состояние куда-нибудь в IORef. G>Попробуй решить проблему в моем примере. Кольцо из объектов, измени состояние. Посмотрим, что у тебя получится, и насколько это будет практично. К слову — пока ни у кого не получалось . Что не удивительно — получиться это не может.
module OO where
import Control.Monad
import Data.IORef
type Mutable = IORef
data MyObject = MyObject { state :: Mutable Int,
otherObject :: Mutable (Maybe MyObject) }
deriving Eq
nullObject = newIORef Nothing
createMyObject :: Int -> IO MyObject
createMyObject init = do
x <- newIORef init
other <- nullObject
return (MyObject {state=x, otherObject=other})
setOther obj other = writeIORef (otherObject obj) (Just other)
readOther obj = readIORef (otherObject obj)
modifyState obj = modifyIORef (state obj)
readState obj = readIORef (state obj)
makeObjLoop = do
o1 <- createMyObject 1
o2 <- createMyObject 2
o3 <- createMyObject 3
setOther o1 o2
setOther o2 o3
setOther o3 o1
return o1
printLoop o = printLoop' o []
where printLoop' obj visited = when (not (obj `elem` visited)) $ do
n <- readState obj
nextRef <- readOther obj
putStrLn (show n)
case nextRef of
Just next -> printLoop' next (obj:visited)
Nothing -> putStrLn "You lied, this is not loop"
main = do
loop <- makeObjLoop
printLoop loop
modifyState loop (+1)
printLoop loop
modifyState loop (+100)
printLoop loop
Оно? Или ты что-то более сложное имел в виду? Прошу обратить внимание на 'deriving Eq' и 'obj `elem` visited' — это обещанная Identity. Полиморфизму сверху добавить тоже можно.
з.ы. Я не говорю, что так нужно делать, но можно — факт
)
