This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Re: Making the scala compiler smarter about overloaded methods

3 replies
Hiram Chirino
Joined: 2011-02-01,
User offline. Last seen 42 years 45 weeks ago.

Accidentally went off list. Bringing back.

On Mon, Feb 7, 2011 at 5:49 PM, martin odersky wrote:
> On Mon, Feb 7, 2011 at 11:44 PM, Chirino, Hiram wrote:
>>
>> Seems to me that at since the there is no way for the caller to force
>> a => T type, overloading should consider all => T as being T when
>> comparing the type arguments of an overloaded method for purposes of
>> finding a more specific method.
>>
> There are good reasons why we do not want that. Notably, we want a
> method taking a T to be more specific than a method taking a => T.
> Believe me, it's pretty carefully calibrated.
>
> Cheers
>
>  -- Martin

Yeah seems delicate.  Ok here's my last shot at it then:  do in 2
passes, the first
pass does it like it's currently done, and if it's still ambiguous
then do a second pass with the => T to T conversion trick in hopes
that it gives you an un-ambiguous selection.

Should give us the best of both worlds.

--
Regards,
Hiram

FuseSource
Web: http://fusesource.com/

Hiram Chirino
Joined: 2011-02-01,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Making the scala compiler smarter about overloaded meth

On Tue, Feb 8, 2011 at 8:18 AM, martin odersky wrote:
> On Tue, Feb 8, 2011 at 12:22 AM, Chirino, Hiram wrote:
>> On Mon, Feb 7, 2011 at 5:49 PM, martin odersky wrote:
>>> On Mon, Feb 7, 2011 at 11:44 PM, Chirino, Hiram wrote:
>>>>
>>>> Seems to me that at since the there is no way for the caller to force
>>>> a => T type, overloading should consider all => T as being T when
>>>> comparing the type arguments of an overloaded method for purposes of
>>>> finding a more specific method.
>>>>
>>> There are good reasons why we do not want that. Notably, we want a
>>> method taking a T to be more specific than a method taking a => T.
>>> Believe me, it's pretty carefully calibrated.
>>>
>>> Cheers
>>>
>>>  -- Martin
>>
>> Yeah seems delicate.  Ok here's my last shot at it then:  do in 2
>> passes, the first
>> pass does it like it's currently done, and if it's still ambiguous
>> then do a second pass with the => T to T conversion trick in hopes
>> that it gives you an un-ambiguous selection.
>>
>
> You'd need to write spec language for that and convince everyone that
> (a) nothing breaks and (b) the added complications are worth it. It's
> a huge and very hard task, which requires a SIP. Overloading
> resolution is one of the most subtle parts of both the Java and the
> Scala specs. You fiddle with it at your own risk ;-)
>
> Cheers
>
>  -- Martin
>

Fair enough. I'm not a language spec guru, so I'm not sure I'd be
able help much on that front. But I was able implement the change we
discussed and it seems to be working swimmingly. You can find the
patch at:

https://github.com/chirino/scala/commit/bc0ff4bae0121ba6fc7c4d12acd122bc...

With this patch in place, overloaded method resolution is 100%
backward compatible since the change only kicks in when the compiler
would have failed due to the method being ambiguous. With the patch
in place you now have the chance to call methods which were previously
thought ambiguous.

extempore
Joined: 2008-12-17,
User offline. Last seen 35 weeks 3 days ago.
Re: Re: Making the scala compiler smarter about overloaded meth

On 2/8/11 7:07 AM, Chirino, Hiram wrote:
> Fair enough. I'm not a language spec guru, so I'm not sure I'd be
> able help much on that front. But I was able implement the change we
> discussed and it seems to be working swimmingly.

Yay for people who implement their ideas. (Or even try.)

There are multiple precedents for "try it this way, and then try it that
way only if it would otherwise fail" in the compiler. That said, they
are not embraced with enthusiasm.

What you want here seems pretty reasonable to me if only because there
is no way I can see to disambiguate the overload you're looking at in
favor of the by-name argument. So it will let you compile something
which you can never use, a situation I am always eager to avoid. I'm
not sure if it has been pointed out, but you can disambiguate it the
other way like this:

foo(arg, Nil: _*)

Hiram Chirino 2
Joined: 2011-02-27,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Making the scala compiler smarter about overloaded meth

Hi,

Anyone had chance to peek at that patch? It's applying the additional
overloading resolution attempt in the tryTwice method which was also
using the same strategy to handle resolution with implicits
enabled/disabled.

BTW where is the wording in the spec which covers that try again
behavior that the compiler is currently using for the implicits? I'm
sure we could probably extend it a little so it also cover the case
that my patch is covering.

On Tue, Feb 8, 2011 at 10:07 AM, Chirino, Hiram wrote:

>>
>> You'd need to write spec language for that and convince everyone that
>> (a) nothing breaks and (b) the added complications are worth it. It's
>> a huge and very hard task, which requires a SIP. Overloading
>> resolution is one of the most subtle parts of both the Java and the
>> Scala specs. You fiddle with it at your own risk ;-)
>>
>> Cheers
>>
>>  -- Martin
>>
>
> Fair enough.  I'm not a language spec guru, so I'm not sure I'd be
> able help much on that front.  But I was able implement the change we
> discussed and it seems to be working swimmingly.  You can find the
> patch at:
>
> https://github.com/chirino/scala/commit/bc0ff4bae0121ba6fc7c4d12acd122bc...
>
> With this patch in place, overloaded method resolution is 100%
> backward compatible since the change only kicks in when the compiler
> would have failed due to the method being ambiguous.  With the patch
> in place you now have the chance to call methods which were previously
> thought ambiguous.
>
> --
> Regards,
> Hiram
>
> FuseSource
> Web: http://fusesource.com/
>

---
Regards,
Hiram

FuseSource
Web: http://fusesource.com/

Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland