除了语法上的便利之外，单例类型，路径依赖类型和隐式值的组合意味着Scala令人惊讶地对依赖类型提供了良好的支持，正如我尝试在shapeless中演示的那样。
Scala对依赖类型的内在支持是通过路径依赖类型。这些允许类型依赖于像这样通过对象（即值）图的选择器路径，
scala> class Foo { class Bar }
defined class Foo
scala> val foo1 = new Foo
foo1: Foo = Foo@24bc0658
scala> val foo2 = new Foo
foo2: Foo = Foo@6f7f757
scala> implicitly[foo1.Bar =:= foo1.Bar] // OK: equal types
res0: =:=[foo1.Bar,foo1.Bar] = <function1>
scala> implicitly[foo1.Bar =:= foo2.Bar] // Not OK: unequal types
<console>:11: error: Cannot prove that foo1.Bar =:= foo2.Bar.
implicitly[foo1.Bar =:= foo2.Bar]
在我看来，以上内容足以回答“ Scala是依赖类型的语言吗？”的问题。肯定的是：很明显，这里我们有一些类型，这些类型的区别在于作为前缀的值。
但是，人们常常反对Scala不是“完全”依赖类型的语言，因为它没有像Agda或Coq或Idris那样的内在求和和乘积类型。我认为这在某种程度上反映了形式对基础的固定，但我将尝试表明Scala与通常认可的其他语言相比更加接近其他语言。
尽管有术语，但依存和类型（也称为Sigma类型）只是一对值，其中第二个值的类型取决于第一个值。这在Scala中可以直接表示，
scala> trait Sigma {
| val foo: Foo
| val bar: foo.Bar
| }
defined trait Sigma
scala> val sigma = new Sigma {
| val foo = foo1
| val bar = new foo.Bar
| }
sigma: java.lang.Object with Sigma{val bar: this.foo.Bar} = $anon$1@e3fabd8
实际上，这是依赖方法类型编码的关键部分，需要从 2.10之前（或更早通过实验性的-Ydependent-method类型Scala编译器选项）摆脱Scala中的“ Boomy of Doom”。
从属产品类型（又名Pi类型）本质上是从值到类型的函数。它们是表示静态大小的向量以及依赖类型的编程语言的其他子代子的表示的关键。我们可以使用路径相关类型，单例类型和隐式参数的组合在Scala中对Pi类型进行编码。首先，我们定义一个特征，该特征将表示从类型T的值到类型U的函数，
scala> trait Pi[T] { type U }
defined trait Pi
然后我们可以定义使用这种类型的多态方法，
scala> def depList[T](t: T)(implicit pi: Pi[T]): List[pi.U] = Nil
depList: [T](t: T)(implicit pi: Pi[T])List[pi.U]
（请注意pi.U在结果类型中使用路径相关类型List[pi.U]）。给定类型T的值，此函数将返回对应于该特定T值的（n个空）该类型的值的列表。
现在，让我们为要保留的功能关系定义一些合适的值和隐式见证，
scala> object Foo
defined module Foo
scala> object Bar
defined module Bar
scala> implicit val fooInt = new Pi[Foo.type] { type U = Int }
fooInt: java.lang.Object with Pi[Foo.type]{type U = Int} = $anon$1@60681a11
scala> implicit val barString = new Pi[Bar.type] { type U = String }
barString: java.lang.Object with Pi[Bar.type]{type U = String} = $anon$1@187602ae
现在这是我们使用Pi类型的功能，
scala> depList(Foo)
res2: List[fooInt.U] = List()
scala> depList(Bar)
res3: List[barString.U] = List()
scala> implicitly[res2.type <:< List[Int]]
res4: <:<[res2.type,List[Int]] = <function1>
scala> implicitly[res2.type <:< List[String]]
<console>:19: error: Cannot prove that res2.type <:< List[String].
implicitly[res2.type <:< List[String]]
^
scala> implicitly[res3.type <:< List[String]]
res6: <:<[res3.type,List[String]] = <function1>
scala> implicitly[res3.type <:< List[Int]]
<console>:19: error: Cannot prove that res3.type <:< List[Int].
implicitly[res3.type <:< List[Int]]
（请注意，这里我们使用Scala的<:<subtype-witnessing运算符，而不是=:=因为res2.type和res3.type是单例类型，因此比我们在RHS上验证的类型更精确）。
但是，实际上，在Scala中，我们不会先编码Sigma和Pi类型，然后再像在Agda或Idris中那样从那里开始。相反，我们将直接使用依赖于路径的类型，单例类型和隐式。您可以找到无数变形的无数示例：大小类型，可扩展记录，全面的HList，报废样板，通用Zipper等。
我只能看到的唯一反对意见是，在以上对Pi类型的编码中，我们要求依赖值的单例类型是可表示的。不幸的是，在Scala中，这仅适用于引用类型的值，而不适用于非引用类型的值（例如，Int）。这是一种耻辱，而不是固有的困难：Scala的类型检查代表内部的单类型的非参考值的，而且已经出现了夫妇的实验中让他们直接表达。在实践中，我们可以使用自然数的相当标准的类型级别编码来解决该问题。
无论如何，我认为这种轻微的域限制不能用作反对Scala作为依赖类型语言的地位的异议。如果是这样，那么对于依存ML（仅允许对自然数的依存关系）可以说是相同的，这是一个奇怪的结论。