構文上の便宜はさておき、シングルトン型、パス依存型、および暗黙値の組み合わせは、私が無形で実証しようとしたように、Scalaが依存型入力に対して驚くほど優れたサポートを提供することを意味します。
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に組み込まれている依存型のsumおよびproduct型を持たないため、「完全に」依存型の言語ではないことがよくあります。これはある程度、ファンダメンタルズよりも形式上の固執を反映していると思いますが、それでも、Scalaが一般的に認められているよりも他の言語に非常に近いことを確認します。
用語に関係なく、依存合計タイプ（シグマタイプとも呼ばれます）は、2番目の値のタイプが最初の値に依存する値のペアです。これは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-methodsタイプのScalaコンパイラーオプションを介して以前のバージョン）のScalaの'Bakery 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値に対応するタイプの値の（空の）リストを返します。
次に、保持したい機能的関係に適した値と暗黙の証人をいくつか定義します。
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の使用していること<:<ではなく、サブタイプ目撃オペレータを=:=理由res2.typeとres3.typeシングルトンの種類と我々はRHSに検証されているタイプよりもので、より正確です）。
ただし実際には、ScalaではAgdaやIdrisの場合のように、Sigma型とPi型をエンコードし、そこから処理を開始することはしません。代わりに、パス依存型、シングルトン型、および暗黙を直接使用します。サイズなしの型、拡張可能なレコード、包括的なHList、定型句のスクラップ、汎用のZipperなど、これが無形でどのように機能するかを示す多数の例を見つけることができます。
私が見ることができる唯一の異論は、上記のPi型のエンコーディングでは、依存する値のシングルトン型を表現可能にする必要があるということです。残念ながらScalaでは、これは参照型の値に対してのみ可能であり、非参照型（たとえば、Int）の値に対しては不可能です。これは残念ですが、本質的な問題ではありません。Scalaの型チェッカーは、非参照値のシングルトン型を内部的に表し、それらを直接表現できるようにするためにいくつかの実験が行われています。実際には、自然数のかなり標準的なタイプレベルのエンコーディングで問題を回避できます。
いずれにせよ、このわずかなドメイン制限が、依存型付け言語としてのScalaのステータスに対する異議として使用できるとは思いません。そうである場合、同じことがDependent ML（自然数の値への依存のみを許可する）についても言え、これは奇妙な結論になります。