What's the difference between functions and methods?

[daniel.green]

I'm in the middle of an argument.

I'm saying that this:

def foo = 3

is a method

and this

val f  = () => 3

is a function

coworker says no saying that it only exists in my mind. What's the deal?

[David MacIver]

On Thu, Aug 14, 2008 at 10:38 PM, Daniel Green <octoberdan@...> wrote:

> I'm in the middle of an argument.
>
> I'm saying that this:
>
> def foo = 3
>
> is a method
>
> and this
>
> val f  = () => 3
>
> is a function
>
> coworker says no saying that it only exists in my mind. What's the deal?

You're right. I sortof wish you weren't, but as it stands (and
probably perpetually) there are quite a few minor semantic differences
between the two.

For example, try

println(f);
val f = () => 3
println(f);

and

println(g);
def g = 3;
println(g);

You'll get very different results.

Additionally it matters in terms of overriding, overloading, etc.

[daniel.green]

>> coworker says no saying that it only exists in my mind. What's the deal?
>
> You're right. I sortof wish you weren't, but as it stands (and
> probably perpetually) there are quite a few minor semantic differences
> between the two.
>
Is it incorrect to call a method a function?

On Thu, Aug 14, 2008 at 5:51 PM, David MacIver <david.maciver@...> wrote:

> On Thu, Aug 14, 2008 at 10:38 PM, Daniel Green <octoberdan@...> wrote:
>> I'm in the middle of an argument.
>>
>> I'm saying that this:
>>
>> def foo = 3
>>
>> is a method
>>
>> and this
>>
>> val f  = () => 3
>>
>> is a function
>>
>> coworker says no saying that it only exists in my mind. What's the deal?
>
> You're right. I sortof wish you weren't, but as it stands (and
> probably perpetually) there are quite a few minor semantic differences
> between the two.
>
> For example, try
>
> println(f);
> val f = () => 3
> println(f);
>
> and
>
> println(g);
> def g = 3;
> println(g);
>
> You'll get very different results.
>
> Additionally it matters in terms of overriding, overloading, etc.
>

[David MacIver]

On Thu, Aug 14, 2008 at 10:55 PM, Daniel Green <octoberdan@...> wrote:
>>> coworker says no saying that it only exists in my mind. What's the deal?
>>
>> You're right. I sortof wish you weren't, but as it stands (and
>> probably perpetually) there are quite a few minor semantic differences
>> between the two.
>>
> Is it incorrect to call a method a function?

Yes. Although methods can be converted to functions, they aren't functions.

[Alex Boisvert-3]

The Scala Book says that methods are functions attached to an object/class.

alex

On Thu, Aug 14, 2008 at 3:02 PM, David MacIver <david.maciver@...> wrote:

On Thu, Aug 14, 2008 at 10:55 PM, Daniel Green <octoberdan@...> wrote:
>>> coworker says no saying that it only exists in my mind. What's the deal?
>>
>> You're right. I sortof wish you weren't, but as it stands (and
>> probably perpetually) there are quite a few minor semantic differences
>> between the two.
>>
> Is it incorrect to call a method a function?

Yes. Although methods can be converted to functions, they aren't functions.

[David Hall-11]

Right, I would tend to think of methods more or less on the line of
(non-static) member functions in C++. They're almost just normal
functions, but not quite.

-- David

On Thu, Aug 14, 2008 at 3:18 PM, Alex Boisvert <boisvert@...> wrote:

> The Scala Book says that methods are functions attached to an object/class.
>
> alex
>
>
> On Thu, Aug 14, 2008 at 3:02 PM, David MacIver <david.maciver@...>
> wrote:
>>
>> On Thu, Aug 14, 2008 at 10:55 PM, Daniel Green <octoberdan@...>
>> wrote:
>> >>> coworker says no saying that it only exists in my mind. What's the
>> >>> deal?
>> >>
>> >> You're right. I sortof wish you weren't, but as it stands (and
>> >> probably perpetually) there are quite a few minor semantic differences
>> >> between the two.
>> >>
>> > Is it incorrect to call a method a function?
>>
>> Yes. Although methods can be converted to functions, they aren't
>> functions.
>
>

[daniel.green]

> The Scala Book says that methods are functions attached to an object/class.
>
So does that mean that they are only functions in semantic way?

