add lazy parameters

[scabug]

For now, we only have call-by-name parameters. We should allow the lazy modifier on parameters, for instance:

def f[a](lazy t: a) = {
 ..
}

The meaning should be equivalent to:

def f[a](t': => a) = {
  lazy val t: a = t'
  ..
}

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-240?orig=1
Reporter: @dragos
Attachments:

• lazy-parameters.patch (created on Nov 3, 2010 10:55:29 AM UTC, 4075 bytes)

[scabug]

@lrytz said:
see also #720

[scabug]

Matthew Pocock (drdozer) said:
I think someone in IRC said that someone else had a patch that provided a prototype of this functionality. Is this right, or am I confused by hear-say?

Either way, I would like to help out if I can with implementing this. My particular use-case is in building lazy, infinite case-class structures such as this rather boring one:

case class Foo(lazy data: Foo)

I presume that any patch that adds lazy function parameters would out of the box, or with minor tweaking, support this also.

[scabug]

@hubertp said:
Since I handled the previous lazy val bugs I will try to fix that one as well in my spare time.

[scabug]

Matthew Pocock (drdozer) said:
What would the semantics of lazy constructor arguments be on pattern matching?

case class Foo(lazy data: Foo)

foo match {
case Foo(data) => // forces evaluation of lazy data
case Foo(_) => // has data been evaluated here? I hope not!
}

The second case needs to not evaluate data. If it does, then it will be impossible to pattern-match against (portions of) infinite data structures.

[scabug]

@jrudolph said:
I gave it a try:

jrudolph/scala-starrless@65052ce

It's still rough:

• Works only for def parameters
• (as suggested) introduces a new name for the parameter, which is the easiest way but not the best when thinking of named parameters
• No error condition checking, like mixing of lazy/by-name

[scabug]

@jrudolph said:
The preliminary version of the patch

[scabug]

@paulp said:
For completeness, see also duplicate #5244.

[scabug]

@paulp said:
Oh, I guess I'm not used to jira doing something useful. Automatically generated bidirectional links? What's next, useable search? A comment system which exceeds telegard in sophistication? The mind reels.

[scabug]

Ryan Hendrickson (ryan.hendrickson_bwater) said:
Does anything block somebody productively championing this (writing a SIP, updating the patch, delivering an impassioned plea to Martin, waiting for Martin to finish x other things so that he has time to consider this class of thing)?

Additional desired syntax, if this is supported in (primary) constructors:

class Stuff([[mods]] lazy val a: Int, [[mods]] def b: Int)

translating to (modulo named-argument issues):

class Stuff(a': => Int, b': => Int) {
  [[mods]] lazy val a: Int = a'
  [[mods]] def b: Int = b'
}

[scabug]

@retronym said:
Shaking out the corner cases would be the first step.

To get the ball rolling: what would be expected here?

def foo(lazy a: Int)(b: Int = a) { a }
foo({println("!"); 0})()

[scabug]

Matthew Pocock (drdozer) said (edited on May 2, 2013 9:07:32 PM UTC):
Leaving aside for a moment that default values don't make sense in anonymous functions, I'd expect these two to be (operationally) semantically equivalent modulo currying:

def foo(lazy a: Int)(b: Int = a) { println("<") ; a; println(">") }
def bar(lazy a: Int): (Int) => Unit = (b: Int = a) => {println("<") ; a; println(">"); ()}

With the 'evaluate on first de-reference' semantics of lazy, I'd expect this to run as follows:

foo({println("!"; 42})()
| !<>
foo({println("!"; 42})(13)
| <!>

However, I'd see an argument for excluding lazy arguments from default values lists, as this least-surprise semantics will require some fancy re-writes that I can't imagine how to get right in the presence of currying.

[scabug]

Ryan Hendrickson (ryan.hendrickson_bwater) said:
Why is that hard to get right? Just as

def foo(a: Int)(b: Int = a) { ... }

foo(effectfulCode)()

rewrites to (I forget the exact mangling, but roughly)

def foo(a: Int)(b: Int) { ... }
def foo$default2(a: Int): Int = a

val x$1: Int = effectfulCode
foo(x$1)(foo$default2(x$1))

, I would expect

def foo(lazy a: Int)(b: Int = a) { ... }

foo(effectfulCode)()

to rewrite to

def foo(a: => Int)(b: Int) { ... }
def foo$default2(a: => Int): Int = a

lazy val x$1: Int = effectfulCode
foo(x$1)(foo$default2(x$1))

Wouldn't that have the desired semantics?

[scabug]

@retronym said:
Given that to make make that case work, we have to perform the rewriting at the call site, should we do it there in all cases? One disadvantage: changing => A to lazy A would require recompilation of client code (although it would appear to be binary compatible.)

We've been burned so often by unforseen (although not unforseeable) feature interactions (think Value Classes). So I'm naturally cautious with this sort of thing.

[scabug]

Ryan Hendrickson (ryan.hendrickson_bwater) said:
Not sure what you mean by ‘do it there in all cases’; my assumption was that any time we would rewrite the call site to use vals to capture arguments, if the parameter in question was marked lazy, we'd capture its argument with a lazy val instead. Did you have additional cases in mind?

It is a good point about the binary-but-not-really compatibility of a function taking => A and a function taking lazy A, but only if there are subsequent parameter lists and default arguments. My low-confidence guess is that practically, it wouldn't cause real issues that often—I at least am pretty used to having to recompile all client code regardless of the binary compatibility of dependencies, given how implicit resolution might change—but I defer to your experience.