Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Are path-dependent types type projections?

I'm reading Scala in depth now. Here is an excerpt from the book:

All path-dependent types are type projections. A path-dependent type foo.Bar is rewritten as foo.type#Bar by the compiler...

In Scala, all type references can be written as projects against named entities. The type scala.String is shorthand for scala.type#String where the name scala refers to the package scala and the type String is defined by the String class on the scala package.

Obviously, there isn't scala.String class, but I failed to reproduce this with Null.

scala> type N = scala.type#Null
<console>:7: error: type mismatch;
 found   : type
 required: AnyRef
       type N = scala.type#Null

So, my questions are as follows. Are path-dependent types type projections? Is it just inner compiler representation or can be expressed in scala code?

like image 470
4e6 Avatar asked May 11 '12 15:05

4e6


People also ask

What is type Projection?

A type projection is a type that has been limited in certain ways in order to gain variance characteristics. Imagine a three-dimensional object that you shine a flashlight onto. Behind that object on the wall is a two-dimensional projection of that object - a shadow.

What is projection in Scala?

For a very long time, Scala has had a featured named type projection, which lets one refer to a type member defined in an existing type (i.e., to “project it” or “pick it out”). The syntax is T#A , where T is some type that is know to contain a type member named A .

Does Scala have dependent types?

Scala already has dependent methods, i.e. methods where the result type refers to some of the parameters of the method.


1 Answers

Here's a quick REPL session which confirms what Josh wrote,

scala> class Foo { type T = String }
defined class Foo

scala> val foo = new Foo
foo: Foo = Foo@10babe8

scala> implicitly[foo.type#T =:= foo.T]
res0: =:=[foo.T,foo.T] = <function1>

The problem with your scala.type#Null example is that the prefix scala is a package prefix rather than being a stable identifier of a value. Arguably it ought to be the latter, but unfortunately it's not ... that's a lingering mismatch between the semantics of Scala packages and Scala objects (in the sense of modules).

like image 151
Miles Sabin Avatar answered Sep 28 '22 07:09

Miles Sabin