On Thu, Aug 14, 2008 at 6:18 PM, Alex Boisvert <boisvert@...> wrote:

> The Scala Book says that methods are functions attached to an object/class.
>
> alex
>
>
> On Thu, Aug 14, 2008 at 3:02 PM, David MacIver <david.maciver@...>
> wrote:
>>
>> On Thu, Aug 14, 2008 at 10:55 PM, Daniel Green <octoberdan@...>
>> wrote:
>> >>> coworker says no saying that it only exists in my mind. What's the
>> >>> deal?
>> >>
>> >> You're right. I sortof wish you weren't, but as it stands (and
>> >> probably perpetually) there are quite a few minor semantic differences
>> >> between the two.
>> >>
>> > Is it incorrect to call a method a function?
>>
>> Yes. Although methods can be converted to functions, they aren't
>> functions.
>
>

[daniel.green]

Thank you all for the information. One last thing...

Is there a spec section or way I can prove the following wrong? If the
statement is in fact wrong:

"
When you write :

def square(x:Int) = x * x

The compiler does this:

val square = new Function1[Int, Int] {
  def apply(x: Int): Int = x*x
}
"

After this I'm just going to go with the flow, this is driving me nuts.

On Thu, Aug 14, 2008 at 6:40 PM, Daniel Green <octoberdan@...> wrote:

>> The Scala Book says that methods are functions attached to an object/class.
>>
> So does that mean that they are only functions in semantic way?
>
> On Thu, Aug 14, 2008 at 6:18 PM, Alex Boisvert <boisvert@...> wrote:
>> The Scala Book says that methods are functions attached to an object/class.
>>
>> alex
>>
>>
>> On Thu, Aug 14, 2008 at 3:02 PM, David MacIver <david.maciver@...>
>> wrote:
>>>
>>> On Thu, Aug 14, 2008 at 10:55 PM, Daniel Green <octoberdan@...>
>>> wrote:
>>> >>> coworker says no saying that it only exists in my mind. What's the
>>> >>> deal?
>>> >>
>>> >> You're right. I sortof wish you weren't, but as it stands (and
>>> >> probably perpetually) there are quite a few minor semantic differences
>>> >> between the two.
>>> >>
>>> > Is it incorrect to call a method a function?
>>>
>>> Yes. Although methods can be converted to functions, they aren't
>>> functions.
>>
>>
>

[James Iry-2]

Methods are not functions in Scala, in spite of what the book says there. Methods are very primitive, distinctly not first class concepts in Scala.  Functions are full blown objects with all rights, privileges, and responsibilities of full citizenship.. 

The interpreter confuses things a bit because it appears to let you write "def" at the "top level".  But it's not really the top level, you're actually creating a method on a giant object that wraps all your code.  Note the $iw in the error below.

=================
scala> def square(x:Int) = x * x
square: (Int)Int

