Eta expansion, meet overloading
Jason Zaugg
I can't find this in the spec, nor infer the logic from these examples:
https://gist.github.com/900853
-jason
Miles Sabin
A target type will resolve the overload,
scala> object OL { def foo() = ""; def foo(a: Any) = "" }
defined module OL
scala> OL.foo _
res0: () => java.lang.String = <function0>
scala> OL.foo _ : (Any => String)
res1: (Any) => String = <function1>
scala> object OL { def foo(a: Any) = ""; def foo(a: Any, b: Any) = "" }
defined module OL
scala> OL.foo _
res2: (Any, Any) => java.lang.String = <function2>
scala> OL.foo _ : (Any => String)
res3: (Any) => String = <function1>
I have to agree that the choice of overload appears somewhat arbitrary
in the absence of a guiding type annotation.
Cheers,
Miles
--
Miles Sabin
tel: +44 7813 944 528
gtalk: mi...@milessabin.com
skype: milessabin
http://www.chuusai.com/
http://twitter.com/milessabin
Paul Phillips
> How is `foo _` resolved if `foo` is overloaded?
>
> I can't find this in the spec, nor infer the logic from these examples:
Here are a few more which will shed absolutely no light on anything.
scala> object OL { def foo(a: Int) = ""; def foo(a: Int, b: Int) = "" }
defined module OL
scala> OL.foo _
<console>:9: error: ambiguous reference to overloaded definition,
both method foo in object OL of type (a: Int,b: Int)java.lang.String
and method foo in object OL of type (a: Int)java.lang.String
match expected type ?
OL.foo _
^
scala> object OL { def foo(a: Int) = ""; def foo(a: AnyRef, b: Int) = "" }
defined module OL
scala> OL.foo _
<console>:9: error: ambiguous reference to overloaded definition,
both method foo in object OL of type (a: AnyRef,b: Int)java.lang.String
and method foo in object OL of type (a: Int)java.lang.String
match expected type ?
OL.foo _
^
scala> object OL { def foo(a: AnyRef) = ""; def foo(a: Int, b: Int) = "" }
defined module OL
scala> OL.foo _
res10: (Int, Int) => java.lang.String = <function2>
Jason Zaugg
> On 4/3/11 2:48 PM, Jason Zaugg wrote:
>>
>> How is `foo _` resolved if `foo` is overloaded?
>>
>> I can't find this in the spec, nor infer the logic from these examples:
>
> Here are a few more which will shed absolutely no light on anything.
Perhaps deprecation would be more straightforward than specification.
-jason
Paul Phillips
> Perhaps deprecation would be more straightforward than specification.
Oh, you and martin are real opinion buddies on this one. Everyone wants
to deprecate poor trailing underscore. I will contrive an example of
why I would miss it. (I use this power in the repl with some frequency.
I guess I could keep faking it in the repl even if it were gone.)
// do dee do, thinking about plumping f up a bit
scala> class A { def f(x1: Int, x2: Int, x3: Int) = x1+x2+x3 }
defined class A
scala> def g(x: A) = x.f _
g: (x: A)(Int, Int, Int) => Int
// I'm doing it! Four! Four value parameters! A ha ha!
scala> class A { def f(x1: Int, x2: Int, x3: Int, x4: Int) = x1+x2+x3+x4 }
defined class A
// Wow, it's source compatible. Abstraction over arity!
// Practcally the only one we have!
scala> def g(x: A) = x.f _
g: (x: A)(Int, Int, Int, Int) => Int
// But without that power, we are sad pandas
scala> class A { def f(x1: Int, x2: Int, x3: Int) = x1+x2+x3 }
defined class A
// g: "I'm grouchy, verbose, and set in my ways. Three, no more no less."
scala> def g(x: A) = x.f(_, _, _)
g: (x: A)(Int, Int, Int) => Int
scala> class A { def f(x1: Int, x2: Int, x3: Int, x4: Int) = x1+x2+x3+x4 }
defined class A
// Ay caramba, error splosion.
scala> def g(x: A) = x.f(_, _, _)
<console>:8: error: missing parameter type for expanded function ((x$1,
x$2, x$3) => x.f(x$1, x$2, x$3))
def g(x: A) = x.f(_, _, _)
^
<console>:8: error: missing parameter type for expanded function ((x$1:
<error>, x$2, x$3) => x.f(x$1, x$2, x$3))
def g(x: A) = x.f(_, _, _)
^
<console>:8: error: missing parameter type for expanded function ((x$1:
<error>, x$2: <error>, x$3) => x.f(x$1, x$2, x$3))
def g(x: A) = x.f(_, _, _)
^
<console>:8: error: not enough arguments for method f: (x1: Int,x2:
Int,x3: Int,x4: Int)Int.
Unspecified value parameter x4.
def g(x: A) = x.f(_, _, _)
^
Jim Powers
On 4/3/11 3:30 PM, Jason Zaugg wrote:Oh, you and martin are real opinion buddies on this one. Everyone wants to deprecate poor trailing underscore. I will contrive an example of why I would miss it. (I use this power in the repl with some frequency. I guess I could keep faking it in the repl even if it were gone.)
Perhaps deprecation would be more straightforward than specification.
Jim Powers
--
Chris Twiner
I don't want to be a sad panda _
On 4 Apr 2011 00:44, "Paul Phillips" <pa...@improving.org> wrote:
On 4/3/11 3:30 PM, Jason Zaugg wrote:
>
> Perhaps deprecation would be more straightforward than spe...
Jason Zaugg
> I don't want to be a sad panda _
>
> On 4 Apr 2011 00:44, "Paul Phillips" <pa...@improving.org> wrote:
>
> On 4/3/11 3:30 PM, Jason Zaugg wrote:
>>
>> Perhaps deprecation would be more straightforward than spe...
>
> Oh, you and martin are real opinion buddies on this one. Everyone wants to
> deprecate poor trailing underscore. I will contrive an example of why I
> would miss it. (I use this power in the repl with some frequency. I guess
> I could keep faking it in the repl even if it were gone.)
For the record, I'm only advocating a deprecation in the case of an
overloaded panda. Who is probably already sad.
-jason
Johannes Rudolph
> For the record, I'm only advocating a deprecation in the case of an
> overloaded panda. Who is probably already sad.
Good to know! I wouldn't be too happy as well to lose the trailing
underscore completely. I think 'deprecation' is what misguided us of
your intentions here. Deprecating something which is as unspecified as
the poor panda twins makes only little sense because no one could have
seriously relied on that feature (though reality will teach me
otherwise probably). Couldn't we just add an error message in the
overloaded case which says "Ambiguous reference to overloaded method
`foo` in partial application, add an explicit type ascription to
disambiguate." or something more glorious?
--
Johannes
-----------------------------------------------
Johannes Rudolph
http://virtual-void.net
martin odersky
On Mon, Apr 4, 2011 at 10:11 AM, Jason Zaugg <jza...@gmail.com> wrote:Good to know! I wouldn't be too happy as well to lose the trailing
> For the record, I'm only advocating a deprecation in the case of an
> overloaded panda. Who is probably already sad.
underscore completely. I think 'deprecation' is what misguided us of
your intentions here. Deprecating something which is as unspecified as
the poor panda twins makes only little sense because no one could have
seriously relied on that feature (though reality will teach me
otherwise probably). Couldn't we just add an error message in the
overloaded case which says "Ambiguous reference to overloaded method
`foo` in partial application, add an explicit type ascription to
disambiguate." or something more glorious?
f _ is exactly the same as f(_). At that time we should deprecate. Again, nothing like that is planned yet. There are too many more urgent things to do.
Cheers
-- Martin
Johannes
-----------------------------------------------
Johannes Rudolph
http://virtual-void.net
--
----------------------------------------------
Martin Odersky
Prof., EPFL and CEO, Scala Solutions
PSED, 1015 Lausanne, Switzerland
Jason Zaugg
>> For the record, I'm only advocating a deprecation in the case of an
>> overloaded panda. Who is probably already sad.
>
> Good to know! I wouldn't be too happy as well to lose the trailing
> underscore completely. I think 'deprecation' is what misguided us of
> your intentions here. Deprecating something which is as unspecified as
> the poor panda twins makes only little sense because no one could have
> seriously relied on that feature (though reality will teach me
> otherwise probably). Couldn't we just add an error message in the
> overloaded case which says "Ambiguous reference to overloaded method
> `foo` in partial application, add an explicit type ascription to
> disambiguate." or something more glorious?
That would also suit me; I was suggesting deprecation as the more
conservative route.
I wouldn't actually bother to allow disambiguate through the the
expected type. I don't think pandering (ha!) to overloaders is worth
the baggage of spec and implementation complexity.
-jason