Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, deniok, Вы писали:
D>>Здрасьте! ФЯ и есть засахаренная лямбда. Т>Как известно по крайней мере с 1965 года, практически любой ЯП есть засахаренная лямбда.
Эквивалентен — да. Является — нет. (Я про чистые ФЯ говорю.) Всякие комбинаторные редукции затруднены для языков, непосредственно апеллирующих к тьюринговой архитектуре вычислителя.
Re[18]: method(obj) то же самое, что и obj.method() ? Что за
Здравствуйте, LaPerouse, Вы писали:
LP>Здравствуйте, deniok, Вы писали:
D>>Современные ФЯ позволяют хранить состояния, не нарушая чистоты. Вопрос их изоляции решается, например, с помощью системы типов. Просто состояние — не предмет первой необходимости при функциональном подходе.
LP>Нет. Не существует такого способа хранить состояние и при этом избежать side-эффектов. Не хотите же вы привести монады из Haskell, которые являются чистым костылем к оригинальному ФП?
Какой костыль? С помощью компактно и математически строго заданной системы типов монтируется языковая конструкция, позволяющая ввести в язык состояние. Монада — это не что-то приделанное к языку сбоку. Это просто один из "интерфейсов" (классов типов), которые реализован на самом языке. Фактически монады — это просто сделанный на самом языке DSL, позволяющий монтировать цепочки вычислений с унифицированным неявным протаскиванием любой доп.информации вдоль цепочки.
LP>Опять-таки, расхождение в терминологии. Вы под ФП, по всей видимости, имеете ввиду то, что реализовано в современных ФЯ. Я же под ФП понимаю его первоначальную трактовку, которая как раз начисто отрицает всякое состояние.
А под ООП? Тогда уж давай говорить, что ООП — это объекты с состоянием, обменивающиеся сообщениями и ничего больше. Идея очень плодотворная, но все другие, более поздние идеи, при таком подходе, к ООП отношения не имеют.
Re[15]: method(obj) то же самое, что и obj.method() ? Что за
Здравствуйте, Sinclair, Вы писали:
SJA>>А если хранить указатель на указатель на ф-цию ? Тогда привешивание доп. ф-ий повлияет на все указатели. S>Что ты понимаешь под словом "привешивание"? Подумай внимательнее, и учти, что никаких модификаций у существующих структур/функций нет.
Но на уровне рантайма модификации то могут быть ? Вот пусть компилятор транслирует "указатель на объект" в программе на указатель на указатель на функцию в реальном коде.
А применнеие ф-ии к объекту транслирует в добавление ф-ии в этот список. При этом меняется только указатель на ф-ию.
Здравствуйте, LaPerouse, Вы писали:
SJA>>Вообще-то в моём примере изменяется список, но голова списка остаётся по одному и тому-же адресу. Этот адрес можно пеердать куда угодно. Причём при каждом доступе к объекту он должен пересоздаться заново (в коде приложения нельзя создать объект из ф-ии и сохранить на него ссылку).
LP>Списки вообще-то тоже должны быть immutable.
Этот список не виден приложению, и изменяется фреймворком.
Так же как Haskell не видит десктруктивного присваивания регистру eax
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, deniok, Вы писали:
D>>Эквивалентен — да. Является — нет.
Т>Боюсь, я недостаточно подкован, для философкой дискуссии о тождественности и эквивалентности.
Ну я далёк от абстрактных философствований
Я имел в виду лишь тот тот факт, что переменные, которые у нас имеются в лямбда-исчислении, например x y и z в
\x y z -> x (y x)
и переменные, как ячейки ленты в тьюринговой архитектуре — это не одно и то же. Первые в принципе неизменяемы. Во вторые можно писать.
А по вычислительной мощности оба подхода эквивалентны (ты это имел ввиду, говоря про 1965 год?). Но детали архитектуры вычислителя и способы работы с ним — весьма различаются. И чистый ФП-подход как раз существенным образом основан на оптимизациях, связанных с редукциями лямбда-термов.
Re[19]: method(obj) то же самое, что и obj.method() ? Что за
Скажите, возможно ли в Haskell определить типы, которые рекурсивно содержат друг друга?
К примеру, нечто такое
class A
{
int state;
A child = new A();
ArrayList<A> childs = new ArrayList<A>();
}
D>А под ООП? Тогда уж давай говорить, что ООП — это объекты с состоянием, обменивающиеся сообщениями и ничего больше.
Все верно. Имеются общеивестные критерии ООП: инкапсуляция, полиморфизм, наследование. Из этих критериев, в частности, следует, что "объекты с состоянием, обменивающиеся сообщениями". И в этом смысле ООП он и в Африке ООП: языки, которые не поддерживают его концепции не являются ОО-языками.
D>Идея очень плодотворная, но все другие, более поздние идеи, при таком подходе, к ООП отношения не имеют.
Какие такие идеи? Я уже сказал, что существуют вполне четкие критерии, позволяющие однозначно определить, вписываются ли такие "поздние идеи", такие, наспример, как "аспекты", в формат ООП.
Впрочем, мне хотелось бы, чтобы вы сосредоточились на ответе на первый вопрос, т к остальное приведет лишь к пустопоржней болтовне, которая мне неинтересна.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[20]: method(obj) то же самое, что и obj.method() ? Что за
Здравствуйте, LaPerouse, Вы писали:
LP>Скажите, возможно ли в Haskell определить типы, которые рекурсивно содержат друг друга?
LP>К примеру, нечто такое
LP>
LP>class A
LP>{
LP>int state;
LP>A child = new A();
LP>ArrayList<A> childs = new ArrayList<A>();
LP>}
LP>
Уточню: разумеется, экземпляры дочерних типов, в отличие от Java, входят в родительский контейнер (иное противоречит идеям ФП). Т е в этом как раз смысл "соджержат друг-друга", а не "ссылаются друг на друга".
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[20]: method(obj) то же самое, что и obj.method() ? Что за
Здравствуйте, LaPerouse, Вы писали:
LP>Скажите, возможно ли в Haskell определить типы, которые рекурсивно содержат друг друга?
LP>К примеру, нечто такое
LP>
LP>class A
LP>{
LP>int state;
LP>A child = new A();
LP>ArrayList<A> childs = new ArrayList<A>();
LP>}
LP>
Конечно. Рекурсивные типы данных — один из основных инструментов.
Собственно тип списка так и определяется (в Стандартных Библиотеках немножко другая терминология, но суть та же)
data List a = Nil | Cons a (List a)
Список — это полиморфный тип, поскольку тип a здесь любой (a называется переменной типа). List — это конструктор типа, он описывает общий shape этого типа (фактически — однопараметричность). Nil и Cons — это конструкторы данных, их типы:
Nil :: List a
Cons :: a -> List a -> List a
Соответственно можем конструировать
my_list = Cons 'a' (Cons 'b' (Cons 'c' Nil)) -- имеет тип List Char
В Стандартных Библиотеках Nil — это [], а Cons — это оператор (:), то есть конструирование выглядит так
my_list = 'a':'b':'c':[] -- имеет тип [Char]
А то, что ты описываешь похоже на multiway trees (rose trees), которые тоже есть в стандартных библиотеках:
data Tree a = Node {
rootLabel :: a
subForest :: (Forest a)
}
type Forest a = [Tree a] -- список деревьев (type - это вроде C++ного typedef)
Значение state будет храниться в a, которым этот тип параметризован.
Re[20]: method(obj) то же самое, что и obj.method() ? Что за
Здравствуйте, LaPerouse, Вы писали:
LP>Все верно. Имеются общеивестные критерии ООП: инкапсуляция, полиморфизм, наследование. Из этих критериев, в частности, следует, что "объекты с состоянием, обменивающиеся сообщениями". И в этом смысле ООП он и в Африке ООП: языки, которые не поддерживают его концепции не являются ОО-языками.
D>>Идея очень плодотворная, но все другие, более поздние идеи, при таком подходе, к ООП отношения не имеют.
LP>Какие такие идеи? Я уже сказал, что существуют вполне четкие критерии, позволяющие однозначно определить, вписываются ли такие "поздние идеи", такие, наспример, как "аспекты", в формат ООП.
LP>Впрочем, мне хотелось бы, чтобы вы сосредоточились на ответе на первый вопрос, т к остальное приведет лишь к пустопоржней болтовне, которая мне неинтересна.
Я имел ввиду то, что смешно при сравнении ограничивать одну парадигму концепциями времени её зарождения, а для другой брать современное состояние. Соответственно предложил считать, что ООП == Simula 67 (например). Это была шутка.
Re[20]: method(obj) то же самое, что и obj.method() ? Что за
Hello, LaPerouse!
You wrote on Sat, 07 Jul 2007 10:20:31 GMT:
L> Все верно. Имеются общеивестные критерии ООП: инкапсуляция, L> полиморфизм, наследование. Из этих критериев, в частности, L> следует, что "объекты с состоянием, обменивающиеся сообщениями". И L> в этом смысле ООП он и в Африке ООП: языки, которые не L> поддерживают его концепции не являются ОО-языками.
Уже не раз говорилось о том, что наследование — не обязательный признак ОО-языка.
Наследование, в частности — это способ обеспечить полиморфизм в статически типизированных языках. При наличии динамической типизации без наследования можно обойтись.
Posted via RSDN NNTP Server 2.1 beta
Re[21]: method(obj) то же самое, что и obj.method() ? Что за
Здравствуйте, deniok, Вы писали:
D>Здравствуйте, LaPerouse, Вы писали:
LP>>Скажите, возможно ли в Haskell определить типы, которые рекурсивно содержат друг друга?
LP>>К примеру, нечто такое
D>
D>data Tree a = Node {
D> rootLabel :: a
D> subForest :: (Forest a)
D>}
D>type Forest a = [Tree a] -- список деревьев (type - это вроде C++ного typedef)
D>
D>Значение state будет храниться в a, которым этот тип параметризован.
1. По смыслу Node — это нечто вроде совокупности полей. Является ли Node ключевым словом?
2. rootLabel — это что, родитель для данной ячейки дерева? Предположим, у нас есть функция, которая принимает объект-ячейку дерева. Этот объект immutable, поэтому ф-ция модифицирует объект и возвращает его копию. У той копии rootLabel будет ссылаться на ячейку-родитель старого дерева, до тех пор, пока ячейка-родитель старого дерева не менялась, ведь так? Иди при любом изменении (в смысле создании при изменении) любой ячейки будет заново пересоздавться вся иерархия? В приницпе, это вопрос реализации, но все хотелось бы понять.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[21]: method(obj) то же самое, что и obj.method() ? Что за
Здравствуйте, YК, Вы писали:
YК>Hello, LaPerouse! YК>You wrote on Sat, 07 Jul 2007 10:20:31 GMT:
L>> Все верно. Имеются общеивестные критерии ООП: инкапсуляция, L>> полиморфизм, наследование. Из этих критериев, в частности, L>> следует, что "объекты с состоянием, обменивающиеся сообщениями". И L>> в этом смысле ООП он и в Африке ООП: языки, которые не L>> поддерживают его концепции не являются ОО-языками.
YК>Уже не раз говорилось о том, что наследование — не обязательный признак ОО-языка. YК>Наследование, в частности — это способ обеспечить полиморфизм в статически типизированных языках. При наличии динамической типизации без наследования можно обойтись.
Все же критерии ООП именно такие: полиморфизм, инкапсуляция, наследование. Это не я сказал. Если выкинуть отсюда что-либо, быть может это и будет ООП в ВАШЕМ понимании, но это не будет ООП в соответствии с его определением.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[22]: method(obj) то же самое, что и obj.method() ? Что за
Здравствуйте, LaPerouse, Вы писали:
LP>Здравствуйте, deniok, Вы писали:
D>>Здравствуйте, LaPerouse, Вы писали:
LP>>>Скажите, возможно ли в Haskell определить типы, которые рекурсивно содержат друг друга?
LP>>>К примеру, нечто такое
D>>
D>>data Tree a = Node {
D>> rootLabel :: a
D>> subForest :: (Forest a)
D>>}
D>>type Forest a = [Tree a] -- список деревьев (type - это вроде C++ного typedef)
D>>
D>>Значение state будет храниться в a, которым этот тип параметризован.
LP>1. По смыслу Node — это нечто вроде совокупности полей. Является ли Node ключевым словом? LP>2. rootLabel — это что, родитель для данной ячейки дерева? Предположим, у нас есть функция, которая принимает объект-ячейку дерева. Этот объект immutable, поэтому ф-ция модифицирует объект и возвращает его копию. У той копии rootLabel будет ссылаться на ячейку-родитель старого дерева, до тех пор, пока ячейка-родитель старого дерева не менялась, ведь так? Иди при любом изменении (в смысле создании при изменении) любой ячейки будет заново пересоздавться вся иерархия? В приницпе, это вопрос реализации, но все хотелось бы понять.
Черт, только что не заметил, что rootlabel имеет тип а. Почему то показалось, что Tree. Все же вопрос остается в силе. Возможно ли в хасклее ссылваться на родителя? Если можно, то интересцет ответ на пред. вопрос.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Re[22]: method(obj) то же самое, что и obj.method() ? Что за
LP>1. По смыслу Node — это нечто вроде совокупности полей. Является ли Node ключевым словом?
Нет, это обычный конструктор данных (единственный для типа Tree):
Node :: a -> Forest a -> Tree a
LP>2. rootLabel — это что, родитель для данной ячейки дерева?
rootLabel и subForest это функции-селекторы, эквивалент имён полей структуры:
rootLabel :: Tree a -> a
subForest :: Tree a -> Forest a
Они добавлены для удобства использования — тип можно было бы описать и без них (и без Forest)
data Tree a = Node a [Tree a]
Представь себе дерево директорий, у каждой директории есть список (Forest) субдиректорий и "имя" (rootLabel как раз возвращает "имя" директории. Ну то есть именем это будет в случае Tree String. А так там хранится значение произвольного типа a — параметрический полиморфизм в действии ).
LP>Предположим, у нас есть функция, которая принимает объект-ячейку дерева. Этот объект immutable, поэтому ф-ция модифицирует объект и возвращает его копию. У той копии rootLabel будет ссылаться на ячейку-родитель старого дерева, до тех пор, пока ячейка-родитель старого дерева не менялась, ведь так? Иди при любом изменении (в смысле создании при изменении) любой ячейки будет заново пересоздавться вся иерархия? В приницпе, это вопрос реализации, но все хотелось бы понять.
Да нет же. Всё вообще неизменяемое. Поэтому новые деревья могут легко использовать куски старых, если им для создания они требуется. Это легче пояснить на списках:
old = [1,2,3]
add_head x xs = x:xs -- добавляет элемент x в голову списка xs
new = add_head 5 old -- [5,1,2,3]
В памяти будет так (стрелочки задают указатели)
old -> 1 -> 2 -> 3 -> null
^
|
new -> 5
Re[22]: method(obj) то же самое, что и obj.method() ? Что за
LP>Все же критерии ООП именно такие: полиморфизм, инкапсуляция, наследование. Это не я сказал. Если выкинуть отсюда что-либо, быть может это и будет ООП в ВАШЕМ понимании, но это не будет ООП в соответствии с его определением.
Здесь была масса холиваров по этому поводу, можно воспользоваться поиском. Не стоит начинать ещё один. Для современных мэйнстримовых статически типизированных языков это действительно общепринятые критерии. RSDN community в наиболее трезвомыслящей его части (сугубое ИМХО ) пришло к выводу, что лучшее (наиболее полное) однострочное определение сущности ООП — это объекты с состоянием, обменивающиеся сообщениями.
Re[23]: method(obj) то же самое, что и obj.method() ? Что за
Здравствуйте, LaPerouse, Вы писали:
LP>Черт, только что не заметил, что rootlabel имеет тип а. Почему то показалось, что Tree. Все же вопрос остается в силе. Возможно ли в хасклее ссылваться на родителя? Если можно, то интересцет ответ на пред. вопрос.
Что значит ссылаться? В Хаскелле описывается алгебраическая структура данных. При этом допустима (и широко используется) рекурсия. В этом смысле да, можно.
Но никаких ссылок на мутабельные объекты там в принципе нет. Да и объектов нет, есть выражения. Имя связывается с выражением раз и навсегда. Это же чистая функциональщина
Re[20]: method(obj) то же самое, что и obj.method() ? Что за
Здравствуйте, LaPerouse, Вы писали:
LP>Все верно. Имеются общеивестные критерии ООП: инкапсуляция, полиморфизм, наследование.
Это не общеизвестные критерии. Общеизвестные привёл deniok. Это то, как определил ООП создатель этого термина.
LP> Из этих критериев, в частности, следует, что "объекты с состоянием, обменивающиеся сообщениями". И в этом смысле ООП он и в Африке ООП: языки, которые не поддерживают его концепции не являются ОО-языками.
ОО-языки без наследования не ОО-языки?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[22]: method(obj) то же самое, что и obj.method() ? Что за
Здравствуйте, LaPerouse, Вы писали:
LP>2. rootLabel — это что, родитель для данной ячейки дерева? Предположим, у нас есть функция, которая принимает объект-ячейку дерева. Этот объект immutable, поэтому ф-ция модифицирует объект и возвращает его копию. У той копии rootLabel будет ссылаться на ячейку-родитель старого дерева, до тех пор, пока ячейка-родитель старого дерева не менялась, ведь так? Иди при любом изменении (в смысле создании при изменении) любой ячейки будет заново пересоздавться вся иерархия? В приницпе, это вопрос реализации, но все хотелось бы понять.
В ФП нет объектов, есть значения. Однако на монадах можно построить аналог ссылок, которые будут ссылаться то на одно значение, то на другое (т.е. менять состояние). Это будет полностью аналогично языку с состоянием, только вместо int тип будет ref int, а вместо MyObject соответственно ref MyObject. Изменим значение в ссылке на другое — все наблюдатели это увидят.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[22]: method(obj) то же самое, что и obj.method() ? Что за
Тогда уж давай говорить, что ООП — это объекты с состоянием, обменивающиеся сообщениями и ничего больше. Идея очень плодотворная, но все другие, более поздние идеи, при таком подходе, к ООП отношения не имеют. 
) пришло к выводу, что лучшее (наиболее полное) однострочное определение сущности ООП — это объекты с состоянием, обменивающиеся сообщениями.