scala> def fourth(x:Int) = (square compose square)(x)   
<console>:6: error: missing arguments for method square in object $iw;
follow this method with `_' if you want to treat it as a partially applied function
       def fourth(x:Int) = (square compose square)(x)

=================

Now watch as I use functions

scala> val square2 = {x:Int => x * x}
square2: (Int) => Int = <function>

scala> val fourth2 = square2 compose square2
fourth2: (Int) => Int = <function>

scala> fourth2(4)
res0: Int = 256

==========================

Scala also makes things a bit more confusing by implicitly converting to functions in some cases without needing the _ syntax.

scala> val fourth3 = square2 compose square
fourth3: (Int) => Int = <function>


Hopefully this has cleared everything up.

On Thu, Aug 14, 2008 at 4:19 PM, Daniel Green <octoberdan@...> wrote:

Thank you all for the information. One last thing...

Is there a spec section or way I can prove the following wrong? If the
statement is in fact wrong:

"
When you write :

def square(x:Int) = x * x

The compiler does this:

val square = new Function1[Int, Int] {
 def apply(x: Int): Int = x*x
}
"

After this I'm just going to go with the flow, this is driving me nuts.

[Seth Tisue]

>>>>> "Daniel" == Daniel Green <octoberdan@...> writes:

 Daniel> Thank you all for the information. One last thing...  Is there
 Daniel> a spec section or way I can prove the following wrong? If the
 Daniel> statement is in fact wrong:
 Daniel> " When you write :
 Daniel> def square(x:Int) = x * x
 Daniel> The compiler does this:
 Daniel> val square = new Function1[Int, Int] { def apply(x: Int): Int =
 Daniel> x*x } "

This is exactly backwards.  Methods are the fundamental concept, not
functions (or "first-class functions" or "function values" or "function
objects" or "functors" or whatever you want to call them, take your
pick).

When you write:

 def square(x:Int) = x * x

you are always doing so in the context of some class or object.  Even
when you type this in the interpreter, you are adding a method to a
special top-level object.  something like:

  object Foo {
    def square(x:Int) = x * x
  }

Defining the square method doesn't cause any Function1 objects to be
created.  A method is just a method.

On the other hand, when I do:

  val square = (x:Int) => x * x

this is equivalent to something like:

  object square extends Function1[Int,Int] {
    def apply(x:Int):Int = x * x
  }
 
This is for illustration; I don't know the internal workings of the
compiler in any detail.  But the idea is right: functions are syntactic
sugar for methods -- not vice versa.  Methods are just methods.

I had some trouble figuring this out when I was getting started...

--
Seth Tisue / http://tisue.net
lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/

[daniel.green]

Thank you all for helping me out with this, now I know I'm not crazy
and perhaps have some ammunition.

On Thu, Aug 14, 2008 at 7:58 PM, Seth Tisue <seth@...> wrote:

>>>>>> "Daniel" == Daniel Green <octoberdan@...> writes:
>
>  Daniel> Thank you all for the information. One last thing...  Is there
>  Daniel> a spec section or way I can prove the following wrong? If the
>  Daniel> statement is in fact wrong:
>  Daniel> " When you write :
>  Daniel> def square(x:Int) = x * x
>  Daniel> The compiler does this:
>  Daniel> val square = new Function1[Int, Int] { def apply(x: Int): Int =
>  Daniel> x*x } "
>
> This is exactly backwards.  Methods are the fundamental concept, not
> functions (or "first-class functions" or "function values" or "function
> objects" or "functors" or whatever you want to call them, take your
> pick).
>
> When you write:
>
>  def square(x:Int) = x * x
>
> you are always doing so in the context of some class or object.  Even
> when you type this in the interpreter, you are adding a method to a
> special top-level object.  something like:
>
>  object Foo {
>    def square(x:Int) = x * x
>  }
>
> Defining the square method doesn't cause any Function1 objects to be
> created.  A method is just a method.
>
> On the other hand, when I do:
>
>  val square = (x:Int) => x * x
>
> this is equivalent to something like:
>
>  object square extends Function1[Int,Int] {
>    def apply(x:Int):Int = x * x
>  }
>
> This is for illustration; I don't know the internal workings of the
> compiler in any detail.  But the idea is right: functions are syntactic
> sugar for methods -- not vice versa.  Methods are just methods.
>
> I had some trouble figuring this out when I was getting started...
>
> --
> Seth Tisue / http://tisue.net
> lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/
>

[Jorge Ortiz-3]

I spent a while arguing this over lunch yesterday.

My take is that there are three distinct function-like concepts in
Scala: methods, functions, and Functions (aka function objects or
function values).

class A {
  def foo = {
    def bar = 3
    val baz = (i: Int) => i + 1
    baz(bar)
  }
}

In this example, foo is a method, bar is a function, and baz is a
Function/functionobject/functionvalue.

We need three concepts because it doesn't make sense to call bar a
method, nor is it a Function in the same sense that baz is a Function.

--j

On Thu, Aug 14, 2008 at 4:38 PM, James Iry <jamesiry@...> wrote:

> Methods are not functions in Scala, in spite of what the book says there.
> Methods are very primitive, distinctly not first class concepts in Scala.
> Functions are full blown objects with all rights, privileges, and
> responsibilities of full citizenship..
>
> The interpreter confuses things a bit because it appears to let you write
> "def" at the "top level".  But it's not really the top level, you're
> actually creating a method on a giant object that wraps all your code.  Note
> the $iw in the error below.
>
> =================
> scala> def square(x:Int) = x * x
> square: (Int)Int
>
> scala> def fourth(x:Int) = (square compose square)(x)
> <console>:6: error: missing arguments for method square in object $iw;
> follow this method with `_' if you want to treat it as a partially applied
> function
>        def fourth(x:Int) = (square compose square)(x)
>
> =================
>
> Now watch as I use functions
>
> scala> val square2 = {x:Int => x * x}
> square2: (Int) => Int = <function>
>
> scala> val fourth2 = square2 compose square2
> fourth2: (Int) => Int = <function>
>
> scala> fourth2(4)
> res0: Int = 256
>
> ==========================
>
> Scala also makes things a bit more confusing by implicitly converting to
> functions in some cases without needing the _ syntax.
>
> scala> val fourth3 = square2 compose square
> fourth3: (Int) => Int = <function>
>
>
> Hopefully this has cleared everything up.
>
>
>
> On Thu, Aug 14, 2008 at 4:19 PM, Daniel Green <octoberdan@...> wrote:
>>
>> Thank you all for the information. One last thing...
>>
>> Is there a spec section or way I can prove the following wrong? If the
>> statement is in fact wrong:
>>
>> "
>> When you write :
>>
>> def square(x:Int) = x * x
>>
>> The compiler does this:
>>
>> val square = new Function1[Int, Int] {
>>  def apply(x: Int): Int = x*x
>> }
>> "
>>
>> After this I'm just going to go with the flow, this is driving me nuts.
>>
>
>

