Re[17]: ФП и абстракция списка
От: geniepro http://geniepro.livejournal.com/
Дата: 04.06.07 17:45
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD2> Как видишь тут идут разговоры о метапрограммировнии на базе системы типов, т.е. внеполовом извращении.


То есть смоллтокеры, занимающиеся метапрограммированием на метаклассах (на базе систему типов) — тоже извращенцы?

Влад, ты зашорил своё представление о метапрограммировании макросами Лиспов и Немерле, а ведь есть и другие способы...

В конце концов, что есть метапрограмма? Это всего лишь программа, которая при трансляции или выполнении порождает другую программу (имею в виду — программу на том же языке, а не в машинных кодах), которая потом и выполняется.

Почему это нужно делать только на макросах-то???
Re[9]: ФП и абстракция списка
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.06.07 18:40
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Абстактный тип данных неполностью удовлетворяет принципу инкапсуляции. АДТ не обязан иметь состояние и идентити. Без них — нет объектов и нет никакого ООП.


АТД — это практически интерфейс плюс конструктор. Он родился в императивном мире. Состояние в нем не быть не может.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: ФП и абстракция списка
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.06.07 18:40
Оценка:
Здравствуйте, geniepro, Вы писали:

G>Здравствуйте, VladD2, Вы писали:


VD2>> Как видишь тут идут разговоры о метапрограммировнии на базе системы типов, т.е. внеполовом извращении.


G>То есть смоллтокеры, занимающиеся метапрограммированием на метаклассах (на базе систему типов) — тоже извращенцы?


Вобще-то я за всю жизнь не видел ни одной прогарммы на Смолтоке (чтобы она что-то полезное делала). Так что говорить о нем как о чем-то реальном у меня рука не поднимается

Но все же их упражнения с метаклассами:
1. Не является полноценным средством МП, так как не опзволяет порождать код. Код они порождкают в виде текстовых строк, которые могут тупо интепретироват (возможно джитить).
2. Это не является нецеливым использованием системы типов. Их метаклассы — это захардкоженая реализация фабрик лассов. К саомй системе типов отношения не имющая.

С++ же, и как я понимаю, Хаскель испльзуют побочные эффекты работы именно ситемы типов.

G>Влад, ты зашорил своё представление о метапрограммировании макросами Лиспов и Немерле, а ведь есть и другие способы...


Я знаком со всеми известными на дакнный момент системами МП. И прекрасно понимаю как и что в них работает. Так что не надо.

G>В конце концов, что есть метапрограмма? Это всего лишь программа, которая при трансляции или выполнении порождает другую программу (имею в виду — программу на том же языке, а не в машинных кодах), которая потом и выполняется.


Не при трансляци, а при работе. Мета-программа — это программа порождающая программу. Все. Более ничего. Так вот есть огромная разница в том являются ли средства МП продуманными и что называется "нарошными", и когда используются разные побочные эффекты средств которые для данной цели не были предназначены. Второй путь ведет к дикому переусложению, неполноценности, и как следствие, к вострженным возгласам "а Вася Пупкин на ххх умудрился фибаначи посчитать". Причем такой бред несется с горящими глазками, как будто была решена вселенская задача, а не примитивный, никому не нужный примерчик.

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

G>Почему это нужно делать только на макросах-то???


Да пофигу как это назвать. Главное чтобы было полноценно, удобно и не через зад.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: ФП и абстракция списка
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.06.07 18:40
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>тебе же сказали по существу — прочти статью Вадлера, разберись с тем, что такое type classes


Я разабрался с тем, что такое классы типов, по крайней мерее в той степени, чтобы понимать что это такое.

Так что если есть, что сказать... иначе не фига засорять эфир.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: ФП и абстракция списка
От: deniok Россия  
Дата: 04.06.07 19:08
Оценка: 15 (1)
Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Gaperton, Вы писали:


G>>Абстактный тип данных неполностью удовлетворяет принципу инкапсуляции. АДТ не обязан иметь состояние и идентити. Без них — нет объектов и нет никакого ООП.


VD>АТД — это практически интерфейс плюс конструктор. Он родился в императивном мире. Состояние в нем не быть не может.


Ты что-то часто стал апеллировать к такой "неестественной" науке, как история

ADT — это абстрактный тип данных, и чем больше он абстрагирован, тем лучше.

Например, стек:
это три операции
push :: Stack -> Elem -> Stack
pop :: Stack -> Stack
top :: Stack -> Elem

и два закона
pop (push s e) === s
top (push s e) === e

Этого достаточно для описания аксиоматической семантики ADT стек (хотя можно ещё расширить её с помощью isEmpty). Язык описания, как ты понимаешь, можно выбрать другой.
Re[11]: ФП и абстракция списка
От: deniok Россия  
Дата: 04.06.07 22:16
Оценка:
в качестве ремарки:

