puzzle suggestion number 8

[kiritsuku]

Hope you like it.

btw, at the beginning of line 6 of pzzlr-template there is an apostrophe. Is this purposed?

[dgruntz]

Regarding Puzzle #8: One could add in the explanation part a note, that a for-comprehension could/should be used, because the variable which is used in the for-expression is immutable (i.e. a val):

for(i <- 0 to 2) { funcs += (() => values(i)) }

and obviously, this could be simplified to

for(v <- values) { funcs += (() => v) }

Both variants print the expected result.

[kiritsuku]

Nice to mention the point with immutable values but I don't think it is useful to mention for-comprehensions here because the expected behavior could achieved in a lot of ways, e.g. with a foldLeft.

On Tue 22 May 2012 10:03:55 PM CEST, dgruntz wrote:

Regarding Puzzle #8: One could add in the explanation part a note, that a for-comprehension could/should be used, because the variable which is used in the for-expression is immutable (i.e. a val):

for(i<- 0 to 2) { funcs += (() => values(i)) }

and obviously, this could be simplified to

for(v<- values) { funcs += (() => v) }

Both variants print the expected result.

---

Reply to this email directly or view it on GitHub: https://github.com/scalapuzzlers/scalapuzzlers.github.com/pull/14#issuecomment-5857277

[demobox]

Hi Simon!

Thanks for your submissions! Been a busy few weeks, hence the delay in responding ;-)

Both puzzlers are nice; just a couple of comments/minor changes that we would suggest.

For puzzler 8

Agree that the difference between Scala's treatment of "val capture" vs. "var capture" is surprising if you don't know about it. We would just like to make the difference a bit more explicit in the sample code: perhaps something like:

val values = List(100, 110, 120)
val funcs1 = collection.mutable.Buffer[() => Int]()
val funcs2 = collection.mutable.Buffer[() => Int]()
var j = 0
for (i <- 0 until values.length) {
 funcs1 += (() => values(i))
 funcs2 += (() => values(j))
 j += 1
}

funcs1.foreach { f1 => println(f1()) }
funcs2.foreach { f2 => println(f2()) }

I think that makes the user think more about the possible difference.

For puzzler 9

Like it, although I would like to the example to something like:

val xs = Seq(Seq("a", "b", "c"), Seq("d", "e", "f"), Seq("g", "h"), Seq("i", "j", "k"))

val ys = for (Seq(x, y, z) <- xs) yield x + y + z
val zs = xs map { case Seq(x, y, z) => x + y + z }

and the answers to

1. Both result in a MatchError

ys: List(abc, def, ijk)
zs: List(abc, def, ijk)

1. Evaluating ys results in a MatchError, zs evaluates to

zs: List(abc, def, ijk)

1. ys evaluates to

ys: List(abc, def, ijk)

evaluating zs results in a MatchError

Couple of reasons:

• Feel Seq is more common than Array, but could be wrong ;-)
• Don't see the need for the concise but complicated creation of xs. That's not where the puzzler is
• Reformulated the answers to match the style of the others and to keep the order of ys and zs consistent in the answers

Thoughts? Comments?

[kiritsuku]

Feel Seq is more common than Array, but could be wrong ;-)

Maybe List is even better?

Don't see the need for the concise but complicated creation of xs. That's not where the puzzler is

Yeah, that's true. This is unnecessary overhead.

Reformulated the answers to match the style of the others and to keep the order of ys and zs consistent in the answers

Ok, this can be useful.

I think that makes the user think more about the possible difference.

Yes, but it is also easier to recognize what is going on. ;)

[demobox]

Thanks for the feedback. I originally used List but Nermin thought Seq was even more common ;-) @nermin ?

[nermin]

I generally tend to use Seq for simple collections, but List is totally fine.

[demobox]

Thanks for the fixes - was just about to prepare a patch to send to you. And thanks for catching my mistake of having Seq in the sample code and List in the answers ;-)

Good to go, I'd say!