Proposal To Revise Implicit Parameters

[mdedetrich]

Slightly misread what you were saying, in which case I agree with you (my point is that I think the new proposal is actually scarier than what we currently have)

[Tom_Poczos]

@mdedetrich

Current implicits are basically parameter passing (with some quirks) which Java people understand very well. Then when I explain to them how the implicit part works, I just draw comparisons with Guice

I like the recent changes concerned with contextual abstractions. I think what you are saying is right, on the other hand though, when the ease of understanding of the concept of implicits is considered together with also having to understand the patterns it is used in, the proposed changes work better. The “expressing intent vs expressing mechanism” argument works for me.

It might turn off slightly more people in the earliest stages of learning than implicits. But to me it seems like a large subset of those would end up not liking scala with implicits either, and I’m yet to see a single person from that group to change their mind. Often the issue is that scala is just not in the part of the typesystem/PL landscape that they are prepared to leave anyway.

The proposed changes might serve better than implicits those newcomers who were more likely to stay with the language just a little bit longer in the first place, and it is this latter group that has the potential to impact adoption.

[tarsa]

@odersky

Then the following calls are all valid (and normalize to the last one)

f("abc")
(f given global)("abc")
f("abc") given ctx
(f given global)("abc") given ctx

@odersky

    foo(given arg)

Syntactically, what is this given ? It has no correspondence to anything else in the language, just like (implicit ...) for parameters is a highly irregular case. By contrast,

    foo given arg

is syntactically an infix operator. So we know how to parse this. It fits with the rest of the language. It’s just not what people are used to now , but that should not be the deciding concern.

If given is an infix operator then why can’t we turn it into a dotted notation? We as Scala programmers know that generally object operator argument can be rewritten as object.operator(argument). If that applies to given as well then normalization could look like this:

f("abc")
f.given(global)("abc")
f("abc").given(ctx)
f.given(global)("abc").given(ctx)

Which looks much saner to me and has the very desirable (IMO) property that there’s less distance between opening and closing parentheses, e.g. f.given(global)("abc") as opposed to (f given global)("abc").

[odersky]

My first reaction: I like .given. That reads even better than as an infix operator.

[drdozer]

@Jasper-M

@drdozer In your experience, would the given for implied syntax still be a huge improvement over regular implicits , if they received those improvements?

Sorry, only just saw this. Apart from the “it works better” reasons for liking the implied given for syntax (modulo I’d wish to change implied to instance or deriving in the declarations) is that it feels like a much cleaner and distinct model for describing derivable values, and how to construct them from one-another. The implied def/object/val constructs in scala 2.* always felt to me as if derived values were being simulated using a source-level DSL within scala. That we were writing the plumbing of an implementation of this machinery. Using implied given for, there is a single, first-class syntax for this, which only does this, and does all of this. It is far, far clearer to see at a glance what code is introducing and manipulating supplied values, and what code is introducing and manipulation derived values. I find it a much lower cognitive overhead writing even quite complex stacks of derived instances using the new syntax, that I’ve never been able to do in practice with the old syntax.

[Ichoran]

@tarsa

If given is an infix operator then why can’t we turn it into a dotted notation?

That would be lovely!

(I think it would be great if match could be also; but I’ll take every dottable operator-or-method-like thing I can get. I always appreciate the regularity-of-flexibility in invocation.)

[nafg]

Too bad I missed most of the discussion (since it happened on Passover).

I think one thing that hasn’t really been expressed is that there’s a huge risk involved. We don’t know what effect it will have on people open to begin using Scala or to stop using Scala. Maybe it will make more people learn Scala. Maybe it won’t. Maybe it will cause people that were on the fence to stop using Scala. Maybe it won’t. We don’t know.

Personally, my reaction to the new syntax is that perhaps it could be justified, but it’s not Scala. It feels like after a decade of using Scala, to continue using it I have to learn a new language now.

Because of the above I feel very strongly that we should take this slowly. There is already a huge amount of changes in Scala 3.0. There is no reason that this has to be in the same release. It can wait. (Personally, I would make the release that includes this Scala 4.0, even if it were released only a week after 3.0.)