Обобщаем интерфейс
f :: a -> b -> a
g :: a -> a
h :: a -> b

+ те же законы
g (f s e) === s
h (f s e) === e

Любая пара типов a и b, с заданным набором функций f, g, h, подчиняющихся этим двум законам, всё равно образуют АТД стек.

А есть там в реализации состояние или нет — это дело десятое. И эту абстракцию ты в ООП не выразишь.
Re[11]: ФП и абстракция списка
От: Трурль  
Дата: 05.06.07 05:55
Оценка: :)
Здравствуйте, deniok, Вы писали:
D> Язык описания, как ты понимаешь, можно выбрать другой.
Например
{} push(s,e) {top(s)=e}
{top(s)=e} push(s,x);pop(s) {top(s)=e}

Re[9]: ФП и абстракция списка
От: BulatZiganshin  
Дата: 05.06.07 07:03
Оценка:
VD>Я разабрался с тем, что такое классы типов, по крайней мерее в той степени, чтобы понимать что это такое.

нет, Влад, не разобрался. ты судишь о них чисто по синтаксическим свойствам, не понимая, как они реализуются. напомнить тебе ещё раз про передачу невидимого аргумента?
Люди, я люблю вас! Будьте бдительны!!!
Re[19]: ФП и абстракция списка
От: BulatZiganshin  
Дата: 05.06.07 07:07
Оценка:
VD>С++ же, и как я понимаю, Хаскель испльзуют побочные эффекты работы именно ситемы типов.

я же тебе ясно сказал, что система типов используеьтся для своих целей, TH — для своих. последний полностью аналогичен макросам в немерле или любой другой системе и иногда является не самым простым способом что-то реализовать. у тебя же всё как всегда сводится к лозунгам: макросы хорошо (посокльку они есть в немерле), система типов плохо (поскольку есть в C++). неужто ты не понимаешь, что некоторые задачи решаются проще на одном, другие — на другом?
Люди, я люблю вас! Будьте бдительны!!!
Re[10]: ФП и абстракция списка
От: Gaperton http://gaperton.livejournal.com
Дата: 05.06.07 09:21
Оценка:
Здравствуйте, VladD2, Вы писали:

G>>Абстактный тип данных неполностью удовлетворяет принципу инкапсуляции. АДТ не обязан иметь состояние и идентити. Без них — нет объектов и нет никакого ООП.


VD>АТД — это практически интерфейс плюс конструктор. Он родился в императивном мире. Состояние в нем не быть не может.


Состояния в нем может не быть.

class Queue
{
public:
  Queue push( Element ) const;

  struct Pair
  {
    Queue queue;
    Element element;
  }

  Pair Queue pop() const;
}


Как нет состояния в этом классе. Как в любом хаскельном АДТ — нет состояния. Как в таких АДТ Эрланга как queue и gb_tree.
Re[19]: ФП и абстракция списка
От: awson  
Дата: 05.06.07 10:12
Оценка: -1
Здравствуйте, VladD2, Вы писали:

VD>Да пофигу как это назвать. Главное чтобы было полноценно, удобно и не через зад.


Вот именно
Автор: BulatZiganshin
Дата: 05.06.07
.

Для некоторых (понятно, не для всех) задач метапрограммировние на типах несопоставимо выразительнее и мощнее макросов. Догадайся, почему.
Re[7]: ФП и абстракция списка
От: dstatyvka  
Дата: 06.06.07 09:48
Оценка: +1
Здравствуйте, VladD2, Вы писали:


VD>С Хаскелем у меня вопросов нет. У меня вопрос в том может ли сама парадигма ФП предоставить что-то для решения этой проблемы? Или все она нуждается в расширении некой идеологией сходной с иделогией ОО-интерфейсов или классов типов Хаскеля?


Вопрос аналогичен следующему: "может ли сама парадигма императивного программирования предоставить что-то для решения этой проблемы?". Ответ на оба вопроса: "Нет, не может. Задача, неформулируемая в терминах парадигмы не может быть решена исключительно средствами парадигмы."
Re[3]: ФП и абстракция списка
От: Кодт Россия  
Дата: 06.06.07 09:54
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Замечательно. Только в Хаскеле классы типов — это фактически вариант интерфейсов. А их воплощения ни что иное как аналог реализации интерфейсов в классаях.

VD>Выходит используется фактически ОО-подход.
VD>Не так ли?

