Proposal to Add Implied Instances to the Language

Scala Improvement Process
61

Personal opinion: of the proposals so far, I strongly prefer the instance ... of syntax. It reads well and naturally, and gets the point across.

To the similarity with the OO concept of “instance”: this is why I like this option so much. When I teach typeclasses – typically to a crowd that are at least somewhat familiar with OO – I introduce them as the FP equivalent of an interface. And the next step is to teach “typeclass instances”, which I phrase that way precisely because they are closely cognate to the notion of instantiating an interface. So I actually support this choice of wording because, rather than being ambiguous, it supports folks’ learning how to use typeclasses, and helps make them more familiar and less scary.

On the subject of _: I agree with @soronpo and @julienrf above. IMO, not just allowing but requiring the use of _ when declaring an anonymous instance is consistent with the way names work elsewhere in the language. When I’m declaring a parameter list, and want to say “I have this unnamed parameter”, I don’t omit the name, I replace it with _. I generally teach _ as being pronounced “whatever”, and this would be entirely in line with that.

I agree that the symbol gets overused, and could stand to be replaced in several places – in particular, I think the language would be improved if:

import com.mypackage._

was replaced with:

import com.mypackage.*

That would be both more in line with other languages (in fact, I still reflexively pronounce it as “star” in this context), and would reduce the mental overhead of _. OTOH, this usage of _ would still be appropriate:

import com.mypackage.{Foo => _, *}

That is intentionally “anonymizing” that name from the package, in line with the general usage.

In short: we shouldn’t be afraid of making use of _. We should, however, be striving to regularize that usage, and I think using it here is totally in line with that goal.

6 Likes
62

Just because we have many uses of _ doesn’t mean we shouldn’t use it for what it’s already used and great for - omitting identifiers. In fact that makes the language more predictable and regular.

5 Likes
63

I completely agree and want to add that I think there’s a general notion to keep in mind: language keywords should be uniquely Googlable. That is, it is desirable for a search for “Scala for” to turn up reference material about one single feature, not two separate ones that happen to use the same keyword. That this is not the case for implicit makes it take way longer to learn the difference between typeclassess (great), extension methods (good when used right), and implicit conversions (scary).

1 Like
64

Since instance ... of ... given received some support and no objections so far, I am thinking of changing the proposal officially to go with that syntax.

So, now is that last chance to speak up for implied ... for. If I see no voices in favor, it wil be gone.

65

FWIW, I feel that instance imports are a bit confusing to someone encountering them for the first time

import A._
import instance A._

A possible assumption could be that the instance A._ just brings all the vals into scope.

Otherwise, while instance conjures up haskell to those familiar, it has no effect on those who don’t in which case it is as good as the other propositions, IMHO. While I do like it, perhaps just the import syntax could be modified in some way maybe import given instances A._

[For context, I think that I am probably the most “ordinary” of scala programmers replying on this thread… a java programmer self converted to scala, that had to battle the steep learning curve]

66

Let me say that I am strongly against instance. I cannot bring myself to think how I’d teach to anyone that Scala has object Foo and instance Foo, but they don’t mean nearly the same thing.

The argument that we can consistently use “implicit instance” in the documentation to fix the above is flawed: there is a huge amount of documentation, books, etc. (and not just on Scala) that use the word “instance” to refer to normal instances, and all that doc is going to be destroyed by the introduction of a keyword instance that doesn’t mean what the word “instance” means at all.

Moreover, if the way to fix it is to call it an “implicit instance” in the doc, that only reinforces my opinion that the right keyword is and remain implicit.

9 Likes
67

Let me say that I am strongly against instance . I cannot bring myself to think how I’d teach to anyone that Scala has object Foo and instance Foo , but they don’t mean nearly the same thing.

But are their meanings really so far apart? After all, a monomorphic instance creates an implicit object. To be sure, instance is more varied, since it has other forms as well.

68

But instance ... of ... given ... will compile to a def so how’s that an instance? def is a factory of instances.

69

Maybe we could then use “implicit object” instead of “implicit instance” to refer to them in the documentation, and at that point why not write implicit object in the code too for consistency ? :grin:

2 Likes
70

Maybe we could then use “implicit object” instead of “implicit instance” to refer to them in the documentation, and at that point why not write implicit object in the code too for consistency ? :grin:

Because it does not translate to parameterized or conditional instances. That’s the whole point of the instance construct: One construct that handles all possible forms of implicit instances.

Here’s another argument why this is important. implicit as a modifier is not as orthogonal as it looks. For instance, I can’t put an implicit on just any def. It must be a def that is either parameterless or that takes only implicit parameters (or that takes a single non-implicit which makes it a conversion, but that will go away). So that’s a feature interaction and a design smell. It means we require users to get the mechanics right and then they can use a certain modifier to make the thing implicit. I want them to express their intent and leave it to the compiler to implement the mechanics.