[Jorge Ortiz-3]

And as to whether methods or Functions are more "fundamental", I guess
it depends on whether your definition of "fundamental" is "closer to
the math" or "closer to the bytecode".

--j

On Thu, Aug 14, 2008 at 6:03 PM, Jorge Ortiz <jorge.ortiz@...> wrote:

> I spent a while arguing this over lunch yesterday.
>
> My take is that there are three distinct function-like concepts in
> Scala: methods, functions, and Functions (aka function objects or
> function values).
>
> class A {
>  def foo = {
>    def bar = 3
>    val baz = (i: Int) => i + 1
>    baz(bar)
>  }
> }
>
> In this example, foo is a method, bar is a function, and baz is a
> Function/functionobject/functionvalue.
>
> We need three concepts because it doesn't make sense to call bar a
> method, nor is it a Function in the same sense that baz is a Function.
>
> --j
>
> On Thu, Aug 14, 2008 at 4:38 PM, James Iry <jamesiry@...> wrote:
>> Methods are not functions in Scala, in spite of what the book says there.
>> Methods are very primitive, distinctly not first class concepts in Scala.
>> Functions are full blown objects with all rights, privileges, and
>> responsibilities of full citizenship..
>>
>> The interpreter confuses things a bit because it appears to let you write
>> "def" at the "top level".  But it's not really the top level, you're
>> actually creating a method on a giant object that wraps all your code.  Note
>> the $iw in the error below.
>>
>> =================
>> scala> def square(x:Int) = x * x
>> square: (Int)Int
>>
>> scala> def fourth(x:Int) = (square compose square)(x)
>> <console>:6: error: missing arguments for method square in object $iw;
>> follow this method with `_' if you want to treat it as a partially applied
>> function
>>        def fourth(x:Int) = (square compose square)(x)
>>
>> =================
>>
>> Now watch as I use functions
>>
>> scala> val square2 = {x:Int => x * x}
>> square2: (Int) => Int = <function>
>>
>> scala> val fourth2 = square2 compose square2
>> fourth2: (Int) => Int = <function>
>>
>> scala> fourth2(4)
>> res0: Int = 256
>>
>> ==========================
>>
>> Scala also makes things a bit more confusing by implicitly converting to
>> functions in some cases without needing the _ syntax.
>>
>> scala> val fourth3 = square2 compose square
>> fourth3: (Int) => Int = <function>
>>
>>
>> Hopefully this has cleared everything up.
>>
>>
>>
>> On Thu, Aug 14, 2008 at 4:19 PM, Daniel Green <octoberdan@...> wrote:
>>>
>>> Thank you all for the information. One last thing...
>>>
>>> Is there a spec section or way I can prove the following wrong? If the
>>> statement is in fact wrong:
>>>
>>> "
>>> When you write :
>>>
>>> def square(x:Int) = x * x
>>>
>>> The compiler does this:
>>>
>>> val square = new Function1[Int, Int] {
>>>  def apply(x: Int): Int = x*x
>>> }
>>> "
>>>
>>> After this I'm just going to go with the flow, this is driving me nuts.
>>>
>>
>>
>

[Seth Tisue]

>>>>> "Jorge" == Jorge Ortiz <jorge.ortiz@...> writes:

 Jorge> I spent a while arguing this over lunch yesterday.  My take is
 Jorge> that there are three distinct function-like concepts in Scala:
 Jorge> methods, functions, and Functions (aka function objects or
 Jorge> function values).

 Jorge> class A { def foo = { def bar = 3 val baz = (i: Int) => i + 1
 Jorge> baz(bar) } }

 Jorge> In this example, foo is a method, bar is a function, and baz is
 Jorge> a Function/functionobject/functionvalue.

 Jorge> We need three concepts because it doesn't make sense to call bar
 Jorge> a method, nor is it a Function in the same sense that baz is a
 Jorge> Function.

Ahhhhh, the plot thickens.  In that way of talking, little-f functions
become the fundamental concept in terms of which the other two are
defined -- a method is a function which is also a member of a class.

The other way of talking, in which bar is a method, also makes sense to
me though.  Couldn't we say bar is a method which happens not to be
lexically visible throughout A?  That's how I would have described it
before reading your post.  Now, I'm not sure.

Perhaps both ways of talking are consistent and Martin should tell us
which one to use :-)

--
Seth Tisue / http://tisue.net
lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/

[Jorge Ortiz-3]

To me, "method" has always been an OOP term. Methods are methods -of-
something, but what would bar be a method of? Is it a method of class
A with a more-restrictive-than-private visibility?

--j

On Thu, Aug 14, 2008 at 6:28 PM, Seth Tisue <seth@...> wrote:

>>>>>> "Jorge" == Jorge Ortiz <jorge.ortiz@...> writes:
>
>  Jorge> I spent a while arguing this over lunch yesterday.  My take is
>  Jorge> that there are three distinct function-like concepts in Scala:
>  Jorge> methods, functions, and Functions (aka function objects or
>  Jorge> function values).
>
>  Jorge> class A { def foo = { def bar = 3 val baz = (i: Int) => i + 1
>  Jorge> baz(bar) } }
>
>  Jorge> In this example, foo is a method, bar is a function, and baz is
>  Jorge> a Function/functionobject/functionvalue.
>
>  Jorge> We need three concepts because it doesn't make sense to call bar
>  Jorge> a method, nor is it a Function in the same sense that baz is a
>  Jorge> Function.
>
> Ahhhhh, the plot thickens.  In that way of talking, little-f functions
> become the fundamental concept in terms of which the other two are
> defined -- a method is a function which is also a member of a class.
>
> The other way of talking, in which bar is a method, also makes sense to
> me though.  Couldn't we say bar is a method which happens not to be
> lexically visible throughout A?  That's how I would have described it
> before reading your post.  Now, I'm not sure.
>
> Perhaps both ways of talking are consistent and Martin should tell us
> which one to use :-)
>
> --
> Seth Tisue / http://tisue.net
> lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/
>

[Geoffrey Alan Washburn-4]

Jorge Ortiz wrote:

> I spent a while arguing this over lunch yesterday.
>
> My take is that there are three distinct function-like concepts in
> Scala: methods, functions, and Functions (aka function objects or
> function values).
>
> class A {
>   def foo = {
>     def bar = 3
>     val baz = (i: Int) => i + 1
>     baz(bar)
>   }
> }
>
> In this example, foo is a method, bar is a function, and baz is a
> Function/functionobject/functionvalue.
>
> We need three concepts because it doesn't make sense to call bar a
> method, nor is it a Function in the same sense that baz is a Function.

No, it is a method.  Firstly, if you look at the compiled output, bar
becomes a private method of A.  Secondly, the type system treats it as a
method as well.  Try changing your example to

class A {
   def foo = {
     def bar(x: Int) = 3 + x
     val baz = bar
     ()
   }
}

When you try to compile it you will get the error message:

ex.scala:4: error: missing arguments for method bar;
follow this method with `_' if you want to treat it as a partially
applied function
     val baz = bar
               ^
