when to () and when not to ()

On Fri, Oct 1, 2010 at 3:42 PM, HamsterofDeath wrote:
>  i read somewhere that  method that has side effects but o parameters
> should be declared with an empty parameter list, like this:
> def changesSomething()
>
> but what exactly is the definition of side effect?
>
>

I believe the recommendation is that when you invoke a method with
side effects, you put the () on the end of the method call. You need
to put the empty () for a method declaration no matter whether it has
side effects or not.

A side effect means that the method modifies something outside of its
input parameters. It could be a global variable, modifying files,
displaying a message box on screen, etc.... So
def writeSomethingToLog() : Unit = {
var writer : java.io.FileWriter = new java.io.FileWriter("log.txt");
writer.write("Message");
writer.close(); }
Tries to write to a file, so it has a side effect.

On the other hand something like toString, which just returns a String
representation of the Object, has no side effect.

Does that help?
-Mike

Changes in global or object state are considered to be side effects.
Functions with no side effects do not change any variables outside
their local scope and simply return a value.

object Test {
private var count = 0
def increment() = { count += 1; count } // side effects
def nextCounter() = counter + 1 // no side effects
def counter = count // simple "getter"
}

I think, the general rule is to declare "getters" as functions with no
parameter list and add an empty parameter list () in all other cases.

On Fri, Oct 1, 2010 at 3:42 PM, HamsterofDeath wrote:
>  i read somewhere that  method that has side effects but o parameters
> should be declared with an empty parameter list, like this:
> def changesSomething()
>
> but what exactly is the definition of side effect?
>
>

In my mind, side-effects also include reading a mutable variable outside the local scope of the function. I usually think of "no side-effects" as meaning: calling the same method, with the same parameters (including the implicit 'this' parameter, if you will), will result in the same value every single time.

In the counter example given, I would say all of those methods have side-effects, since the results of all the calls change depending on the order in which they are called.

- Colin

Just to check if I got it.
You are saying that the following case has side effects because
"counter" can be modified outside of the method scope?

def nextCounter() = counter + 1 // no side effects

Giba

On Fri, Oct 1, 2010 at 5:23 PM, Colin Bullock wrote:
> In my mind, side-effects also include reading a mutable variable outside the
> local scope of the function. I usually think of "no side-effects" as
> meaning: calling the same method, with the same parameters (including the
> implicit 'this' parameter, if you will), will result in the same value every
> single time.
>
> In the counter example given, I would say all of those methods have
> side-effects, since the results of all the calls change depending on the
> order in which they are called.
>
> - Colin
>

A function is side-effecting if it is not referentially transparent.
http://projects.tmorris.net/public/what-does-fp-mean/artifacts/0.3/chunk...

Also, I am of the opinion that such advice is bogus and often
contraindicated.

On 02/10/10 05:42, HamsterofDeath wrote:
> i read somewhere that method that has side effects but o parameters
> should be declared with an empty parameter list, like this:
> def changesSomething()
>
> but what exactly is the definition of side effect?
>
>
>

@Colin Bullock:

I think you are confusin the concept of "referential transparency"
with "no side effects".

On Fri, Oct 1, 2010 at 4:23 PM, Colin Bullock wrote:
> In my mind, side-effects also include reading a mutable variable outside the
> local scope of the function. I usually think of "no side-effects" as
> meaning: calling the same method, with the same parameters (including the
> implicit 'this' parameter, if you will), will result in the same value every
> single time.
>
> In the counter example given, I would say all of those methods have
> side-effects, since the results of all the calls change depending on the
> order in which they are called.
>
> - Colin
>

 You need to put the empty () for a method declaration no matter whether it has
side effects or not.

Sorry to say that's not correct. There is no requirement to include the empty parenthesis in a method declaration. This class compiles and runs just fine.
class Example(a: String) {   def m1 = a;   def m2() = a }
--
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
bschlining@gmail.com

I go by the "if it works like a property, you can leave of the parenthesis" rule
This is how `var` already works, it's actually a method, the returned value can change between successive calls, and you can override a def with a var.
So if successive calls will always return the same value *in the absence of any other intervening operations* and the method does not, itself, mutate any state, then leave the thing unadorned :)


On 1 October 2010 22:03, Tony Morris <tonymorris@gmail.com> wrote:

A function is side-effecting if it is not referentially transparent.
http://projects.tmorris.net/public/what-does-fp-mean/artifacts/0.3/chunk-html/ar01s04.html

Also, I am of the opinion that such advice is bogus and often
contraindicated.

On 02/10/10 05:42, HamsterofDeath wrote:
>  i read somewhere that  method that has side effects but o parameters
> should be declared with an empty parameter list, like this:
> def changesSomething()
>
> but what exactly is the definition of side effect?
>
>
>

--
Tony Morris
http://tmorris.net/

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

i tried to use the rule
"the this method call will not change any existing value, it has no side effect". it is allowed to create new stuff as is pleases.
however, what about this:
class CachedValue[T](f: () => T, step:Int = 1) {
  private var v: T = null.asInstanceOf[T]

  def value() = {
    if (v == null) {
      v = f()
    }
    v
  }

  def invalidate() {
    v = null.asInstanceOf[T]
  }
}

invalidate has a side effect, which is clear. value also has one, but the caller is supposed to think of value as a simple property. so, should it have () or not?

Am 01.10.2010 23:32, schrieb Kevin Wright:

AANLkTikhhxWvf2EDqXOJAonb3kTkycsUTeRhp3WSMw39 [at] mail [dot] gmail [dot] com" type="cite">I go by the "if it works like a property, you can leave of the parenthesis" rule
This is how `var` already works, it's actually a method, the returned value can change between successive calls, and you can override a def with a var.
So if successive calls will always return the same value *in the absence of any other intervening operations* and the method does not, itself, mutate any state, then leave the thing unadorned :)


On 1 October 2010 22:03, Tony Morris <tonymorris [at] gmail [dot] com" rel="nofollow">tonymorris@gmail.com> wrote:

A function is side-effecting if it is not referentially transparent.
http://projects.tmorris.net/public/what-does-fp-mean/artifacts/0.3/chunk-html/ar01s04.html

Also, I am of the opinion that such advice is bogus and often
contraindicated.

On 02/10/10 05:42, HamsterofDeath wrote:
>  i read somewhere that  method that has side effects but o parameters
> should be declared with an empty parameter list, like this:
> def changesSomething()
>
> but what exactly is the definition of side effect?
>
>
>

--
Tony Morris
http://tmorris.net/

--
Kevin Wright

mail / gtalk / msn : kev [dot] lee [dot] wright [at] gmail [dot] com" target="_blank" rel="nofollow">kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

On Sat, Oct 2, 2010 at 2:54 AM, HamsterofDeath <h-star@gmx.de> wrote:

i tried to use the rule
"the this method call will not change any existing value, it has no side effect". it is allowed to create new stuff as is pleases.
however, what about this:
class CachedValue[T](f: () => T, step:Int = 1) {
  private var v: T = null.asInstanceOf[T]

  def value() = {
    if (v == null) {
      v = f()
    }
    v
  }

  def invalidate() {
    v = null.asInstanceOf[T]
  }
}

I'd say this is a matter of personal preference.  If you are looking for inspiration, note that lazy vals work approximately like this, and they don't take (), so this suggests a lack of () for value.  Invalidate does change state, so there I'd leave the () on.

But one could equally well argue that since f is pretty useless unless it changes state, and it doesn't get called until you hit value, that it should be value().

Or you could argue that it doesn't matter, since what is going on is complicated at the class level, not at the method level.

  --Rex

P.S. Because of issues like these, and because in the absence of compiler-forced guarantees people are liable to get sloppy about ()-placement or not think through what is or is not state-changing, I'm likely to agree with Tony about the bogosity potential of the ()-use custom.  If it helps you out, great.  If not, no worries.

P.P.S. Argh:

def f[A <: { def value: Int }](a: A) = a.value
def g[B <: { def value(): Int}](b: B) = b.value
class C { def value() = 1 }
class D extends C { override def value = 2 }
class E extends C { override val value = 3 }
class F { def value = 4 }
class G extends F { override def value() = 5 }
class H extends G { override def value = 6 }

f(new C)  // fails
g(new C)

f(new D)  // fails?!
g(new D)

f(new E)  // succeeds??!
g(new E)  // fails ??!?!

f(new F)
g(new F)  // fails

f(new G)  // fails?!
g(new G)

f(new H)  // fails??!?!
g(new H)

Caching is generally taken, by convention, to not be a side effect.
Perhaps the most obvious precedent for this is the lazy vals that Scala already has available...



On 2 October 2010 07:54, HamsterofDeath <h-star@gmx.de> wrote:

i tried to use the rule
"the this method call will not change any existing value, it has no side effect". it is allowed to create new stuff as is pleases.
however, what about this:
class CachedValue[T](f: () => T, step:Int = 1) {
  private var v: T = null.asInstanceOf[T]

  def value() = {
    if (v == null) {
      v = f()
    }
    v
  }

