What is the scala proof parameter

Question

I tried to find a reliable definition of what is an exponential parameter, to no avail, to solve the question "could not find an implicit value for the argument parameter type ...". Can you give a very good explanation of what exactly is the evidence parameter?

Answer 1

I will try to post my own answer, improving it later. We start with a motivational scenario, but you can go to TL; DR below, and then return here as needed.

In one scenario, the parameters of evidence can be considered as a means of enriching the class with some behavior (method / s) outside its initial definition.

Soft redistribution of a large position in Cake Solutions :

In case you have not yet intuitively written such code before, here is a code that demonstrates the used parameters of the proof.

object EvidenceExample { // class with no methods case class Bar(value: String) // a trait the class Bar had not implemented trait WithFoo[A] { def foo(x: A): String } // object that attaches an implementation of the trait for Bar - for methods // willing to play along with this kind of trait attachment - see immediately below implicit object MakeItFoo extends WithFoo[Bar] { def foo(x: Bar) = x.value } // method willing to recognize anything as having trait WithFoo, // as long as it has evidence that it does - the evidence being the previous object def callFoo[A](thing: A)(implicit evidence: WithFoo[A]) = evidence.foo(thing) callFoo(Bar("hi")) // and it works } 

You can read this code from the bottom up to understand that the Bar class has been enriched beyond its original definition. However, only the functions that play along with the testimony ceremony can see it enriched.

There is very little magic in this template - although it is a unique language function - the wrapper object associates the attribute with Bar , and callFoo relies on this association.

We could even write the same template without implications, but then the last line that calls the method will require an additional parameter - the cost-effectiveness of using implicit or not - is completely up to you.

You can use sugar or sugar as you wish, for example, with a slight improvement in syntax:

(only the last def is changed here and the comments are deleted now)

 object EquivalentEvidenceExample { case class Bar(value: String) // a trait the class Bar had not implemented trait WithFoo[A] { def foo(x: A): String } implicit object MakeItFoo extends WithFoo[Bar] { def foo(x: Bar) = x.value } def callFoo[A:WithFoo](thing: A) = implicitly[WithFoo[A]].foo(thing) // lightly sugared syntax, frankly only more confusing callFoo(Bar("hi")) } 

And nothing requires you to name anything with a string of evidence . The compiler simply knows that this is a proof parameter, since it is used in all these equivalent cases.

More generally or etymologically, borrowing from another answer , a proof parameter is one that “proves” a particular property of the type, and this requires a compiler where the method signature expresses such a requirement (in another answer there is no data presented for the Any type, which is <:< Foo , as required by the signature of the method, therefore, this is a case of lack of evidence).

Failure to have an evidence object accessible as implicit will result in the well-known could not find implicit value for evidence parameter of type ... because the compiler knows that this is part of the evidence template and not just the missing implicit (how important this is for you),

TL; DR:

In short, the proof parameter for some class S is a parameter of type T[S] (so, a parameter that is a class) that defines one or more things about S - thus “proving” something about S - what S does acceptable for extended use by the caller, beyond the original definition of S An exact form, such as T[S] , should be given in my borrowed examples above, an implicit object MakeItFoo .

Answer 2

The language specification uses the term “proof” in §7.4 “Contextual frames” and “Boundary viewing” :

A type parameter of a method or class without attributes may also have one or more context boundaries A : T In this case, the type parameter can be an instance of any type S , for which there is evidence at the instantiation point that S satisfies the estimate T Such evidence consists of an implicit value of type T[S] .

With this syntactic sugar, you get synthetic parameters, which the spec calls “evidence parameters”. (Note that this also applies to <% view limits that are now out of date).

Since often explicitly written implicit parameters are also called evidence , I believe that this is indeed the case to invoke some implicit parameter as “evidence” if it is a witness to a particular type property. Take, for example, <:< [A, B] , which indicates that A is a subtype of B :

 trait Foo trait Bar[A] { def baz(implicit evidence: A <:< Foo): Unit } 

Then, if you try this:

 trait Test { def bar: Bar[Any] bar.baz } 

This fails with a compilation error:

 <console>:58: error: Cannot prove that Any <:< Foo. bar.baz ^ 

The exact wording can be indicated using the implicitNotFound annotation . Without a specific code example, it is unclear what generates "could not find an implicit value for the type proof parameter ...".

Here is an example of a custom post:

 @annotation.implicitNotFound(msg = "Oh noes! No type class for ${A}") trait MyTypeClass[A] trait Bar[A] { def baz(implicit evidence: MyTypeClass[A]): Unit } 

Then:

 trait Test { def bar: Bar[Any] bar.baz } 

Failed to create custom message:

 <console>:58: error: Oh noes! No type class for Any bar.baz ^