Abstract given seems useless

[rjolly]

Abstract given were introduced in #10538 . But these seem useless, as one can always define an abstract field and use a given alias:

def ord: Ord[T]
given Ord[T] = ord

Would it be possible to drop this feature, as it forces us to add an uncanny with to givens even when no structural part is needed lampepfl/dotty-feature-requests#156

[odersky]

I let @nicolasstucki and @julienrf respond. They have been arguing strongly for abstract givens.

[julienrf]

I find abstract givens useful, indeed. Abstract definitions are a common means of abstraction (abstract methods and abstract type members). We can observe that in Scala 2 abstract implicit definitions are used (e.g. in cats, endpoints4s, akka, and maybe at other places that I’m not aware of).

From a more fundamental perspective, there is a correspondence between parameters and abstract members. Both are means of abstractions, and you can refactor from one form to the other:

trait WithMembers {
  type A
  val foo: A
}

class WithParameters[A](val foo: A)

However, if we remove abstract givens, this will make it impossible to refactor this:

class Foo[A](using SemiGroup[A])

into that:

trait Foo {
  type A
  given SemiGroup[A]
}

You mentioned a workaround, which in my opinion is not only verbose, but very low-level and “mechanism-oriented” (as opposed to “intent-oriented”). I like how abstract givens removed half of the lines of this part of the compiler.

[julienrf]

That being said, if abstract givens are the only reason why we need the with connector, I agree that it’s an important drawback. Is it true that we could remove with if we didn’t support abstract givens?

[bmeesters]

I agree with Julien. Also, even if I am not very fond of the empty with {}, leaving it out is IMO pretty confusing:

given [T : Ord]: ConcreteFoo[T]

looks too much like an abstract def in my opinion, so reusing it for a slightly shorter syntax is not worth it IMO. Maybe we can find another solution to get rid of the with {}?

[rjolly]

Is it true that we could remove with if we didn’t support abstract givens?

We could define a structural instance like so without risk of confusion:

given [T : Ord]: Foo[T]:
  ...

I like how abstract givens removed half of the lines of this part of the compiler

Only you (or Nicolas) can tell if there is a better way to express this. If not, then perhaps we need it after all. But in that case, maybe we could bring back a keyword such as as, or better extends, to distinguish empty structural part from abstract given:

given [T : Ord] extends ConcreteFoo[T]

Edit : in this case, the problem is that given alias (and abstract given) on the one hand, and structural instances on the other hand, now are syntactically separate domains, and it would be difficult to implement an abstract given with a structural instance.

[rjolly]

Maybe we can find another solution to get rid of the with {}

given [T : Ord]: ConcreteFoo[T] new

[rjolly]

After reflection, I still think the workaround is better, for separation of concerns. Abstraction is a thing, and context abstraction is something else. Having both conflated in the same construct is problematic. Especially since givens are meant to disentangle implicits from other concerns (among which is abstract).

Happy new year.

[odersky]

I believe one aspect is that the syntax

given table: Table

for a concrete given is objectionable since it looks like an abstract given. That was a common complaint when : was still as.
It's true that

given table: Table with {}

looks cryptic, but at least it's not misleading. A better way to write this is with an alias, even if it is slightly longer:

given table: Table = Table()

So no matter what we do, we probably should either outlaw

given table: Table

outright, or make it an abstract given. I was fielding the same "separation of concerns" argument as @rjolly to defend why there should be no abstract givens. On the other hand, since it is useful, easy to spec and implement, and the natural syntax is already available, why not?

[rjolly]

Then perhaps we should disable abstract and re-introduce extends (for non-alias):

given table extends Table

For me, the main problem is that this mandates braces, right in the middle of a whole braceless effort:

given table: Table with {}

Edit: and it look abstract too, since there is no equal sign.

[odersky]

And for anonymous? given extends is pretty yucky!

The root issue is that for givens x: is an optional label. Everything has to work with and without that label, and every discussion should include that aspect from the start.

[odersky]

I have the impression that the whole discussion here and the contributors thread is essentially trying to walk back to what we had before with as but with different keywords. I firmly believe that as was already the best choice for a keyword, but that ultimately : is better than any keyword even if it does lead to the irregularity with with.

[LPTK]

@odersky

given extends is pretty yucky!

For clarity, here is what it ends up looking like:

given extends Ord[Int]:
   def compare(x: Int, y: Int) = ...

given [T](using Ord[T]) extends Ord[List[T]]:
  def compare(xs: List[T], ys: List[T]): Int = ...

I think the reason given extends feels strange at first is that we normally read "given" not as a noun, but as a preposition. In English, we often see the forms "given <some context>, then <some conclusion>" or "given that <some fact>".

However, IIRC you have argued that Scala declarations normally start with nouns (class, object, trait, def, package, etc.), and that "given" should therefore be understood in this capacity – this was actually a hard criterion used in the choice of an appropriate keyword. In a given declaration, we are defining a given (instance).

Under that interpretation, given extends T is not jarring anymore, as it's understood as "this given instance extends T", just like one reads object ... extends T as "this object instance extends T". In fact, this forms pushes the reader to treat the word "given" in its intended grammatical role, making it less of an exception in the language.

// the following
given Obj extends Ord[Int] { ... }

// is conceptually similar to the following
object Obj extends Ord[Int] { ... }

// and if we had anonymous objects, we'd write
object extends Ord[Int] { ... }

// just like we would now write
given extends Ord[Int] { ... }

So I think one will actually get used to this form quickly.

Since it happens to solve many problems at once and has been proposed over and over by the community, why not give it a serious try?

[odersky]

@LPTK I don't understand how this not a clear step backwards from what we had with as?