Холиварная тема, но всё-таки выскажусь. Не соглашусь насчёт ОО.
Классам типов Хаскелла можно найти аналогию в ОО-мире, и это действительно будут интерфейсы. Фикус в том, что это действие — поиск аналогии — наш произвол.
Особенность ООП — это полиморфизм времени исполнения. Классы типов же относятся исключительно ко времени компиляции. В этом плане Эрланг с его традицией передавать кортежи с тэгами гораздо более похож на ООЯ, чем Хаскелл.
... << RSDN@Home 1.2.0 alpha rev. 655>>
Перекуём баги на фичи!
Re[4]: ФП и абстракция списка
От: BulatZiganshin  
Дата: 06.06.07 10:05
Оценка:
К>Особенность ООП — это полиморфизм времени исполнения. Классы типов же относятся исключительно ко времени компиляции.

это не так. читай статью Вадлера или объяснения, которые я давал Владу. повторять это в 4-й раз у меня нет желания
Люди, я люблю вас! Будьте бдительны!!!
Re[12]: ФП и абстракция списка
От: Кодт Россия  
Дата: 06.06.07 10:25
Оценка: +1 :)))
Здравствуйте, VladD2, Вы писали:

BZ>>немерле-подобных языках


VD>О. Новая терминалогия. Оказывается Немерле является родоначальником целой плеяды языков.


Подобно тому, как военачальник не строит армию с нуля, а возглавляет и направляет в бой готовую структуру, созданную его предшественниками.
... << RSDN@Home 1.2.0 alpha rev. 655>>
Перекуём баги на фичи!
Re[8]: ФП и абстракция списка
От: Кодт Россия  
Дата: 06.06.07 10:25
Оценка: +1
Здравствуйте, <Аноним>, Вы писали:

А>>>видишь ли, полиморфизм не реализуется неким волшебным образом. есть различные механизмы его реализации, которые отражаются в выразительных средствах языка. например, в C++ нет оверлоадинга по возвращаемому типу — это невомзожно в ООП. в хаскеле (и templates, afaik) такое поддерживается


СТ>>Это потому что тип возвращаемого значения в С++ не входит в сигнатуру, и mangled names для функций отличающихся только им будут одинаковы.


А>в сигнатуру он как раз входит, но для выбора реализации метода не используется. и это ограничение возникло не с бухты-барахты, оно является следствием используемой в ООП реализации классов. информация о типе содержится только в самих объектах, поэтому невозможно выбрать между двумя функциями, различающимися только возвращаемым типом. в отличие от этого в реализации type classes информация о типе передаётся отдельным аргументом, поэтому такое ограничение отсутствует. надеюсь в третий (или четвёртый?) раз объяснять одно и то же не придётся?


Думаю, что дело в другом. У С++, как у наследника С, есть развитая система неявного приведения типов. Которая катастрофически усложняет вывод типа от результата к аргументам.
long foo(long);
char foo(char);

int bar(int);

int main()
{
    auto x = 0; // 0 - полиморфный литерал
    int y = bar(/*здесь неявный оператор приведения*/foo(x)); // какое из foo вызвать?
    // возможно, что многими этажами ниже будет ясно, что x - это исключительно long или исключительно char
    // но может быть и так, что x участвует и в других неявных преобразованиях или сложных уравнениях
}


Хиндли-Милнеровские языки разными способами избегают этого:
— запрет неявных приведений
— диагностика неоднозначности с сообщением об ошибке
— ограничение контекста для уравнений (например, зависимость только от предшествующих, но не последующих определений констант)
— использование универсального вариантного типа в случае дефолта
... << RSDN@Home 1.2.0 alpha rev. 655>>
Перекуём баги на фичи!
Re[9]: ФП и абстракция списка
От: BulatZiganshin  
Дата: 06.06.07 11:08
Оценка:
А>>в сигнатуру он как раз входит, но для выбора реализации метода не используется. и это ограничение возникло не с бухты-барахты, оно является следствием используемой в ООП реализации классов. информация о типе содержится только в самих объектах, поэтому невозможно выбрать между двумя функциями, различающимися только возвращаемым типом. в отличие от этого в реализации type classes информация о типе передаётся отдельным аргументом, поэтому такое ограничение отсутствует. надеюсь в третий (или четвёртый?) раз объяснять одно и то же не придётся?

К>Думаю, что дело в другом. У С++, как у наследника С, есть развитая система неявного приведения типов. Которая катастрофически усложняет вывод типа от результата к аргументам.


не в большей степени, чем обратный вывод

что действительно является приницпиальным ограничением, так это передача словаря методов класса (VMT) как части объекта. нет объекта — нет и VMT. в type classes она передаётся отдельно, поэтому можно сделать что-нибудь в духе

class C a where
  nul :: a
instance C Int where
  nul = 0
main = print (nul + length [])


в C++ есть templates, которые ввиду их резолвинга во время компиляции не обладают этим ограничением, и насколько я понимаю, тоже отлично резолвятся в обе стороны
Люди, я люблю вас! Будьте бдительны!!!
Re[10]: ФП и абстракция списка
От: Кодт Россия  
Дата: 06.06.07 11:55
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