Meanwhile, all of the proposed improvements to implicits that don’t break code or involve paradigm shifts, should go into 3.0. Or 2.14. Those have the least risk for the greatest gain. Then we can decide whether it’s worth the bolder move.

[tarsa]

@nafg

Personally, my reaction to the new syntax is that perhaps it could be justified, but it’s not Scala. It feels like after a decade of using Scala, to continue using it I have to learn a new language now.

IMO given doesn’t make Scala much more different. Overall it seems that what given changes is giving implicit arguments less priority than regular arguments. It won’t substantially change the shape of Scala programs if method notation for given arguments (i.e. f.given(a)(b).given(c)) will be used.

OTOH removing assignment operator from typeclasses instances definition could require tedious restructuring. instance abc of Type given xyz { ...class members... } is greatly limited compared to implicit abc: Type given xyz = anything.
Update: I missed aliases in implied instances proposal. Well, it changes the situation then.

[aosagie]

I love the simplicity and targeted nature of your proposal.

What do you think of just enforcing that passing implicit arguments must be by-name instead of positional? Instead of:

@smarter

maximum(xs)(implicit descending)

Just doing:

maximum(xs)(ord = descending)

Do you think that would solve the same problem and be even less radical of a change?

[bmeesters]

The problem with your proposal is that it could also be a normal argument list, and you cannot see it from here.

It also goes against two of the principles as discussed in the other thread (leaving out of scope whether or not you agree with them):

• It doesn’t mirror call and use sites.
• It doesn’t distance implicit parameters from normal parameters anymore than is done now, which is one of the reasons the change it.

[scalway]

I like idea with given as function call f.given(a)(b).given(c) but it moves back to first implementation that was proposed few years ago f.implicitly(a)(b).implicitly(c). Why original proposition was abandoned?

This volatile also first rule:

(1) Implicit parameters and arguments should use the same syntax

Maybe we should also accept same syntax on definition site then?

def f(x: Double).given(ctx: Context):Double = { ... } 

[curoli]

If I want to respond directly to a point made, how can I do that? Can I split off a separate thread by replying to a post here?

[virusdave]

+1 to infer and inferred over implied

[tarsa]

@scalway

I like idea with given as function call f.given(a)(b).given(c) but it moves back to first implementation that was proposed few years ago f.implicitly(a)(b).implicitly(c) . Why original proposition was abandoned?

I don’t remember implicitly keyword being suggested, but anyway implicitly is already present in Scala’s stdlib as a function and it’s frequently used. You would first need to deprecate that method in Scala Next and only in Scala Next+1 you would have a chance to reintroduce implicitly as a keyword. To avoid that lengthy process you need to choose another keyword.

[nafg]

It’s not a keyword, it would be a method, much like apply

[curoli]

I don’t want to hijack this thread (and started a new one on Scala governance to take any further discussion there), but I feel this statement needs a reply:

I think you’re over-interpreting this. I mean, Martin does not
have the final say here, the SIP committee does. Yes, he’s extremely influential in the process, but we’ve long since moved on from “everything Martin says is final”.

I don’t think that is entirely correct. The SIP submission process details:

For a SIP to be accepted, the following three requirements must be met:

• At least 50% of the committee members vote in favor.
• There are at least two-thirds “in favor” versus “against” votes.
• Martin Odersky does not veto it.
  

[soronpo]

AFAIK, he can only veto against a proposal, but not in favor.

[yangbo]

I agree with @lihaoyi, even if we use the given syntax, we should instead choose another keyword that is more familiar to mainstream language developers.

The alternative keywords to given that I can imagine include:

• autowire
• inject
• import

[odersky]

Principles for Implicits in Scala 3

Here’s an update: The SIP committee voted to accept provisionally the changes to implied instances and given clauses. This means: We will go forward with the design of these two components as they are currently specified and implemented in the Dotty codebase. Before we ship 3.0 final (sometimes in 2020) we will evaluate whether the new features saw significant use and what the usage experience was. If these are judged unsatisfactory we keep the possibility open to drop one or both of the chang…

[gabrieljones]

I propose changing

delegate for

to

delegate as

eg

s/delegate (.*) for/delegate $1 as/

Old Post:
I propose changing

implied for

to

implied as

eg

s/implied (.*) for/implied $1 as/