Я читал, что система типа Scala ослаблена взаимодействием Java и поэтому не может выполнять некоторые из тех же полномочий, что и система типов Haskell. Это правда? Является ли слабость из-за стирания стилей, или я ошибаюсь во всех отношениях? Разве эта разница является причиной того, что у Scala нет стилей?Недостатки системы типа Scala по сравнению с Haskell?
Большое различие заключается в том, что Scala не имеет вывода глобального типа Hindley-Milner и вместо этого использует форму вывода локального типа, требуя указать типы параметров метода и тип возвращаемого значения для перегруженных или рекурсивных функций.
Это не управляется стиранием типа или другими требованиями JVM. Все возможные трудности здесь могут быть преодолены и были рассмотрены, просто рассмотрим Jaskell - http://docs.codehaus.org/display/JASKELL/Home
Вывод H-M не работает в объектно-ориентированном контексте. В частности, когда используется тип-полиморфизм (в отличие от ad-hoc-полиморфизма классов типов). Это имеет решающее значение для сильного взаимодействия с другими библиотеками Java и (в меньшей степени) для получения наилучшей оптимизации от JVM.
Нельзя сказать, что либо у Haskell, либо у Scala есть более сильная система типов, только они разные. Оба языка подталкивают границы для программирования по типу в разных направлениях, и каждый язык обладает уникальными сильными сторонами, которые трудно дублировать в другом.
В главе 16 демонстрируются типы данных Scala и сопоставление образцов, разрабатывающих систему вывода типов в стиле H/M http: //www.scala -lang.org/docu/files/ScalaByExample.pdf – oluies
«Вывод HM не работает в объектно-ориентированном контексте». Но F # реализует H-M и имеет объектно-ориентированную сторону. –
@Mauricio: Да, и OCaml - еще лучший пример счетчика, потому что он отображает типы классов ... –
Scala не имеет rank-n types, хотя в некоторых случаях возможно work around this limitation.
На связанную ноту, она также не поддерживает impredicativity. –
Еще один интересный момент, который следует учитывать, заключается в том, что Scala напрямую поддерживает классический стиль OO. Это означает, что существуют отношения подтипов (например, List является подклассом Seq). И это делает вывод типа более сложным. Добавьте к этому факт, что вы можете смешивать в чертах Scala, что означает, что данный тип может иметь несколько отношений супертипа (делая его еще более сложным)
У меня мало опыта с Haskell, но самое очевидное, что я обратите внимание, что система типа Scala, отличная от Haskell, является типом вывода.
В Scala нет вывода глобального типа, вы должны явно указать тип аргументов функции.
Например, в Scala вам нужно написать следующее:
def add (x: Int, y: Int) = x + y
вместо
add x y = x + y
Это может вызвать проблемы, когда вам нужно дженерик функции добавления, которые работают со всеми видами типа имеет метод «+». Для этого есть обходной путь, но он будет более подробным.
Но в реальности я использовал систему типа Scala, которая достаточно мощна для ежедневного использования, и я почти никогда не использую эти обходные пути для общего типа, возможно, это потому, что я пришел из мира Java.
И ограничение явного объявления типа аргументов не является необходимым, но вам все равно необходимо его документировать.
Система типа Scala отличается от системы Haskell, хотя концепции Scala иногда непосредственно вдохновляются сильными сторонами Haskell и ее знающим сообществом исследователей и профессионалов.
Конечно, работа на виртуальной машине, не предназначенной, в первую очередь, для функционального программирования, в первую очередь создает проблемы совместимости с существующими языками, ориентированными на эту платформу. Поскольку большинство аргументов о типах происходит во время компиляции, ограничения Java (как языка и платформы) во время выполнения ничего не беспокоит (кроме Type Erasure, хотя именно эта ошибка, похоже, делает интеграцию в Java-экосистема более плавная).
Насколько я знаю, единственный «компромисс» на уровне системного уровня с Java - это особый синтаксис для обработки Raw Types. Хотя Scala даже не разрешает использование Raw Types, она принимает старые файлы классов Java с этой ошибкой. Возможно, вы видели код, похожий на List[_] (или более длинный эквивалент List[T] forSome { type T }). Это функция совместимости с Java, но она также рассматривается как экзистенциальный тип и не ослабляет систему типов.
Система типа Scala поддерживает type classes, хотя более подробно, чем Haskell.Я предлагаю прочитать эту статью, которая может создать другое впечатление относительно относительной силы системы типа Scala (таблица на стр. 17 служит хорошим списком очень мощных системных концепций типа).
Не обязательно связанный с мощностью системы типов - это подход, используемый компиляторами Scala и Haskell для определения типов, хотя это влияет на то, как люди пишут код. Имея мощный алгоритм вывода типа, вы можете написать более абстрактный код (вы можете сами решить, хорошо ли это во всех случаях).
В конце концов система типа Scala и Haskell управляется стремлением предоставить своим пользователям лучшие инструменты для решения своих проблем, но они по-разному подходят к этой цели.
+1 для упоминания этой таблицы. –
Экзистенциальные типы не совсем то же самое, что и исходные типы. Например, List [_] не считается равным типу другому списку [_] –
Хорошо, что они Тьюринга приводимы?
См. Страницу Олега Киселева http://okmij.org/ftp/ ... Можно реализовать исчисление лямбда в системе типа Haskell. Если Scala может это сделать, то в некотором смысле система типа Haskell и система типа Scala вычисляют одни и те же типы. Вопросы: насколько естественным является один над другим? Насколько элегантно одно над другим?
Возможно, вы захотите это прочитать. http://lambda-the-ultimate.org/taxonomy/term/32 –
Я уверен, что у Haskell есть как минимум стирание стилей, как это делает Scala, для чего это стоит. –