Кодирование стандартных модулей ML в OO

Модуль модуля ML выступает в качестве знака высокого уровня поддержки языка программирования для абстракция данных. Однако внешне кажется, что он легко может быть закодирован на объектно-ориентированном языке, который поддерживает элементы абстрактного типа. Например, мы можем кодировать элементы модульной системы SML в Scala следующим образом:

Подписи SML: Scala черты без конкретных элементов
Структуры SML с заданными сигнатурами: Scala объекты, расширяющие заданные черты
Функторы SML, параметризованные данными сигнатурами: Scala классы, принимающие объекты, расширяющие заданные черты как аргументы конструктора

Есть ли какие-либо существенные функции, которые может пропустить кодировка? Что-нибудь, что может быть выражено в модулях SML, которые кодировка не может выразить? Любые гарантии, что SML делает невозможным создание этой кодировки?

Ответ 1

Есть несколько принципиальных отличий, которые вы не можете легко преодолеть:

Подписи ML являются структурными типами, признаками Scala являются: подпись подписи ML может быть сопоставлена любым соответствующим модулем после факта, для объектов Scala вам необходимо объявить отношение во время определения. Аналогично, подтипирование между подписями ML является полностью структурным. Scala уточнения ближе к структурным типам, но имеют некоторые довольно серьезные ограничения (например, они не могут ссылаться на свои собственные определения локального типа и не содержат свободных ссылок на абстрактные типы вне их сферы).
Подписи ML могут быть составлены структурно с использованием include и where. Результирующая подпись эквивалентна встроенному расширению соответствующего сигнатурного выражения или уравнения типа. Scala состав смеси, хотя и более мощный во многих отношениях, снова является номинальным и создает неэквивалентный тип. Даже порядок композиции имеет значение для эквивалентности типов.
Функторы ML параметризуются структурами и, следовательно, обоими типами и значениями, Scala общие классы только параметризуются типами. Чтобы закодировать функтор, вам нужно превратить его в общую функцию, которая принимает типы и значения отдельно. В общем, это преобразование, называемое фазовым расщеплением в литературе ML-модуля, не может быть ограничено только определением и использованием функторов, поскольку на своих сайтах-вызовах оно должно быть рекурсивно применено к вложенным аргументам структуры; это в конечном итоге требует, чтобы все структуры последовательно разделялись по фазе, что не является стилем, который вы хотите запрограммировать вручную. (Также нет возможности сопоставлять функторы простым функциям в Scala, поскольку функции не могут выражать необходимые зависимости типов между параметрами и типами результатов. Edit: поскольку 2.10, Scala поддерживает зависимые методы, которые могут кодировать некоторые примеры SML первообразные функторы первого порядка, хотя в общем случае это не представляется возможным).
ML имеет общую теорию рафинирования и распространения информации о "полупрозрачном" типе. Scala использует более слабую экваториальную теорию "зависимых от пути" типов, где пути обозначают объекты. Scala таким образом обрабатывает ML более выразительные эквиваленты типов для возможности использования объектов (с членами типа) в качестве значений первого класса. Вы не можете легко обойтись без быстрого решения проблем разрешимости или надежности.
Edit: ML может, естественно, выражать конструкторы абстрактного типа (т.е. типы более высокого типа), которые часто возникают с функторами. Для Scala необходимо активировать более высокие типы, которые более сложны для его системы типов и, по-видимому, приводят к неразрешимой проверке типов.

Различия становятся еще более интересными, когда вы переходите за пределы SML, к более высоким, первоклассным или рекурсивным модулям. Мы кратко обсудим несколько вопросов в Разделе 10.1 нашей MixML.