Ответ на »сообщение 3239« (Geniepro)
___________________________

>Асинхронное ООП в моем понимании не сильно отличается от декларатива (то бишь вообще не отличается).

Это вообще поразительное утверждение. Этак можно договориться, что Смоллток - диалект Пролога... :о))

Утверждение про асинхронное ООП следует из »сообщение 3142«.

Ответ на »сообщение 3249« (Geniepro)
___________________________

Евгений, спасибо. Очень интересная информация для размышлений.

Ответ на »сообщение 3246« (Jack Of Shadows)
___________________________

Руслан, говорили же много раз про type classes. Где вы там пришпиливание к контейнеру увидели ?

Это я увидел? Может быть, все же Евгений? :)

См. »сообщение 3159«:
>Как только вы пришпиливаете функции к данным, вы становитесь заложником этой связки. Если же данные и функции отдельно, то очень легко создавать новые типы данных, и новые функции работы с ними. Не нужно ничего ни к чему привязывать.

А Вы не задумывались над тем, что можно иметь и то, и другое? Отдельно -- пришпиливание процедур (методов) к типам и отдельно -- функции?


Реакция на него Евгения. См. »сообщение 3241«:
Ну так это так и сделано в Хаскелле - классы типов, содержащие в себе методы работы со значениями разных логически схожих типов, и просто функции...

Моя реакция. См. »сообщение 3242«:
Как сообразуется Ваше высказывание с негативным высказыванием Вагифа про пришпиливание процедур к типам (про инкапсуляцию)? См. »сообщение 3154« и »сообщение 3135«.

Реплика Евгения. См. »сообщение 3243«:
У Вагифа негатив был к пришпиливанию изменяемого состояния к типам, насколько я понял...

Ваша реплика. См. »сообщение 3246«:
Руслан, говорили же много раз про type classes. Где вы там пришпиливание к контейнеру увидели ?

Мой вывод: как выясняется, есть пришпиливание и пришпиливание. Одно чистое, другое -- грязное. Но я собственно о чистоте в своей реплике и не заикался... :)

Ответ на »сообщение 3244« (Руслан Богатырев)
___________________________

Я имел в виду O'Haskell, OOHaskell. Если делают -- значит, видимо, не хватает.

Делают, как я уже сказал, для забавы, для получения острых ощущений, для проверки на прочность системы типов Хаскелла, да просто что бы получить больший опыт в Хаскелле. Сделали, посмеялись и забыли, ох уж эта академическая элита.... Этими диалектами никто не пользуется...

Не предлагаю убрать монады, просто хочу понять, зачем дублировать императив внутри Хаскеля в том случае, если у Хаскеля появится искусственный ИП-спутник.

Давайте представим, что получится, если убрать имитацию императива из Хаскелла - это do-нотация, в основном. Так как на do-нотации также основан очень популярный и удобный механизм list comprehensions, позволяющий декларативно описывать содержимое списков (которые в Хаскелле являются разновидностью монад), то убирание этого сахара (do-нотации и list comprehensions) чуть-чуть упростит компилятор и заметно понизит удобство использования Хаскелла - придётся вручую писать очень много ненаглядного (э.. в смысле, не имеющего наглядности :о) ) кода. В результате, кто-нибудь просто напишет простейший препроцессор, который реализует и do-нотацию, и list comprehensions. Сейчас этот несложный препроцессор встроен в трансляторы Хаскелла.

Что бы избавиться раз и навсегда от квазиимператива Хаскелла, нужно убрать сами монады. Так как монады в Хаскелле - это просто два класса типов Monad и MonadPlus, то если просто убрать эти два класса, их тут же реализует вручную любой достаточно опытный функциональщик, вместе с тем же препроцессором do-нотации...

Что бы сделать воссоздание монад таким же трудным, неудобным и корявым, как их имитируют в С#, Java и прочих языках, нужно будет избавиться от классов типов, что будет огромнейшим щагом назад, к языкам типа Миранды и ML/O'Caml. Это решение возродит давно забытые (20 лет назад) проблемы с перегрузочным полиморфизмом и статической типизацией с автовыводом типов по алгоритму Хиндли-Милнера. Почитайте статью Корделии Холл и пр. "Type Classes in Haskell" , там описаны те проблемы, которые были просто, элегантно и эффективно решены благодаря классам типов:

- перегрузка операций сравнения на равенство и неравенство;
- перегрузка арифметических операций + - * / и т.д.;
- преобразование значений разных типов в строковое представление.

