M>> Чтобы голову не заморачивать
VD>map должен возвращать другой массив/список, а не менять имеющися. А проблемы ява-скрипов пусть так и остаются их проблемами.
Будем считать особенностями реализации В С++ вон map — это вообще тип данных, и ничего
Здравствуйте, VladD2, Вы писали:
VD2> На замечание о ужасности и громоздкости кода начинашь о знаниях языка рассуждать.
ООП для Хаскелла инороден, а потому и ООП-код на нём выглядит громоздко...
С другой стороны, на С++ такой же код выглядел бы наверняка ещё более громоздко и ужастно...
Re[15]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, geniepro, Вы писали:
G>ООП для Хаскелла инороден, а потому и ООП-код на нём выглядит громоздко...
+10 G>С другой стороны, на С++ такой же код выглядел бы наверняка ещё более громоздко и ужастно...
Да ну, кольцевой список и модификация состояния там как раз получаются абсолютно естественно, т.к. вместо IORef (Maybe MyObject) будет просто my_object*, вместо writeIORef будет '=', вместо readIORef будет просто обращение к переменной, тут С++ на своем поле и состязаться с ним трудно. У С++ другие проблемы.
Re[15]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, Mamut, Вы писали:
M>>>Для человека, знающего, что такое map, второй код будет намного читабильнее. И таких примеров можно придумать много (как и котрпримеров, кстати )
VD>>Жаль, правда, что код не идентичный.
G>А мы его немного не то чтобы изменим, а слегка дополним...
Ну, если уж по честному дополнять, то это будет примерно так: G>
Соответственно, накладываються ограничения на тип контейнера и на тип возврата функции.
Можно, вместо явной передачи контейнера перейти на итераторы — тогда придём к std::transform или std::for_each в зависимости от того нужен нам результат или нет.
Т.е.
Здравствуйте, Tonal-, Вы писали:
T>Соответственно, накладываються ограничения на тип контейнера и на тип возврата функции. T>Можно, вместо явной передачи контейнера перейти на итераторы — тогда придём к std::transform или std::for_each в зависимости от того нужен нам результат или нет.
Вот transform и есть map, только как и многое в С++ громоздкий и неудобный.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, VladD2, Вы писали: T>>Можно, вместо явной передачи контейнера перейти на итераторы — тогда придём к std::transform или std::for_each в зависимости от того нужен нам результат или нет.
VD>Вот transform и есть map
Если нам результат map-а не нужен, то std::for_each вполне канает.
Хотя в чистом ФП мап без результата похоже не часто встречается.
VD>, только как и многое в С++ громоздкий и неудобный.
Стоит упомянуть С++ или Python и "Остапа понесло"
... << RSDN@Home 1.2.0 alpha rev. 677>>
Re[10]: Так в чем же принципиальные отличия ФП от ИП?
Здравствуйте, Tonal-, Вы писали:
VD>>Вот transform и есть map T>Если нам результат map-а не нужен, то std::for_each вполне канает. T>Хотя в чистом ФП мап без результата похоже не часто встречается.
В чистом ФП функции без возвращаемого значения вообще не бывает
Re[12]: Так в чем же принципиальные отличия ФП от ИП?
M>>Будем считать особенностями реализации В С++ вон map — это вообще тип данных, и ничего
VD>Там мы сравниваем разные вещи имеющие одинаковые названия, или все же в нас еще осталась чистичка разума?
G>1) Ромбик мне из объектов не изобразите? Чтобы два иорефа в структуре данных на один объект указывали. Зело хоцца на идентити в действии поглядеть.
в хаскеле, ввиду его божественной и несравненной чистоты, нет переменных (variables). но в нём есть ссылки (pointers). поэтому то, что в императивном языке делается с помощью переменных, в хаскеле эмулируется с использованием константных ссылок (не путать со ссылками на константы). итак,
main = do x <- newIORef 1
a <- readIORef x
writeIORef x (a+1)
эвивалетно следующему:
main()
{
int* const x = new int(1);
const int a = *x;
*x = a+1;
}
можно также написать эквивалентный с++ код с использованием references, но они синтаксически-невидимо разыменовываются
итак, в чём разница по сравнению с переменными в C? в дополнительном уровне косвенности (что неэффективно), в необходлимости явного разыменования (причём отдельной командой, внутри выражения это не сделаешь) и явной операции выделения памяти. присваивание внутри выражения тоже невозможно
вообще, когда дело доходит до записи на хаскеле низхкоуровневого императивного кода, дело очень напоминает анекдот "товарищ прапорщик, ну можно я веником подмету?..." для более сложного, высокоуровневого кода ФВП отчасти нивуоируют эту проблему. в принципе, некоторые подходы к решению этой проблемы существуют, но по-большому счёту автоматическое разыменование несколько затруднительно из-за автовывода типов
с другой стороны, в хаскеле низкоуровневый имеративный код я писал только в двух случаях — для general-purpose библиотек, где нужна максимальная эффектвиность, и как часть кода, работающего с низкоуровневыми императивными библиотеками (написанные на C++). писать же императивные алгоритмы обработки данных на хаскеле — это в большинстве случаев нонсенс
В С++ вон map — это вообще тип данных, и ничего 