2 Likes
71

Right, but then we come back to @sjrd’s point that this is using “instance” in a completely different way than we’ve used it so far in Scala and every other OO language. Everyone familiar with one of these languages will want to know how instance in Scala relates to the well-known use of the term, and I guess we’ll have to say: “An implicit instance in Scala is either an instance of a class, or a class, or a method.”, I doubt people will feel enlightened by that explanation.

True, implicit def indeed has peculiar rules, but I think that’s mostly a concern when writing it (where the compiler/IDE is there to guide you), when reading existing code, the fact that these are just methods make them look more familiar. And I expect that most people almost never write implicit defs, but very often have to read them when they start using a new library for example.

If we create a new syntax that just replaces implicit def then it will look alien to people who don’t use this syntactic construct regularly, in the same way that C++ templates look alien to a lot of “regular” C++ programmers, and I think the end result will be that these definitions will seem even more magical/scary to people.

72

Getting back on topic: Do you have a preference between the implied ... for and instance ... of versions? Or maybe one of the alternatives I proposed (i.e. implicit as a noun, or evidence)?

73

People with Java (or other OO languages) will have a hard time understanding instance. I prefer either implied or implicit.

Why do we have to use the of or for preposition there (for is especially confusing since it has another well-established usage in the language)? To express a term is of a certain type, Scala uses : for that – this is the standard usage of least surprise. I’d prefer either

implied ev: Typeclass[A]
implied ev[A] given (A: Eq[A]): Typeclass[F[A]]

or

implicit ev: Typeclass[A]
implicit ev[A] given (A: Eq[A]): Typeclass[F[A]]
3 Likes
74

I think object made sense to me when I first saw it as I derived the meaning from how I was taught OOP: “a class is a blueprint to instantiate objects”. If knowing that I take a look at object: well, it is not a class so I can’t use it as a blueprint to instantiate new objects, but it is already an (instance of an) object, therefore a singleton.

With “instance…of” I don’t see an understanding that we are talking about an implicit instance arising in a similarly natural way.

That being said, I don’t think it is a bad proposal, as far as this SIP goes. I think most of what has been suggested works, except of evidence and witness being too unfamiliar to most (including me, although I personally wouldn’t mind too much).

I do think though that instance in

instance ... of

is more confusing than the for in

implied(or a suitable adjective) ... for

and as others said, I too don’t see it working too well with the implied imports SIP (not sure if that concern has been addressed, it is possible I missed that.

(also, thumb up for moving given to the end of the expression, whatever the rest of it will end up being)

75

The main reason why : is problematic is because of what can come after it.

In general, when I write

val x: T = ...
def x: T = ...

then T is an arbitrary type. But when I write

class C extends TC
implied x for TC

then TC is a class constructor. There are some important differences between the two:

  • Class constructors must produce class types
  • Class constructors can take arguments
  • Class constructors cannot be refined types.

That last difference is the most important. When I see:

   extends T { ... }
   of T { ... }
   for T { ... }

then the ... in the braces is a list of definitions. But when I see:

    : T { ... }

then the ... in the braces is a list of refinements of type T. That’s something completely different. In my opinion, we should take care not to dilute the visual cues that distinguish the two.

2 Likes
76

Then we can do:

implicit ev: Typeclass[A] = {  ...  }

or:

implicit ev: Typeclass[A] = new {  ...  }

Syntax is then almost as close to current one as it can be. Just replace implicit def, implicit val, implicit lazy val, etc with implicit alone. Then use new given syntax for implicit parameters. Implicit conversions are impossible to define using this syntax so it’s probably OK.

2 Likes
77

@tarsa

That’s again mechanism instead of intent to my eyes.

78

How about **implicit yield**?

79

Yes. It’s almost as low-level as current way of defining typeclasses instances, while simultaneously is not significantly longer than implied ev of Typeclass[A] { ... }. It’s somewhat higher level because it automatically chooses between lazy val/ object and def.

It has some upsides:

  • it looks familiar to exising Scala programmers, so less impression that Scala 3 is a different language than Scala 2
  • variant implicit ev: Typeclass[A] = new { ... } is generally as flexible as current syntax, so migration would be easy (mechanical) and very localized
  • most importantly - it still makes defining implicit conversions impossible
80

OK now I understand your justification. There are indeed differences between : and extends.

So in this case I think that we can reuse extends (again, least surprise for existing Scala programmers) when we create a concrete implied instance:

implied ListEq[A] given (A: Eq[A]) extends Eq[List[A]] { 
  // definitions
}

and use : for abstract implied instances:

trait A {
  implied monoid: Monoid[A] 
}

I think that

implied <Instance> given <Evidences> extends <Type>

works pretty well in English.