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

Passing methods around

8 replies
Sophie
Joined: 2011-11-10,
User offline. Last seen 42 years 45 weeks ago.

In the REPL:

>> def isOdd(x: Int) ...

>> List(1,2,3,4,5).filter(isOdd) // works fine

>> isOdd
:14: error: missing arguments for method isOdd in object $iw;
follow this method with `_' if you want to treat it as a partially
applied function
isOdd

Why this difference? Some implicit conversions?

bmjsmith
Joined: 2010-03-12,
User offline. Last seen 42 years 45 weeks ago.
Re: Passing methods around
You can omit the _  that serves as a placeholder where a function is required, and since filter takes a function type A=> Boolean it's allowed. 
There's an explanation at the end of 8.6 in Programming In Scala.
Cheers
Brian

On 13 December 2011 21:47, Sophie <itsme213@hotmail.com> wrote:
In the REPL:

def isOdd(x: Int) ...

List(1,2,3,4,5).filter(isOdd)  // works fine

isOdd
<console>:14: error: missing arguments for method isOdd in object $iw;
follow this method with `_' if you want to treat it as a partially applied function
            isOdd

Why this difference? Some implicit conversions?



Sophie
Joined: 2011-11-10,
User offline. Last seen 42 years 45 weeks ago.
Re: Passing methods around

Thanks, Brian!

On 2011-12-13 16:01:03 -0600, Brian Smith said:

> You can omit the _  that serves as a placeholder where a function is
> required, and since filter takes a function type A=> Boolean it's
> allowed. 
>
> There's an explanation at the end of 8.6 in Programming In Scala.
>
> Cheers
>
> Brian
>
> On 13 December 2011 21:47, Sophie
> wrote:
> In the REPL:
>
> def isOdd(x: Int) ...
>
> List(1,2,3,4,5).filter(isOdd)  // works fine
>
> isOdd
> :14: error: missing arguments for method isOdd in object $iw;
> follow this method with `_' if you want to treat it as a partially
> applied function
>             isOdd
>
> Why this difference? Some implicit conversions?

Joshua.Suereth
Joined: 2008-09-02,
User offline. Last seen 32 weeks 5 days ago.
Re: Re: Passing methods around
This is called 'lifting' or 'lambda lifiting'.   Scala can negate some of the syntax required to lift a method into a function *if* the context is right.

  val x = method_foo _ // Manually lifting a method.   val x: Int => Int = metohd_foo   // Context lets Scala know it's ok to lift.

On Tue, Dec 13, 2011 at 7:02 PM, Sophie <itsme213@hotmail.com> wrote:
Thanks, Brian!

On 2011-12-13 16:01:03 -0600, Brian Smith said:

You can omit the _  that serves as a placeholder where a function is required, and since filter takes a function type A=> Boolean it's allowed. 

There's an explanation at the end of 8.6 in Programming In Scala.

Cheers

Brian

On 13 December 2011 21:47, Sophie <itsme213@hotmail.com> wrote:
In the REPL:

def isOdd(x: Int) ...

List(1,2,3,4,5).filter(isOdd)  // works fine

isOdd
<console>:14: error: missing arguments for method isOdd in object $iw;
follow this method with `_' if you want to treat it as a partially applied function
            isOdd

Why this difference? Some implicit conversions?




Kevin Wright 2
Joined: 2010-05-30,
User offline. Last seen 26 weeks 4 days ago.
Re: Re: Passing methods around
I find that an analogy which works well for many people is Java's boxed primitives.
An int isn't an object and so you can't have a List<int>.  You can, however, have a List<Integer>.  If you try and append an int to this list then it'll be boxed.
In the same way, a Scala `FunctionN` is an object that can be happily passed around by reference.  Whereas a method is simply a member of some other other object, but it can be boxed/lambda lifted when required.
This is automatic in many cases where it's unambiguous, or you can explicitly use the trailing underscore.



On 14 December 2011 14:23, Josh Suereth <joshua.suereth@gmail.com> wrote:
This is called 'lifting' or 'lambda lifiting'.   Scala can negate some of the syntax required to lift a method into a function *if* the context is right.

  val x = method_foo _ // Manually lifting a method.   val x: Int => Int = metohd_foo   // Context lets Scala know it's ok to lift.

On Tue, Dec 13, 2011 at 7:02 PM, Sophie <itsme213@hotmail.com> wrote:
Thanks, Brian!

On 2011-12-13 16:01:03 -0600, Brian Smith said:

You can omit the _  that serves as a placeholder where a function is required, and since filter takes a function type A=> Boolean it's allowed. 

There's an explanation at the end of 8.6 in Programming In Scala.

Cheers

Brian

On 13 December 2011 21:47, Sophie <itsme213@hotmail.com> wrote:
In the REPL:

def isOdd(x: Int) ...

List(1,2,3,4,5).filter(isOdd)  // works fine

