Как вывести принуждения?

Question

Я хотел бы знать, как вывести принуждения (неявные преобразования a.k.a.) во время вывода типа. Я использую схему вывода типа, описанную в Top Quality Type Error Messages Бастианом Хереном, но я бы предположил, что общая идея, вероятно, одинакова во всех подходах Хиндли-Милнера-Эска.

Похоже, что принуждение можно рассматривать как форму перегрузки, но подход перегрузки, описанный в этой статье, не рассматривает (по крайней мере, не так, как я мог) перегрузку на основе требований, тип, который является обязательным для принуждения. Я также обеспокоен тем, что такой подход может затруднить уделение приоритета принуждению личности, а также уважение транзитивного закрытия коэрцитивности. Я могу видеть, как сахарное соединение имеет каждое принуждаемое выражение, скажем e, чтобы принудить (e), но сжимая его на принуждение (принуждение (принуждение (...) (e) ...))) для некоторой глубины к максимальному вложению принуждений кажется глупым, а также ограничивает отношение коэрцитивности к чему-то с конечным транзитивным замыканием, глубина которого не зависит от контекста, который кажется (необязательно?) ограничительным.

Answer 1

Не могли бы вы дать немного больше разъяснений относительно того, что именно вы спрашиваете?

У меня есть небольшая идея, и если моя идея правильная, тогда этот ответ должен быть достаточным для моего ответа. Я считаю, что вы говорите об этом с точки зрения того, кто создает язык, и в этом случае вы можете посмотреть на такой язык, как ActionScript 3 для примера. В AS3 вы можете выводить два разных способа: 1) NewType (объект), или 2) объект как NewType.

С точки зрения реализации, я IMAGING каждый класс должен определить его собственные способы преобразования в зависимости от того типа, что может преобразовать (массив не может реально преобразовать в целое ... или может?). Например, если вы попробуете Integer (myArrayObject), а myArrayObject не определяет способ преобразования в Integer, вы можете либо выбросить исключение, либо позволить ему быть и просто передать исходный объект, не прошедший трансляцию.

Весь мой ответ может быть полностью выключен, хотя :-D Дайте мне знать, если это не то, что вы ищете

Answer 2

Я надеюсь, что вы получите хорошие ответы на это.

Я еще не читал бумагу, на которую вы ссылаетесь, но это звучит интересно. Вы вообще посмотрели, как в Haskell работает ad-hoc-полиморфизм (в основном перегрузка)? Система типа Haskell - это H-M плюс некоторые другие лакомства. Один из этих плюсов - это классы типов. Классы типов обеспечивают перегрузку или как вызов Хаскеллера ad-hoc-полиморфизм.

В GHC, наиболее распространенном компиляторе Haskell, классы классов реализуются путем передачи словарей во время выполнения. Словарь позволяет системе времени выполнения выполнять поиск от типа к реализации. Предположительно, jhc может использовать супер-оптимизацию для выбора правильной реализации во время компиляции, но я скептически отношусь к полностью полиморфным случаям, которые может разрешить Haskell, и я не знаю никаких формальных доказательств или документов, подтверждающих правильность.

Похоже, что ваш тип вывода будет сталкиваться с теми же проблемами, что и другие полиморфные подходы ранга-n. Возможно, вы захотите ознакомиться с некоторыми статьями здесь для дополнительного фона: Scroll down to "Papers about types" Его статьи имеют специфический характер, но теоретические данные типа должны быть значимыми и полезными для вас.

Я думаю, что эта статья о ранге п полиморфизма и вопросах проверочного типа должна вызвать некоторые интересные мысли для вас: http://research.microsoft.com/~simonpj/papers/higher-rank/

Я хотел бы обеспечить лучший ответ! Удачи.

Answer 3

Мой опыт заключается в том, что сахарирование каждого термина интуитивно кажется непривлекательным, но стоит преследовать.

Интерес к постоянному хранению привел меня к обходному пути, чтобы рассмотреть проблемы смешения выражений и атомных значений. Чтобы поддержать это, я решил полностью их разделить на систему типов; таким образом, Int, Char и т. д. являются конструкторами типов только для целочисленных и символьных значений. Типы выражений формируются с помощью конструктора полиморфного типа Exp; например Exp Int ссылается на значение, которое сокращается на один шаг до Int.

Уместность этого на ваш вопрос возникает, когда мы рассматриваем оценку. На базовом уровне есть примитивы, которые требуют атомных значений: COND, addInt и т. Д. Некоторые люди ссылаются на это как на принудительное выражение, я предпочитаю видеть его просто как литье между значениями разных типов.

Задача состоит в том, чтобы увидеть, можно ли это сделать без применения явных директив сокращения. Одно из решений точно так же, как вы предлагаете: например, рассматривать принуждение как форму перегрузки.

Скажем, у нас есть входной скрипт: foo x

Затем, после того, как обсахаривания, это становится: (coerce foo) (coerce x)

Где, неформально:

coerce :: a -> b 
coerce x = REDUCE (cast x) if a and b are incompatible 
x       otherwise 

Таким образом принуждать либо личность или приложение от cast где b - тип возврата для заданного контекста.

литье теперь можно рассматривать как метод класса типа, например.

class Cast a, b where {cast :: a -> b }; 
-- ¬:: is an operator, literally meaning: don’t cast 
--(!) is the reduction operator. Perform one stage of reduction. 

-- Reduce on demand 
instance Cast Exp c, c where { inline cast = ¬::(!)(\x::(Exp c) -> ¬::(!)x) }; 

В ¬:: аннотации используются для подавления принуждать синтаксический обсахаривания.

Намерение состоит в том, что могут быть введены другие экземпляры Cast, чтобы расширить диапазон преобразований, хотя я этого не исследовал. Как вы говорите, совпадающие экземпляры кажутся необходимыми.