Каковы некоторые убедительные варианты использования для зависимых типов методов?

Более или менее любое использование типов элементов (т.е. вложенных) может вызвать необходимость в зависимых типах методов. В частности, я утверждаю, что без зависимых типов методов классический шаблон торта ближе к анти-шаблону.

Так в чем проблема? Вложенные типы в Scala зависят от их вмещающего экземпляра. Следовательно, при отсутствии зависимых типов методов попытки использовать их вне этого экземпляра могут быть сложными. Это может превратить проекты, которые изначально кажутся элегантными и привлекательными в чудовищах, которые кошмарно жестки и сложны для рефакторинга.

Я проиллюстрирую это упражнение, которое я даю во время моего расширенного курса Scala,

trait ResourceManager {
  type Resource <: BasicResource
  trait BasicResource {
    def hash : String
    def duplicates(r : Resource) : Boolean
  }
  def create : Resource

  // Test methods: exercise is to move them outside ResourceManager
  def testHash(r : Resource) = assert(r.hash == "9e47088d")  
  def testDuplicates(r : Resource) = assert(r.duplicates(r))
}

trait FileManager extends ResourceManager {
  type Resource <: File
  trait File extends BasicResource {
    def local : Boolean
  }
  override def create : Resource
}

class NetworkFileManager extends FileManager {
  type Resource = RemoteFile
  class RemoteFile extends File {
    def local = false
    def hash = "9e47088d"
    def duplicates(r : Resource) = (local == r.local) && (hash == r.hash)
  }
  override def create : Resource = new RemoteFile
}

Это пример классического шаблона торта: у нас есть семейство абстракций, которые постепенно уточняются через иерархию (ResourceManager/Resource уточняются на FileManager/File, которые в свою очередь уточняются на NetworkFileManager/RemoteFile). Это пример игрушек, но шаблон реальный: он использовался во всем компиляторе Scala и широко использовался в плагине Scala Eclipse.

Здесь пример использования абстракции,

val nfm = new NetworkFileManager
val rf : nfm.Resource = nfm.create
nfm.testHash(rf)
nfm.testDuplicates(rf)

Обратите внимание, что зависимость пути означает, что компилятор гарантирует, что методы testHash и testDuplicates на NetworkFileManager могут быть вызваны только с соответствующими ему аргументами, т.е. он принадлежит RemoteFiles, и ничего больше.

Это бесспорно желательное свойство, но предположим, что мы хотим, чтобы переместить этот тестовый код на другой исходный файл? С зависимыми типами методов тривиально легко переопределить эти методы вне иерархии ResourceManager,

def testHash4(rm : ResourceManager)(r : rm.Resource) = 
  assert(r.hash == "9e47088d")

def testDuplicates4(rm : ResourceManager)(r : rm.Resource) = 
  assert(r.duplicates(r))

Обратите внимание на использование зависимых типов методов здесь: тип второго аргумента (rm.Resource) зависит от значения первого аргумента (rm).

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

Попробуйте сами...

// Reimplement the testHash and testDuplicates methods outside
// the ResourceManager hierarchy without using dependent method types
def testHash        // TODO ... 
def testDuplicates  // TODO ...

testHash(rf)
testDuplicates(rf)

После непродолжительного сражения с ним вы, вероятно, узнаете, почему я (или, может быть, это Дэвид Макивер, мы не можем вспомнить, кто из нас придумал этот термин) назовите это Хлебопером Судьбы.

Изменить: Консенсус в том, что Bakery of Doom была монетой Дэвида Макивера...

Для бонуса: форма зависимых типов Scala вообще (и зависимых типов методов как часть этого) была вдохновлена ​​языком программирования Beta... они естественным образом возникают из согласованной семантики вложенности Бета. Я не знаю ни одного другого, даже слабого основного языка программирования, который имеет зависимые типы в этой форме. Языки, такие как Coq, Cayenne, Epigram и Agda, имеют различную форму зависимой типизации, которая в некотором роде более общая, но которая существенно отличается, будучи частью систем типов, которые, в отличие от Scala, не имеют подтипов.