isOdd
<console>:14: error: missing arguments for method isOdd in object $iw;
follow this method with `_' if you want to treat it as a partially applied function
            isOdd

Why this difference? Some implicit conversions?







--
Kevin Wright
mail: kevin.wright@scalatechnology.com
gtalk / msn : kev.lee.wright@gmail.com quora: http://www.quora.com/Kevin-Wrightgoogle+: http://gplus.to/thecoda
kev.lee.wright@gmail.com twitter: @thecoda
vibe / skype: kev.lee.wrightsteam: kev_lee_wright
"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra
Alan Burlison
Joined: 2011-08-26,
User offline. Last seen 42 years 45 weeks ago.
Re: Re: Passing methods around

On 14/12/2011 14:33, Kevin Wright wrote:

> I find that an analogy which works well for many people is Java's boxed
> primitives.
>
> An int isn't an object and so you can't have a List. You can,
> however, have a List. If you try and append an int to this list
> then it'll be boxed.
>
> In the same way, a Scala `FunctionN` is an object that can be happily
> passed around by reference. Whereas a method is simply a member of some
> other other object, but it can be boxed/lambda lifted when required.
>
> This is automatic in many cases where it's unambiguous, or you can
> explicitly use the trailing underscore.

I think that's a very useful analogy.

Andreas Scheinert
Joined: 2011-02-11,
User offline. Last seen 42 years 45 weeks ago.
Re: Passing methods around

Hi Josh!
IMHO it would be very nice to have that explanation on the official
Docs. When I search for lift in the Docs today nothing useful appears.

Regards Andreas

On 14 Dez., 15:23, Josh Suereth wrote:
> This is called 'lifting' or 'lambda lifiting'.   Scala can negate some of
> the syntax required to lift a method into a function *if* the context is
> right.
>
>   val x = method_foo _ // Manually lifting a method.
>   val x: Int => Int = metohd_foo   // Context lets Scala know it's ok to
> lift.
>
>
>
> On Tue, Dec 13, 2011 at 7:02 PM, Sophie wrote:
> > Thanks, Brian!
>
> > On 2011-12-13 16:01:03 -0600, Brian Smith said:
>
> >  You can omit the _  that serves as a placeholder where a function is
> >> required, and since filter takes a function type A=> Boolean it's allowed.
>
> >> There's an explanation at the end of 8.6 in Programming In Scala.
>
> >> Cheers
>
> >> Brian
>
> >> On 13 December 2011 21:47, Sophie wrote:
> >> In the REPL:
>
> >> def isOdd(x: Int) ...
>
> >> List(1,2,3,4,5).filter(isOdd)  // works fine
>
> >> isOdd
> >> :14: error: missing arguments for method isOdd in object $iw;
> >> follow this method with `_' if you want to treat it as a partially
> >> applied function
> >>             isOdd
>
> >> Why this difference? Some implicit conversions?

dcsobral
Joined: 2009-04-23,
User offline. Last seen 38 weeks 5 days ago.
Re: Re: Passing methods around
Isn't it called eta expansion in the spec?

Em 14/12/2011, às 12:23, Josh Suereth <joshua.suereth@gmail.com> escreveu:

This is called 'lifting' or 'lambda lifiting'.   Scala can negate some of the syntax required to lift a method into a function *if* the context is right.

  val x = method_foo _ // Manually lifting a method.   val x: Int => Int = metohd_foo   // Context lets Scala know it's ok to lift.

On Tue, Dec 13, 2011 at 7:02 PM, Sophie <itsme213@hotmail.com> wrote:
Thanks, Brian!

On 2011-12-13 16:01:03 -0600, Brian Smith said:

You can omit the _  that serves as a placeholder where a function is required, and since filter takes a function type A=> Boolean it's allowed. 

There's an explanation at the end of 8.6 in Programming In Scala.

Cheers

Brian

On 13 December 2011 21:47, Sophie <itsme213@hotmail.com> wrote:
In the REPL:

def isOdd(x: Int) ...

List(1,2,3,4,5).filter(isOdd)  // works fine

isOdd
<console>:14: error: missing arguments for method isOdd in object $iw;
follow this method with `_' if you want to treat it as a partially applied function
            isOdd

Why this difference? Some implicit conversions?




Joshua.Suereth
Joined: 2008-09-02,
User offline. Last seen 32 weeks 5 days ago.
Re: Re: Passing methods around
OOps, yeah, I meant eta expansion.   Lifting is something else...

On Sat, Dec 17, 2011 at 8:28 PM, Daniel Sobral <dcsobral@gmail.com> wrote:
Isn't it called eta expansion in the spec?

Em 14/12/2011, às 12:23, Josh Suereth <joshua.suereth@gmail.com> escreveu:

This is called 'lifting' or 'lambda lifiting'.   Scala can negate some of the syntax required to lift a method into a function *if* the context is right.

  val x = method_foo _ // Manually lifting a method.   val x: Int => Int = metohd_foo   // Context lets Scala know it's ok to lift.

On Tue, Dec 13, 2011 at 7:02 PM, Sophie <itsme213@hotmail.com> wrote:
Thanks, Brian!

On 2011-12-13 16:01:03 -0600, Brian Smith said:

You can omit the _  that serves as a placeholder where a function is required, and since filter takes a function type A=> Boolean it's allowed. 

There's an explanation at the end of 8.6 in Programming In Scala.

Cheers

Brian

On 13 December 2011 21:47, Sophie <itsme213@hotmail.com> wrote:
In the REPL:

def isOdd(x: Int) ...

List(1,2,3,4,5).filter(isOdd)  // works fine

isOdd
<console>:14: error: missing arguments for method isOdd in object $iw;
follow this method with `_' if you want to treat it as a partially applied function
            isOdd

Why this difference? Some implicit conversions?





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