К>>Думаю, что дело в другом. У С++, как у наследника С, есть развитая система неявного приведения типов. Которая катастрофически усложняет вывод типа от результата к аргументам.


BZ>не в большей степени, чем обратный вывод


BZ>что действительно является приницпиальным ограничением, так это передача словаря методов класса (VMT) как части объекта. нет объекта — нет и VMT.


В чём препятствие? VMT — это кортеж лямбд (которые можно с самого начала замкнуть на конкретный объект — хоть это и оверхед).
Для нормальной работы нужно, чтобы система типов допускала наследование структур.
Кажется, это не ломает ХМ, потому что обращение к определённому полю VMT означает заведомый up-casting до базовой структуры VMT, содержащей это поле, и в дальнейшем информация о типе VMT уже не нужна.
Как-то я путано сказал — поскольку сам до конца не вкурил.
Если можешь привнести ясность — буду благодарен.

BZ> в type classes она передаётся отдельно, поэтому можно сделать что-нибудь в духе


В type classes передаётся статическая информация о типе, там про VMT можно вообще не задумываться (тем более, про VMT конкретных объектов).

BZ>в C++ есть templates, которые ввиду их резолвинга во время компиляции не обладают этим ограничением, и насколько я понимаю, тоже отлично резолвятся в обе стороны


В плюсовых шаблонах утиная типизация — поэтому они и резолвятся (на уровне шаблонов) отлично, что уравнения типов сводятся ну максимум к проверке арности.
... << RSDN@Home 1.2.0 alpha rev. 655>>
Перекуём баги на фичи!
Re[9]: ФП и абстракция списка
От: dstatyvka  
Дата: 06.06.07 12:35
Оценка:
Здравствуйте, VladD2, Вы писали:

D>>Никаких объектов с состояниями (то есть ООП) в классах типов нет.


VD>Ну, состояние конечно же есть. Просто оно не так явно заметно. Иноче свертку массива произвести было бы прсото невозможно.


Откуда взяться состоянию в "чистых" функциях? На которых свертка (fold в частности) реализуется элементарно.

VD>Важно, что мы можем объеявить интерфейс Foldable (не важно будет ли это интерфейс Явы, трэйтс Скалы или класс типов Хаскеля), и реализовать его в/для разных (подчеркиваю, совсем разный) типов (таких как массивы, списки, деревья и т.п.).


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


Не стоит так переживать за собственные мозги, небольшой шок им не повредит. Например, для того, чтобы перестать пытаться заткнуть ОО-средствами императивных языков все дыры.
Кроме того, не думаю, что словосочетание "интерфейс типа данных" было бы удачнее "класс типов данных".
Re[11]: ФП и абстракция списка
От: BulatZiganshin  
Дата: 06.06.07 13:23
Оценка: 111 (6)
К>Если можешь привнести ясность — буду благодарен.

три раза уже вносил для Влада

ладно. вот смотри. есть функция, печатающая значение, условно говоря, объекта. для этого она вызывает функцию, возвращающую строкове представление этого объекта:

print x = putStrLn (show x)


для осукществления своих коварных планов она должна каким-то образом помимо *данных* x получить и *функцию*, переводящую x в строку. какие здесь есть варианты:

1) в compile time подставить тело print в каждую точку вызова и выбрать нужную реализацию show в каждой точке вызова отдельно. т.е. compile-time polymorphism. он реализуется в C++ механизмом overload и темплейтами, которые готовы в любой момент сгенерировать код для нужной комбинации типов. ты, как я порнимаю, до сих пор полагал, что type classes устроены так же

2) сгенерить один-единственный type-independent code для print, и упаковать таблицу виртуальных функций (VMT) вместе с каждым объектом. это и есть ООП подход. когда print должна вызвать функию show — она лезет в VMT и берёт её адрес оттуда. таким образом, один-единственный откомпилированный экземпляр print может работать с любым объектом, реализующим этот интерфейс

3) также сгенерить один-единственный экземпляр print, но передавать информацию обо всех вызываемых полиморфных функиях в так назыавемом словаре класса — дополнительном невидимом аргументе. т.е. после дешугаринга этот вызов выглядит так:

print show x = putStrLn (show x)


если скажем, передаётся объект класса Number, реализующий 4 действия арифметики, то вызов после дешугаринга выглядит как:
double (+,-,*,/) x = x*2


как видишь, все функции класса просто идут в этом неявном аргументе. вот и всё. у этого подхода свои преимущества и недостатки, но главное для FP — что он в отличие от OO classes совместим с HM type inference. поскольку в OOP print может получить объект любого типа — всё определяется в run-time, и весь type inference на этом кончается. с type classes же такой проблемы не возникает. зато, с другой стороны, нельзя например делать полиморфные коллекции без дополнительных ухищрений (фактически эмулирующих VMT)
Люди, я люблю вас! Будьте бдительны!!!
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.