one error found

So for all intents and purposes, bar is a method.

[Jorge Ortiz-3]

I understand what bar gets compiled to, and I understand it's not a
function in the same sense that my original baz was a function.

My contention was that it shouldn't be called a "method" because it
kind of doesn't act like methods as we know them from OOP.

Though perhaps you're right that it should be called a method, though
with a visibility that other OOP languages don't provide:
method-private.

--j

On Thu, Aug 14, 2008 at 8:11 PM, Geoffrey Alan Washburn
<geoffrey.washburn@...> wrote:

> Jorge Ortiz wrote:
>>
>> I spent a while arguing this over lunch yesterday.
>>
>> My take is that there are three distinct function-like concepts in
>> Scala: methods, functions, and Functions (aka function objects or
>> function values).
>>
>> class A {
>>  def foo = {
>>    def bar = 3
>>    val baz = (i: Int) => i + 1
>>    baz(bar)
>>  }
>> }
>>
>> In this example, foo is a method, bar is a function, and baz is a
>> Function/functionobject/functionvalue.
>>
>> We need three concepts because it doesn't make sense to call bar a
>> method, nor is it a Function in the same sense that baz is a Function.
>
> No, it is a method.  Firstly, if you look at the compiled output, bar
> becomes a private method of A.  Secondly, the type system treats it as a
> method as well.  Try changing your example to
>
> class A {
>  def foo = {
>    def bar(x: Int) = 3 + x
>    val baz = bar
>    ()
>  }
> }
>
> When you try to compile it you will get the error message:
>
> ex.scala:4: error: missing arguments for method bar;
> follow this method with `_' if you want to treat it as a partially applied
> function
>    val baz = bar
>              ^
> one error found
>
> So for all intents and purposes, bar is a method.
>
>
>

[James Iry-2]

In Scala, classes, traits, objects and methods are "fundamental."  Functions are just a special kind of object.   Other languages might do it differently, but that's Scala's take on the subject.  That's what the spec says.  A function is an object that implements a FunctionN trait.

As to what "the math" says, it just depends on which math.  One can start with an object oriented calculus and get to Scala style functions or one can start with a functional calculus and get to something like Scala style objects.  There are good reasons to prefer one way or the other in various cases, but either one can get you consistent results.

Finally, the spec says that bar is a method  and Scala treats it that way.  It's just a method with some "peculiar" (by, say, Java standards) access rules.


object A {
   def stuff = {
          def double(x:Int) = x * 2;
          double compose double
   }
}

<console>:4: error: missing arguments for method double;
follow this method with `_' if you want to treat it as a partially applied function
 

