Ответ на »сообщение 5864« (AVC)
___________________________
Просто с определенной (а не вообще) точки зрения (обероновской) между между структурной и утиной типизацией нет принципиального различия.
Конечно -- IMHO.
Ах вот вы о чем. Как инструмент полиморфизма конечно, результат достигается один и тот же. А вот механика принципиально разная.
Скажем как циклы в императивных языках и функции высшего порядка (map, fold, filter) в функциональных.
Созданы для одного и того же - циклической обработки данных, и результат работыт один и тот же. А вот уже механика принципиально различна.
Настолько различна что мы с вами имеем императивные языки и функциональные языки, да еще и ругаемся постоянно. Что лучше ? for или map ?

Также и c duck typing vs structural subtyping. Один - динамический механизм, другой - статический.

Ответ на »сообщение 5864« (AVC)
___________________________
Это очень похоже на принцип размерности в физике: килограммы нельзя складывать с секундами, хотя структурно и те, и другие выражаются через значение с плавающей точкой.

Простите но в очередной раз сталкиваюсь с суждениями о том чего вы не пробовали.
Опишите килограммы и секунды как типы в хаскеле и он точно так же запретит вам их складывать.
Откуда такие страхи по поводу вещей которые вы никогда даже не видели ?
Почему оберон (то с чем вы знакомы) будет понимать разницу между секундами и киллограммами, а хаскель (то с чем вы незнакомы) обящательно должен тут споткнуться ? Вы что сталкивались с этим на практике ? Явно нет.
Вы читали об этом ну хоть ГДЕ НИБУДЬ ? Тоже вряд ли, иначе привели бы ссылку давно.
В чем дело ?

Раз уж разговор зашел об этом, вот вам хаскелевская библиотека http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dimensional-0.7

Dimensional, a library providing data types for performing arithmetic with physical quantities and units. Information about the physical dimensions of the quantities and units is embedded in their types and the validity of operations is verified by the type checker at compile time.

Как раз то о чем вы говорили. Можете привести в пример библиотеку оберона, работающюю таким же образом с физическими метриками ?

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

>>>Продолжаете играть в непонимание.

Просто с определенной (а не вообще) точки зрения (обероновской) между между структурной и утиной типизацией нет принципиального различия.
Конечно -- IMHO.

>>>А structural subtyping - то что есть в языках с системой типов Hindler Milner (ocaml, haskell)

Ну вот мы и подобрались к ответу на Ваш вопрос, почему трусливые оберонщики объявляют типы, а не доверяют выводить их компилятору.
Дело в том, что в Обероне принята не структурная, а номинативная типизация.
Типы могут иметь одинаковую структуру, но разный смысл.
Передать смысл только через структуру трудно, вот и используют явное (намеренное) объявление типа.
В Обероне это связано прежде всего со структурными типами: массивами и записями.
Ада пошла дальше и применила тот же принцип к простым (базовым) типам.
Это очень похоже на принцип размерности в физике: килограммы нельзя складывать с секундами, хотя структурно и те, и другие выражаются через значение с плавающей точкой.

Ответ на »сообщение 5862« (AVC)
___________________________
Продолжаете играть в непонимание.
Из приведенной вами же статьи:
утиная типизация (калька с англ. Duck typing) — вид динамической типизации, применяемой в некоторых языках программирования 

Вам еще раз указать на разницу между динамической и статической типизацией ? И результат этой разницы ?
То что в осамле это не duck typing а structural subtyping.
Разница заключается в том что в динамической типизации вы можете написать любую чушь, и узнать что это чушь только после того как успешно запущенная программа дойдет до этого места и выяснит, что то что предполагалось будет крякать на самом деле мычит.
А structural subtyping - то что есть в языках с системой типов Hindler Milner (ocaml, haskell)
дает вам (почти) такую же свободу и легкость полиморфизма как и динамическая типизация, но при этом сохраняя проверку при компиляции. То есть то что мычит, даже по ошибке не будет передано как крякающая утка.

А я, оказывается, неоригинален:
http://ru.wikipedia.org/wiki/Утиная_типизация
Шаблоны в Си++ реализуют статическую форму неявной типизации. Различные итераторы, например, не обязаны наследоваться от общего класса, но могут быть использованы в единой манере, если реализуют соответствующие методы.
И даже:Другим близким подходом является структурные подтипы в OCaml, где типы объектов совместимы если совместимы сигнатуры их методов, независимо от объявленного наследования, причём всё это проверяется во время компиляции программы.

Ответ на »сообщение 5860« (AVC)
___________________________
Если судить по сообщению »сообщение 5849«, то да. :)

Ошибаетесь. Я не знаю как вы читали, но я там четко указал - с сохранением статической типизации.
То есть программа проверяет на этапе компиляции соответствие типов, а не доверяется на "похожесть крякания" в runtime.
Потому и указал вам на различия между динамическим питоном и статическим хаскелем.

Странно что строннику статического оберона это еще надо разжевывать.

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

Ответ на »сообщение 5858« (AVC)
___________________________
>>>Тот же принцип: если крякает, значит утка.

И каким боком сюда хаскелевсике типы классов ? Они тоже крякают ?

Если судить по сообщению »сообщение 5849«, то да. :)

Ответ на »сообщение 5858« (AVC)
___________________________
Тот же принцип: если крякает, значит утка.

И каким боком сюда хаскелевсике типы классов ? Они тоже крякают ?

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

>>>Не смешите мои тапочки. Вы срьезно сравниваете динамическую типизпцию питона со статической хаскеля и приходите к выводу что это "одно и то же" ? или "так же работает" ?

А почему нет?
Разве шаблоны Си++ не похожи на статическую разновидность "утиной" типизации?
Тот же принцип: если крякает, значит утка.

А тапочки лучше убрать подальше от монитора. Например, на пол. :)

>>>А шаблоны в си++ вообще из разряда ночных кошмаров.

Из серии книг для Си++ников "Кошмар, который всегда с тобой". :)

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

Ответ на »сообщение 5855« (Дядя .СЭМ)
___________________________

... вручить ему цикл обобщающий LOOP. Это - смело. С удовольствием посмотрю эти "игры разума".

Вы лучше книжку Дейкстры почитали бы, чтобы не путаться, кто что обобщает.


Говоря что цикл Дейкстры обобщает цикл LOOP я подразумеваю что для каждой конкретной реализации цикла LOOP существует непустое множество, семантически эквивалентных ей, реализаций цикла Дейкстры.
Умных людей нужно читать и перечитывать, так что давайте почитаем - Э. Декстра, Дисциплина программирования. /пер. с англ. - М.:МИР, 1978, стр. 66:

Основная теорема для конструкции повторения применительно к условию P, сохраняемому инвариантно истинным, утверждает, что

(P and wp(DO, T)) => (DO, P and non BB)

Здесь член wp(DO, T) представляет собой слабейшее предусловие, такое , что конструкция повторения завершится. Если задана произвольная конструкция DO, то в общем случае очень трудно (а может быть, невозможно) определить wp(DO, T). Поэтому я предлагаю проектировать наши конструкции повторения, постоянно помня о требовании завершимости, т.е. предлагаю искать подходящее доказательство завершимости и строить программу таким способом, чтобы она удовлетворяла предложениям, на которых основывается это доказательство.


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