Replacing projection types

[bblfish]

Projection types were removed from Dotty. Some libraries like banana-rdf relied on this very heavily to make elegant user libraries.

It looks like some subset of it may not be problematic, as per issue 14: Make type projections safe instead of dropping them.
So we are now in a grey zone where it is not clear whether a safe subset is going to be brought back, or if there is a better way to get the same effect. So I think we should really have this as a whole discussion topic in itself. Questions to look at:

• what are the ways to replace projection types, for the various use cases where they have been applied to?
• how can Scala3 best interact with scala 2.13 libs that use projection types?

[bblfish]

Here is a simple interaction problem I have come across regarding inherited projection types.

Banana RDF projection types are defined in the RDF trait which starts like this:

trait RDF {
  // types related to the RDF datamodel
  type Graph
  type Triple
  type Node
  type URI <: Node
  type BNode <: Node
  type Literal <: Node

This trait is implemented for a number of RDF frameworks such as the Apache Jena project (started at HP in the early 2000s). The Jena trait for example just specifies how those types should be translated for the Jena class hierarchy.

It looks like implicit transformations which work in Java 2.13 don't work that well anymore when using the library in Scala 3.0.

We use this for example for our DSL, to allow people to write RDF in a Scala friendly way:

   val g: PointedGraph[Rdf] = (
      bnode("betehess")
      -- foaf.name ->- "Alexandre".lang("fr")
      -- foaf.knows ->- (
        URI("http://bblfish.net/#hjs")
        -- foaf.name ->- "Henry Story"
        -- foaf.currentProject ->- URI("http://webid.info/")
      )
    )

This requires Scala to convert a URI into a PointedGraph which relies on the ToPG Binder. In particular we have

 implicit def ToNodeToPG[Rdf <: RDF, T](implicit ops: RDFOps[Rdf], to: ToNode[Rdf, T]): ToPG[Rdf,T] = new ToPG[Rdf, T] {
    def toPG(t: T): PointedGraph[Rdf] = PointedGraph(to.toNode(t))
  }

That seems to work fine on Scala 2.13. But for Scala 3 I seem to need to add:

implicit def URIToNode: ToNode[Rdf,Rdf#URI] = new ToNode[Rdf, Rdf#URI] {
		def toNode(t: Rdf#URI): Rdf#Node = t
	}

Is that a bug in Scala3, do I need to write these implicit transformations out explicitly for the inheritance hierarchy, or is there a better way to get this done?

[julienrf]

Hello @bblfish

We use this for example for our DSL, to allow people to write RDF in a Scala friendly way:

Could you please elaborate on why you need to use type projections to provide this user-facing DSL?

[bblfish]

The main reason for type projections is that it allows one to write code that does not depend on the specific RDF library used. It is then possible to change implementation by changing one line of code.

All our tests are written this way. For example GraphUnionTest

abstract class GraphUnionTest[Rdf <: RDF](implicit ops: RDFOps[Rdf]) extends WordSpec with Matchers {
...
"union of Nil must return an empty graph" in {    
     val result: Rdf#Graph = union(Nil)    isomorphism(result, emptyGraph) shouldEqual true  }
...

We can then implement these tests by setting the RDF to be Apache's Jena for example as in JenaTest.scala

class JenaGraphUnionTest extends GraphUnionTest[Jena]

or to IBM's RDF4J.scala.

In fact you can write your whole codebase generically and switch between implementations by changing a couple of lines of code. This is very useful as it allows one to write code for the client in ScalaJS and on the server, and also try out how well different inferencing engines are working without needing to rewrite one's whole codebase. You could also have your code use both and exchange graphs between the two implementations if needed.

[julienrf]

Would it be possible to write something like this instead?

trait GraphUnionTest {
  val rdf: RDF
  implicit def ops: RDFOps[rdf.type]
  "union of Nil must …" in {
    val result: rdf.Graph = ...
  }
}

// and
class JenaGraphUnionTest extends GraphUnionTest {
  lazy val rdf: Jena = ...
  implicit lazy val ops = ...
}

[bblfish]

I started looking at using dependent types 9 months ago in banana-play and opened a "feature request" 133. It did not seem that easy to get it written out nicely at the time.(But that was after a few years of not having programmed in Scala.)

Now I have 6 months experience with Scala3 so it will soon be time to look at it again. But it will be a very big change with over 500 errors to be fixed. So I just thought I'd see with others what their experience was.

[bblfish]

It could be that Opaque types are useful.
scala/docs.scala-lang#2158

[bblfish]

It looks like Match Types are the answer to my problem. See #13416 and test code.

[bblfish]

Note: with the latest Scala3 it is possible now to mix opaque and inline.

[bblfish]

Using Opaque types and pattern matching can be done it seems, see https://contributors.scala-lang.org/t/algebras-of-opaque-types-and-pattern-matching/5245

[bblfish]

@Sciss described how he went about answering his problem in lampepfl/dotty-feature-request issue 133.

[bblfish]

Match types do seem to work. See banana-play's RDF.scala.

I am able to write code like

class PG[Rdf <: RDFObj](val pointer: Node[Rdf], val graph: Graph[Rdf])

object PG:
   def apply[Rdf <: RDFObj](node: Node[Rdf])(using ops: RDFOps[Rdf]): PG[Rdf] = 
        new PG[Rdf](node, ops.empty)