search

scalapuzzlers / scalapuzzlers.github.com

Github Pages behind scalapuzzlers.com
www.scalapuzzlers.com
161 stars 53 forks source link

Puzzler 14: Puzzler on implicit conversions #28

Closed dgruntz closed 11 years ago

dgruntz commented 12 years ago

enclosed you find a puzzler on implicit conversions. I am not yet that happy with the explanation, probably you can check that one. It is clear to me what the compiler does, but I cannot map that 1 by 1 on the spec.

demobox commented 12 years ago

grin. So how did you run across this one? ;-)

dgruntz commented 12 years ago

well, the def/val priority difference is something that I realized while reading the spec, and the last option is something I found in a bug report.

Regarding the other question wrt applicability, I hoped to get an answer from your side ;-) I have to check it once again. I debugged the compiler to find out what is going on, but I am nut sure whether the spec really describes what the compiler is doing.

dgruntz commented 12 years ago

I have to ask Martin, but he is away next week, so this one will be delayed for at least one week.

demobox commented 12 years ago

An answer from Martin sounds like it's worth the wait ;-) Thanks!

demobox commented 12 years ago

@dgruntz Has Martin been able to shed any light on what is going on here..?

dgruntz commented 12 years ago

not yet. He was too busy this week (after ECOOP). Actually it is not clear to me whether it is a specification issue or a bug in the compiler. But it is on my list - will try to resolve this issue next week.

-----Original Message----- From: Andrew Phillips [mailto:reply@reply.github.com] Sent: Donnerstag, 21. Juni 2012 18:55 To: Gruntz Dominik Subject: Re: [scalapuzzlers.github.com] Puzzler 14: Puzzler on implicit conversions (#28)

@dgruntz Has Martin been able to shed any light on what is going on here..?

Reply to this email directly or view it on GitHub: https://github.com/scalapuzzlers/scalapuzzlers.github.com/pull/28#issuecomment-6488130

demobox commented 12 years ago

Tsk...who cares about ECOOP when there are Scala Puzzlers questions to be answered? ;-))

nermin commented 12 years ago

@demobox exactly!

demobox commented 12 years ago

Warming this one up again. Any news, @dgruntz ? ;-)

demobox commented 12 years ago

@jsuereth : After your flawless Puzzler performance (so @nermin informes me ;-) ) I was going to take the liberty to ask whether you have any thoughts on this one, Josh. Thanks!

dgruntz commented 12 years ago

I was busy the last few weeks (the semester starts next week). I intend to contact/ask Jason as it is a spec question (it is only the explanation which is open).

demobox commented 12 years ago

No hurry - there's no timeout on puzzlers ;-) Good luck with the new semester!

som-snytt commented 12 years ago

I don't understand the hang-up. Delete the phrase about "not applicable." The two steps are (as noted) prefer not parameterized and prefer defined in derived class. It is as spec'd.

Recently, I heard a character on one of those CSI-style tv crime dramas pronounce it paraMEterized.

BTW, there is a timeout on puzzlers. Every Scala release risks invalidating them all with a bug fix or a feature.

demobox commented 12 years ago

BTW, there is a timeout on puzzlers. Every Scala release risks invalidating them all with a bug fix or a feature.

Indeed. In fact, we already know one puzzler that will be affected. We're wondering about whether to put them in some kind of archive, or deprecate them, or...

Any thoughts on that from your side?

som-snytt commented 12 years ago

A drop-down to select a versioned view of the puzzlers, of course. Is that actually easy on github?

demobox commented 11 years ago

On reviewing this one again, I agree with @som-snytt and the explanation that at least aToBobj being chosen in preference to aToBval appears to be as spec'd, since the class of aToBobj derives from the class of aToBval.

Since, according to the following REPL session (2.10.0), aToBval is also chosen in preference to aToBdef, it would seem that the behaviour observed is as expected, and so not "puzzling" unless one is not aware of the precedence rules:

scala> class A
defined class A

scala> case class B(value: String)
defined class B

scala> implicit def aToBdef(x: A) = B("def")
warning: there were 1 feature warnings; re-run with -feature for details
aToBdef: (x: A)B

scala> implicit val aToBval = (x: A) => B("val")
aToBval: A => B = <function1>

scala> val b: B = new A
b: B = B(val)

@dgruntz @som-snytt : could you suggest a spec reference for the "def/val priority difference"/"prefer not parameterized" precedence on which this last case is based? It does not appear to be based on 6.26.3 since

  1. aToBval is as specific as aToBdef since it is a non-parameterized "member of any other type"
  2. aToBdef is as specific as aToBval since aToBval.apply is applicable to arguments of type A
  3. The types do not derive from each other

Searching for more information, I came across this scala-lang thread from last year which, if anything, seems to indicate that "val over def" for implicits is a bug.

demobox commented 11 years ago

@dgruntz Any more news on this one? Or do you think it should better be closed, and perhaps revived at a later date..?

demobox commented 11 years ago

Or do you think it should better be closed, and perhaps revived at a later date..?

@dgruntz I think we'll close this one for now. Please reopen if any more details emerge and you're interested in continuing! And, of course, thanks for the proposal! ;-)

dgruntz commented 11 years ago

ok

demobox commented 11 years ago

ok

@dgruntz Hi Dominik! Glad to hear from you again after a while ;-) If you do get more information about this puzzler, am certainly looking forward to understanding what is (supposed to) going on there!