  def invalidate() {
    v = null.asInstanceOf[T]
  }
}

invalidate has a side effect, which is clear. value also has one, but the caller is supposed to think of value as a simple property. so, should it have () or not?

Am 01.10.2010 23:32, schrieb Kevin Wright:

I go by the "if it works like a property, you can leave of the parenthesis" rule
This is how `var` already works, it's actually a method, the returned value can change between successive calls, and you can override a def with a var.
So if successive calls will always return the same value *in the absence of any other intervening operations* and the method does not, itself, mutate any state, then leave the thing unadorned :)


On 1 October 2010 22:03, Tony Morris <tonymorris@gmail.com> wrote:

A function is side-effecting if it is not referentially transparent.
http://projects.tmorris.net/public/what-does-fp-mean/artifacts/0.3/chunk-html/ar01s04.html

Also, I am of the opinion that such advice is bogus and often
contraindicated.

On 02/10/10 05:42, HamsterofDeath wrote:
>  i read somewhere that  method that has side effects but o parameters
> should be declared with an empty parameter list, like this:
> def changesSomething()
>
> but what exactly is the definition of side effect?
>
>
>

--
Tony Morris
http://tmorris.net/

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

Brian Schlining wrote on 2.10.2010 0:04:
> Sorry to say that's not correct. There is no requirement to include the
> empty parenthesis in a method declaration. This class compiles and runs
> just fine.
>
> class Example(a: String) {
> def m1 = a;
> def m2() = a
> }

I've noticed that sometimes the Scala compiler requires the caller of a
method to use or not use (), depending on whether the method was
declared with or without (). But sometimes the compiler is not enforing
it. In which situations does the compiler do this check?

On Sat, Oct 2, 2010 at 10:41 AM, Esko Luontola <esko.luontola@gmail.com> wrote:

I've noticed that sometimes the Scala compiler requires the caller of a method to use or not use (), depending on whether the method was declared with or without (). But sometimes the compiler is not enforing it. In which situations does the compiler do this check?

As far I know, if the method declares an empty argument list you can use or not use () when you call it, but if the method don't declare an argument list you can't use () when calling it
scala> def m() = 1m: ()Int
scala> mres0: Int = 1
scala> m()res1: Int = 1
scala> def m = 1 m: Int
scala> mres2: Int = 1
scala> m()<console>:7: error: m of type Int does not take parameters       m()
and the possibility to not use () in a call of a method with an empty parameter list is primarly for java compatibility, which force you to always declare an argument list, so you can call java methods without using ().
I personally don't use the "side efect" rule... I omit the () as much I can.
Regards,Germán

On Sat, Oct 2, 2010 at 11:32 AM, Germán Ferrari <german.ferrari@gmail.com> wrote:

scala> def m = 1 m: Int
scala> mres2: Int = 1
scala> m()<console>:7: error: m of type Int does not take parameters       m()

And yet:

scala> m _
res3: () => Int = <function0>

Argh.  I guess it does take parameters (i.e. an empty parameter list) now....

  --Rex

On Sat, Oct 02, 2010 at 11:50:39AM -0400, Rex Kerr wrote:
> scala> m _
> res3: () => Int =
>
> Argh. I guess it does take parameters (i.e. an empty parameter list)
> now....

I take it from "Argh" you see this as a bad thing, but without it you
couldn't do this:

scala> val f = 5
f: Int = 5

scala> f _
res0: () => Int =

