Здравствуйте, Кодт, Вы писали:
G>>Предлагаю перейти с Хаскелла на Лискелл! G>>Семантика хаскелловская, синтаксис... Синтаксис вторичен! :о))
К>Не выйдет. К>В Хаскелле и Лиспе разное строение синтаксических деревьев, что оказывает влияние на семантику.
Ну вапще-то автор Лискелла утверждает, что Лискелл — это именно хаскеллевская семантика с лисповским синтаксисом.
Даже компилятор Лискелла основан на GHC 5.04...
Здравствуйте, geniepro, Вы писали:
G>Ну вапще-то автор Лискелла утверждает, что Лискелл — это именно хаскеллевская семантика с лисповским синтаксисом. G>Даже компилятор Лискелла основан на GHC 5.04...
Здравствуйте, BulatZiganshin, Вы писали:
BZ>полиморфные коллекции — это соджержащие объекты разных типов, реализующих общий интерфейс. пусть скажем, это фигуры, которые можно рисовать на экране — треугольники, овалы и т.д. если каждый объект включает свою собственную VMT, то из неё вы узнаёте, как нарисовать это конкретный объект. если же вы перелаёте одну VMT на всё-про всё, то нифига хорошего не выйдет реализация этого требует так называемых existentials, которые включают VMT класса вместе с каждым объектом:
BZ>
BZ>diplayAll1 :: Figure a => [a] -> IO ()
BZ>diplayAll2 :: [exist a . Figure a => a] -> IO ()
BZ>
Разве в GHC есть exist? Я думал он через forall делается. Если есть — где почитать?
Насчёт forall — тут уже не будет так однозначно, т.к. тип
[forall a. Figure a => a]
описать можно, но использовать его элементы не получится. Пправда, не знаю почему — читал где-то, что функции не могут быть экзистенциальными, только типы. Т.е.
data Shape = forall a. Figure a => Shape a
displayAll :: [Shape] -> IO ()
displayAll = mapM_ display
Здравствуйте, dstatyvka, Вы писали:
VD>>С Хаскелем у меня вопросов нет. У меня вопрос в том может ли сама парадигма ФП предоставить что-то для решения этой проблемы? Или все она нуждается в расширении некой идеологией сходной с иделогией ОО-интерфейсов или классов типов Хаскеля?
D>Вопрос аналогичен следующему: "может ли сама парадигма императивного программирования предоставить что-то для решения этой проблемы?". Ответ на оба вопроса: "Нет, не может. Задача, неформулируемая в терминах парадигмы не может быть решена исключительно средствами парадигмы."
Это не вопрос. Это подлог. Потому как исходно речь шла об ООП. В ООП такие средства несомненно есть. В ФП,как мы выяснили, нет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dstatyvka, Вы писали:
VD>>>С Хаскелем у меня вопросов нет. У меня вопрос в том может ли сама парадигма ФП предоставить что-то для решения этой проблемы? Или все она нуждается в расширении некой идеологией сходной с иделогией ОО-интерфейсов или классов типов Хаскеля?
D>>Вопрос аналогичен следующему: "может ли сама парадигма императивного программирования предоставить что-то для решения этой проблемы?". Ответ на оба вопроса: "Нет, не может. Задача, неформулируемая в терминах парадигмы не может быть решена исключительно средствами парадигмы."
VD>Это не вопрос. Это подлог. Потому как исходно речь шла об ООП. В ООП такие средства несомненно есть. В ФП,как мы выяснили, нет.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dstatyvka, Вы писали:
VD>>>С Хаскелем у меня вопросов нет. У меня вопрос в том может ли сама парадигма ФП предоставить что-то для решения этой проблемы? Или все она нуждается в расширении некой идеологией сходной с иделогией ОО-интерфейсов или классов типов Хаскеля?
D>>Вопрос аналогичен следующему: "может ли сама парадигма императивного программирования предоставить что-то для решения этой проблемы?". Ответ на оба вопроса: "Нет, не может. Задача, неформулируемая в терминах парадигмы не может быть решена исключительно средствами парадигмы."
VD>Это не вопрос. Это подлог.
Какой подлог? false analogy? это не она Был приведен вопрос, аналогичный обсуждаемому. Ответ был дан на оба вопроса, независимо.
VD>Потому как исходно речь шла об ООП. В ООП такие средства несомненно есть. В ФП,как мы выяснили, нет.
Исходно речь шла о решении проблемы, сформулированной в терминах ООП. Соответственно, можно сказать, что в ФП и проблемы-то такой нет.
Часто вижу, как ярые защитники императивных языков неверно истолковывают слова восторженных функциональщиков о бесполезности ООП. Часто имеется в виду очевидная вещь: в ФП отсутствуют многие проблемы императивного мира, в частности, решаемые средствами ООП (в тех ИЯ, где они есть). Т.е. на достаточно крупной задаче обнаружится наверное необходимость OOD и OO-средств, но этот момент наступит значительно позже, чем в императивном мире при прочих равных условиях. Например, решаемая задача в реальных условиях разработки на ФЯ попросту не возникнет, imo.
Здравствуйте, dstatyvka, Вы писали:
D>Откуда взяться состоянию в "чистых" функциях? На которых свертка (fold в частности) реализуется элементарно.
Подумай.
VD>>Важно, что мы можем объеявить интерфейс Foldable (не важно будет ли это интерфейс Явы, трэйтс Скалы или класс типов Хаскеля), и реализовать его в/для разных (подчеркиваю, совсем разный) типов (таких как массивы, списки, деревья и т.п.).
VD>>Причем в Хаскеле это решили демонсративно назвать подругому (хотя все равно получилось несколько ООП-ообразно, классы все же тоже попахивают ООП-ом). Хотя ничто не мешало не компостировать могз окружающим и назвать это интерфейсами.
D>Не стоит так переживать за собственные мозги, небольшой шок им не повредит. Например, для того, чтобы перестать пытаться заткнуть ОО-средствами императивных языков все дыры.
Алё! Гараж? Я вообще-то говорил о выборе устоявшихся терминов. Другими словами, о том, что не стоит придумывать уникальную терминалогию без необходимости.
D>Кроме того, не думаю, что словосочетание "интерфейс типа данных" было бы удачнее "класс типов данных".
А зачем "интерфейс типа данных" просто "интерфейс" было бы достаточно. Просто особенность Хаскеля заключается в том, что интерфес может быть реализован и для уже существующего типа данных, в том время как в классических ЯП они обычно реализуются в самом описании типа данных. Это несомненно очень удобная особенность, но сути дела она все же не меняет.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dstatyvka, Вы писали:
D>Исходно речь шла о решении проблемы, сформулированной в терминах ООП. Соответственно, можно сказать, что в ФП и проблемы-то такой нет.
Проблема есть. Ести кто-то ее не хочет замечать, то это его проблемы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>у тебя же всё как всегда сводится к лозунгам: макросы хорошо (посокльку они есть в немерле), система типов плохо (поскольку есть в C++).
Примеры подобных высказываний с моей стороны в студию. До тех пор будем считать это вымыслом.
BZ>неужто ты не понимаешь, что некоторые задачи решаются проще на одном, другие — на другом?
Я заню только две задачи которые на С++ диелаются лучше всего:
1. Писать С++-код.
2. Делать ошибки.
Если этих задач не стоит, то всгеда можно найти лучший инструмент.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BulatZiganshin, Вы писали:
К>>Особенность ООП — это полиморфизм времени исполнения. Классы типов же относятся исключительно ко времени компиляции.
BZ>это не так. читай статью Вадлера или объяснения, которые я давал Владу. повторять это в 4-й раз у меня нет желания
Лучше давать сыылку...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
D>>Откуда взяться состоянию в "чистых" функциях? На которых свертка (fold в частности) реализуется элементарно.
VD>Подумай.
Э... Просветишь? На всякий случай напомню, что чистыми называются функции, результат вычисления которых зависит исключительно от значений ее параметров.
VD>>>Причем в Хаскеле это решили демонсративно назвать подругому (хотя все равно получилось несколько ООП-ообразно, классы все же тоже попахивают ООП-ом). Хотя ничто не мешало не компостировать могз окружающим и назвать это интерфейсами.
D>>Не стоит так переживать за собственные мозги, небольшой шок им не повредит. Например, для того, чтобы перестать пытаться заткнуть ОО-средствами императивных языков все дыры.
VD>Алё! Гараж? Я вообще-то говорил о выборе устоявшихся терминов. Другими словами, о том, что не стоит придумывать уникальную терминалогию без необходимости.
Согласен, но в данном случае, необходимость очевидна, по меньшей мере, тем, кто потрудился выяснить суть обсуждаемого термина. Я думаю, этому (выяснению) может мешать костность мышления, часто преодолеваемая при помощи шоковой терапии.
Кстати, использование терминов class и instance в Haskell я тоже не считаю удачным решением, в силу той же перегруженности терминов.
D>>Кроме того, не думаю, что словосочетание "интерфейс типа данных" было бы удачнее "класс типов данных".
VD>А зачем "интерфейс типа данных" просто "интерфейс" было бы достаточно.
'Просто "интерфейс"' — термин очень перегруженный.
VD>Просто особенность Хаскеля заключается в том, что интерфес может быть реализован и для уже существующего типа данных, в том время как в классических ЯП они обычно реализуются в самом описании типа данных. Это несомненно очень удобная особенность, но сути дела она все же не меняет.
В целом, мысль понятна. Однако, классы типов в Haskell допускают default-рализацию, в том числе частичную, что, согласись, также не свойственно интерфейсам в обсуждаемом смысле, ближе к абстрактным классам в ОО.
Здравствуйте, VladD2, Вы писали:
VD>Алё! Гараж? Я вообще-то говорил о выборе устоявшихся терминов. Другими словами, о том, что не стоит придумывать уникальную терминалогию без необходимости.
Классы типов — это не ОО-интерфейсы. Не скажу "совсем не", скорее "не совсем". Возможно поэтому то и термин взяли "неустоявшийся".
Вот класс типа MArray и его реализация.
class (HasBounds a, Monad m) => MArray a e m
instance MArray (STArray s) e (ST s)
Какой тип данных реализует здесь "интерфейс" MArray?
Здравствуйте, lomeo, Вы писали:
L>Классы типов — это не ОО-интерфейсы. Не скажу "совсем не", скорее "не совсем". Возможно поэтому то и термин взяли "неустоявшийся".
А может, такое быть, что "класс типов" термин устоявшийся, но только у математиков?
Здравствуйте, no4, Вы писали:
no4>А может, такое быть, что "класс типов" термин устоявшийся, но только у математиков?
Сомневаюсь. Устоявшийся он, по видимому, только в Haskell.
Поскольку, насколько я знаю, впервые появился в этом языке.
Первая статья о них -- это, кажется, Вадлеровская "How to Make Ad-Hoc Polymorphism Less Ad Hoc", где они и были предложены.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>нет, Влад, не разобрался. ты судишь о них чисто по синтаксическим свойствам, не понимая, как они реализуются. напомнить тебе ещё раз про передачу невидимого аргумента?
Напомин.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Перекуём баги на фичи!