Another important consequence is how return works - it always returns from the nearest enclosing method, not function.  That nearest enclosing method may be the nested method like double or bar.

On Thu, Aug 14, 2008 at 6:08 PM, Jorge Ortiz <jorge.ortiz@...> wrote:

And as to whether methods or Functions are more "fundamental", I guess
it depends on whether your definition of "fundamental" is "closer to
the math" or "closer to the bytecode".

--j

On Thu, Aug 14, 2008 at 6:03 PM, Jorge Ortiz <jorge.ortiz@...> wrote:
> I spent a while arguing this over lunch yesterday.
>
> My take is that there are three distinct function-like concepts in
> Scala: methods, functions, and Functions (aka function objects or
> function values).
>
> class A {
>  def foo = {
>    def bar = 3
>    val baz = (i: Int) => i + 1
>    baz(bar)
>  }
> }
>
> In this example, foo is a method, bar is a function, and baz is a
> Function/functionobject/functionvalue.
>
> We need three concepts because it doesn't make sense to call bar a
> method, nor is it a Function in the same sense that baz is a Function.
>
> --j
>
> On Thu, Aug 14, 2008 at 4:38 PM, James Iry <jamesiry@...> wrote:
>> Methods are not functions in Scala, in spite of what the book says there.
>> Methods are very primitive, distinctly not first class concepts in Scala.
>> Functions are full blown objects with all rights, privileges, and
>> responsibilities of full citizenship..
>>
>> The interpreter confuses things a bit because it appears to let you write
>> "def" at the "top level".  But it's not really the top level, you're
>> actually creating a method on a giant object that wraps all your code.  Note
>> the $iw in the error below.
>>
>> =================
>> scala> def square(x:Int) = x * x
>> square: (Int)Int
>>
>> scala> def fourth(x:Int) = (square compose square)(x)
>> <console>:6: error: missing arguments for method square in object $iw;
>> follow this method with `_' if you want to treat it as a partially applied
>> function
>>        def fourth(x:Int) = (square compose square)(x)
>>
>> =================
>>
>> Now watch as I use functions
>>
>> scala> val square2 = {x:Int => x * x}
>> square2: (Int) => Int = <function>
>>
>> scala> val fourth2 = square2 compose square2
>> fourth2: (Int) => Int = <function>
>>
>> scala> fourth2(4)
>> res0: Int = 256
>>
>> ==========================
>>
>> Scala also makes things a bit more confusing by implicitly converting to
>> functions in some cases without needing the _ syntax.
>>
>> scala> val fourth3 = square2 compose square
>> fourth3: (Int) => Int = <function>
>>
>>
>> Hopefully this has cleared everything up.
>>
>>
>>
>> On Thu, Aug 14, 2008 at 4:19 PM, Daniel Green <octoberdan@...> wrote:
>>>
>>> Thank you all for the information. One last thing...
>>>
>>> Is there a spec section or way I can prove the following wrong? If the
>>> statement is in fact wrong:
>>>
>>> "
>>> When you write :
>>>
>>> def square(x:Int) = x * x
>>>
>>> The compiler does this:
>>>
>>> val square = new Function1[Int, Int] {
>>>  def apply(x: Int): Int = x*x
>>> }
>>> "
>>>
>>> After this I'm just going to go with the flow, this is driving me nuts.
>>>
>>
>>
>

[Detering Dirk-2]

> I'm saying that this:
>
> def foo = 3
>
> is a method
>
> and this
>
> val f  = () => 3
>
> is a function
>
> coworker says no saying that it only exists in my mind.
> What's the deal?

The deal is that you're both right :-) .

It all depends on the perspective.
From the technical perspective (practice) you are right,
as David told you.

From the semantical perspective (theory) you can let your
colleague gain a lolly, as both are named callable entities
without relation to a containing instance (by e.g. a 'this' reference),
what would be a possible sign for being a 'method'.

Just my 0,02€
Det


***********************************************************************

Die Information in dieser email ist vertraulich und ist ausschließlich
für den/die benannten Adressaten bestimmt. Ein Zugriff auf diese
email durch andere Personen als den/die benannten Adressaten ist
nicht gestattet. Sollten Sie nicht der benannte Adressat sein, löschen
Sie bitte diese email.

***********************************************************************

BITMARCK Software GmbH
Paul-Klinger-Straße 15, 45127 Essen
 
Amtsgericht Essen HRB 20680
Geschäftsführer: Frank Krause, Andreas Prenneis

[daniel.green]

Thank you all so much for getting back to me with all this useful
information and explanation. Him and I are now on the same page. Allot
of the problem was communication. I'm not too good at it... ;-)

2008/8/15 Detering Dirk <Dirk.Detering@...>:

>> I'm saying that this:
>>
>> def foo = 3
>>
>> is a method
>>
>> and this
>>
>> val f  = () => 3
>>
>> is a function
>>
>> coworker says no saying that it only exists in my mind.
>> What's the deal?
>
> The deal is that you're both right :-) .
>
> It all depends on the perspective.
> From the technical perspective (practice) you are right,
> as David told you.
>
> From the semantical perspective (theory) you can let your
> colleague gain a lolly, as both are named callable entities
> without relation to a containing instance (by e.g. a 'this' reference),
> what would be a possible sign for being a 'method'.
>
> Just my 0,02€
> Det
>
>
> ***********************************************************************
>
> Die Information in dieser email ist vertraulich und ist ausschließlich
> für den/die benannten Adressaten bestimmt. Ein Zugriff auf diese
> email durch andere Personen als den/die benannten Adressaten ist
> nicht gestattet. Sollten Sie nicht der benannte Adressat sein, löschen
> Sie bitte diese email.
>
> ***********************************************************************
>
> BITMARCK Software GmbH
> Paul-Klinger-Straße 15, 45127 Essen
>
> Amtsgericht Essen HRB 20680
> Geschäftsführer: Frank Krause, Andreas Prenneis
>
>