(Of course given that example you could be forgiven for thinking "big
loss" but where I live 5 moves around all the time.)

The distinctions and corner cases in large part arise from the desire to
be able to override a def with a val, a useful thing.

I realize as I write this that that parameterless defs and by-name
parameters are two sides of a coin.

normal def: a name + function application
parameterless def: a name (function application is implied)
by name parameter: a function application (name is implied)

Neither of the latter two exists as a first-class construct. If you
want to work with either one as a value, then it has to be turned into
something which is. Neatly enough, they transform into the same thing,
Function0.

The elephant in the room here is Java interop (isn't it always?)
Because Java methods *always* have a param list, Scala is able to call such empty-listed methods as though they had none.Just be careful if you use structural typing, you have to leave the empty list in there if the type is to match methods declared in java-land

On 2 October 2010 16:50, Rex Kerr <ichoran@gmail.com> wrote:

On Sat, Oct 2, 2010 at 11:32 AM, Germán Ferrari <german.ferrari@gmail.com> wrote:

scala> def m = 1 m: Int
scala> mres2: Int = 1
scala> m()<console>:7: error: m of type Int does not take parameters       m()

And yet:

scala> m _
res3: () => Int = <function0>

Argh.  I guess it does take parameters (i.e. an empty parameter list) now....

  --Rex

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

I personally don't use the "side efect" rule... I omit the () as much I can.

Just FYI, the "side effect" rule is a common idiom in functional programming. For example, in Clojure, method names that exist primarily for their side-effects will end with "!". I think Lift adopted the "!" idiom too. 
--
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
bschlining@gmail.com

While we're rummaging through the cases in the corner of the room...

Primary class constructors must have at least one, non-implicit
parameter section. If omitted, it is added by the compiler.

scala> implicit val s = ""
s: java.lang.String =

scala> class A(implicit a: String)
defined class A

scala> new A("")
:8: error: too many arguments for constructor A: ()(implicit
a: String)A
new A("")
^

scala> new A()
res9: A = A@21c75cff

scala> new A()("")
res10: A = A@2babbba1

scala> new B
res13: B = B@17d5176d

scala> new B()
res14: B = B@bb277f0

scala> class C()
defined class C

scala> new C
res15: C = C@6770526a

scala> new C()
res16: C = C@22f42d53

The same restriction applies to auxiliary constructors, but the empty
parameter list isn't inferred.

scala> class D(e: Any) { def this = this(()) }
:1: error: auxiliary constructor needs non-implicit parameter list
class D(e: Any) { def this = this(()) }

-jason

On Sat, Oct 2, 2010 at 6:10 PM, Kevin Wright wrote:
> The elephant in the room here is Java interop (isn't it always?)
> Because Java methods *always* have a param list, Scala is able to call such
> empty-listed methods as though they had none.
> Just be careful if you use structural typing, you have to leave the empty
> list in there if the type is to match methods declared in java-land

my experience says: there is no exception. can you provide one?

Am 02.10.2010 15:41, schrieb Esko Luontola:
> Brian Schlining wrote on 2.10.2010 0:04:
>> Sorry to say that's not correct. There is no requirement to include the
>> empty parenthesis in a method declaration. This class compiles and runs
>> just fine.
>>
>> class Example(a: String) {
>> def m1 = a;
>> def m2() = a
>> }
>
> I've noticed that sometimes the Scala compiler requires the caller of
> a method to use or not use (), depending on whether the method was
> declared with or without (). But sometimes the compiler is not
> enforing it. In which situations does the compiler do this check?
>

On Sat, Oct 2, 2010 at 1:45 PM, Brian Schlining <bschlining@gmail.com> wrote:

Just FYI, the "side effect" rule is a common idiom in functional programming. For example, in Clojure, method names that exist primarily for their side-effects will end with "!". I think Lift adopted the "!" idiom too. 

Thank you for the data. I have used that idiom previously but in my cases it wasn't that helpfull. After reading the link posted by Tony Morris, I'm thinking that in a more functional style it could be much more significative...
Regards,Germán

On Sat, Oct 2, 2010 at 8:41 AM, Esko Luontola <esko.luontola@gmail.com> wrote:

I've noticed that sometimes the Scala compiler requires the caller of a method to use or not use (), depending on whether the method was declared with or without (). But sometimes the compiler is not enforing it. In which situations does the compiler do this check?

The rule is that if the method is defined with (), it's optional at the call site. if it's defined without (), it's prohibited at the call site.

On Sat, Oct 2, 2010 at 12:08 PM, Paul Phillips <paulp@improving.org> wrote:

On Sat, Oct 02, 2010 at 11:50:39AM -0400, Rex Kerr wrote:
> scala> m _
> res3: () => Int = <function0>
>
> Argh.  I guess it does take parameters (i.e. an empty parameter list)
> now....

I take it from "Argh" you see this as a bad thing, but without it you
couldn't do this:

scala> val f = 5
f: Int = 5

scala> f _
res0: () => Int = <function0>

(Of course given that example you could be forgiven for thinking "big
loss" but where I live 5 moves around all the time.)

Sure, that's useful, except I would expect res0: => Int.

The argh is from a standpoint of conceptual purity.  If zero-parameter-list and one-empty-parameter-list methods were always equivalent, I wouldn't mind.  If they were never equivalent I would also not mind.  But it seems that there's a strange mix of equivalence and not.  This manifests most annoyingly in my PPS to an earlier message--structural typing has some very odd ideas about equivalence of empty parameter lists.  (Yes, I can come up with a few simple rules that predict all behaviors, but that's not the same as it intuitively making sense.)
 

The distinctions and corner cases in large part arise from the desire to
be able to override a def with a val, a useful thing.

Agreed, but how is this not served by saying that zero-argument-list and one-empty-argument-list methods are _exactly the same thing_, but if you have a val you may not use () because it's not a method (not because it's a zero-argument-list method)?
 

I realize as I write this that that parameterless defs and by-name
parameters are two sides of a coin.

 normal def: a name + function application
 parameterless def: a name (function application is implied)
 by name parameter: a function application (name is implied)

Neither of the latter two exists as a first-class construct.  If you
want to work with either one as a value, then it has to be turned into
something which is.  Neatly enough, they transform into the same thing,
Function0.

The question is why the latter two should exist at all, given that the normal def (and the corresponding Function0) can do everything, and if they should, why they shouldn't be first-class constructs.

For example, to make them first class, one could say that a class with def apply = xyz will return xyz whenever the class is named; myClass.this would always be a stable way to refer to the class itself instead of the apply of the class.  To remove them from partial-class status, just say that vals and by-name parameters are purely syntactic sugar to say that you don't need to put () to get the value out, and always allow a method f() to be called as f (which we already have) and vice versa (which we don't), and then drop any further distinctions (e.g. with structural typing).

  --Rex

P.S. Kevin - I do understand that Java will have to view zero parameter lists and one empty parameter list (and forty-five empty parameter lists, for that matter) as the same thing, unless name mangling is introduced.  But that doesn't mean that Scala has to be quite as internally inconsistent as it is (though despite inconsistency the present behavior does work well in most cases).

Lift appends _! to methods that should be used with a lot of care taken.

On Sat, Oct 2, 2010 at 5:17 PM, Germán Ferrari <german.ferrari@gmail.com> wrote:

On Sat, Oct 2, 2010 at 1:45 PM, Brian Schlining <bschlining@gmail.com> wrote:

Just FYI, the "side effect" rule is a common idiom in functional programming. For example, in Clojure, method names that exist primarily for their side-effects will end with "!". I think Lift adopted the "!" idiom too. 

Thank you for the data. I have used that idiom previously but in my cases it wasn't that helpfull. After reading the link posted by Tony Morris, I'm thinking that in a more functional style it could be much more significative...
Regards,Germán

On 01/10/2010 22:06, Lex wrote:
> Changes in global or object state are considered to be side effects.
> Functions with no side effects do not change any variables outside
> their local scope and simply return a value.

So a function doing I/O without altering variables (eg. with a simple println) is seen as
no side effect if it returns something?
Or is the Console seen as a variable being altered?

Does there have to be one right answer?

On Mon, Oct 4, 2010 at 4:19 AM, Philippe Lhoste <PhiLho@gmx.net> wrote:

On 01/10/2010 22:06, Lex wrote:

Changes in global or object state are considered to be side effects.
Functions with no side effects do not change any variables outside
their local scope and simply return a value.

So a function doing I/O without altering variables (eg. with a simple println) is seen as no side effect if it returns something?
Or is the Console seen as a variable being altered?

Yes, and it's Haskell ;-)

On Mon, Oct 4, 2010 at 11:42 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

Does there have to be one right answer?

On Mon, Oct 4, 2010 at 4:19 AM, Philippe Lhoste <PhiLho@gmx.net> wrote:

On 01/10/2010 22:06, Lex wrote:

Changes in global or object state are considered to be side effects.
Functions with no side effects do not change any variables outside
their local scope and simply return a value.

So a function doing I/O without altering variables (eg. with a simple println) is seen as no side effect if it returns something?
Or is the Console seen as a variable being altered?

On 04/10/10 22:42, Naftoli Gugenheim wrote:
> Does there have to be one right answer?

Well, I don't think it's useful to strictly enforce any particular approach.
I prefer not to think of it so much in terms of the method producing a side
effect as the method appearing like a property.

If I add a logging statement to a parenthesisless method, I wouldn't change
the signature to have parentheses. Conversely, if I write a method which is
perfectly pure, but does some Herculean calculation, churning through fifty
rounds of garbage collection in the process, then I'm going to give it
parentheses.

Jon

>>>>> "Jon" == Jon Pretty <_@scala.propensive.com> writes:

Jon> Well, I don't think it's useful to strictly enforce any particular
Jon> approach. I prefer not to think of it so much in terms of the
Jon> method producing a side effect as the method appearing like a
Jon> property.

Jon> If I add a logging statement to a parenthesisless method, I
Jon> wouldn't change the signature to have parentheses. Conversely, if
Jon> I write a method which is perfectly pure, but does some Herculean
Jon> calculation, churning through fifty rounds of garbage collection
Jon> in the process, then I'm going to give it parentheses.

+1