Этой проблемы нет в динамически типизируемых языках, в императивных языках это реализуется просто, так как там нет автовывода типов по Хиндли-Милнеру, в ООП своя система перегрузочного полиморфизма, которую к ФП не пришлёпаешь. Так что до классов типов в языках вроде Миранды и ML приходилось иметь на каждый числовой тип свои собственные обозначения арифметических операций (ML) или просто ограничившись одним-единственным числовым типом (Миранда)... Короче, классы типов позволили просто и ясно решить эту проблему.

Так и что же получается? Стоит ли ради сомнительного удовольствия ограничить Хаскелл чисто функционально-декларативными возможностями убирать такую фундаментальную для Хаскелла вещь, как его систему типов, введя в него старые нелогичные попытки вроде ML-ных? Не знаю, что за мёртворождённый кадаврик это получится, но уж точно это не будет Хаскеллом, лабораторией типов...

Ответ на »сообщение 3236« (Илья Ермаков)
___________________________

Т.е. циклом while вы пользоваться не умеете. Только рассуждаете о том, какой он правильный. Так и запишем.

Ответ на »сообщение 3238« (Geniepro)
___________________________
Евгений, спасибо за комментарий и ссылки. Сделал себе несколько закладок в браузере. :)

Руслан, говорили же много раз про type classes. Где вы там пришпиливание к контейнеру увидели ?
Функции описанные в type classes все также принимают значения через параметры и все также возвращают новое значение, ничего ни в каком контейнере не меняя.
писывая тип как принадлежащий к каому то классу, вы всего лишь даете знать что функции в этом классе будут принимать параметры этого типа. Естественно для вашего нового типа эти функции придется переопределить, когда вы описываете свой новый тип как instance какого то класса типов.
Ближайшим аналогом type classes в ОО наверное будут интерфейсы.

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

Ответ на »сообщение 3240« (Geniepro)
___________________________

Ответ на »сообщение 3153« (Евгений Непомнящий)
___________________________
Пролог, кстати, не имеет отношения к ФП - это язык логического программирования, которое вместе с функциональным составляет ветку декларативного программирования, противостоящую ветке императивного программирования, в которую входят процедурное и ООП...
В императив ещё стоит, видимо, добавить автоматное.
А в декларатив - марковское.

Ответ на »сообщение 3243« (Geniepro)
___________________________

>Аналогично: может ли он обойтись без ООП, если за это отвечает свой язык?

В стандартном Хаскелле-98 нет и намёков на ООП, тем не менее хаскеллеры прекрасно пользуются Хаскеллом, иногда, правда, ради забавы придумывая разные диалекты для разных целей, в частности вводя расширяемые записи аля Оберон...


Я имел в виду O'Haskell, OOHaskell. Если делают -- значит, видимо, не хватает.

>Как сообразуется Ваше высказывание с негативным высказыванием Вагифа про пришпиливание процедур к типам (про инкапсуляцию)?

У Вагифа негатив был к пришпиливанию изменяемого состояния к типам, насколько я понял...

Раз сомнения -- подождем, как прокомментирует сам Вагиф, как сообразуются Ваши высказывания с его.

>Может ли Haskell обойтись без работы с миром императива через монады? Если будет для этого специальный язык (вне Haskell'я)?

Вопрос непонятен. Вы хотите убрать монады и упростить Хаскелл на один процент, но при этом потерять треть его возможностей? Смысл?
Императивная работа с вводом/выводом - это лишь маленький побочный эффект введения монад в Хаскелл...

Не предлагаю убрать монады, просто хочу понять, зачем дублировать императив внутри Хаскеля в том случае, если у Хаскеля появится искусственный ИП-спутник.

Ответ на »сообщение 3242« (Руслан Богатырев)
___________________________

Как сообразуется Ваше высказывание с негативным высказыванием Вагифа про пришпиливание процедур к типам (про инкапсуляцию)?

У Вагифа негатив был к пришпиливанию изменяемого состояния к типам, насколько я понял...

Может ли Haskell обойтись без работы с миром императива через монады? Если будет для этого специальный язык (вне Haskell'я)?

Вопрос непонятен. Вы хотите убрать монады и упростить Хаскелл на один процент, но при этом потерять треть его возможностей? Смысл?
Императивная работа с вводом/выводом - это лишь маленький побочный эффект введения монад в Хаскелл...

Аналогично: может ли он обойтись без ООП, если за это отвечает свой язык?

В стандартном Хаскелле-98 нет и намёков на ООП, тем не менее хаскеллеры прекрасно пользуются Хаскеллом, иногда, правда, ради забавы придумывая разные диалекты для разных целей, в частности вводя расширяемые записи аля Оберон...