Accumulate: Add tests for mutability/immutability

[booniepepper]

Accumulate is an exercise that uses higher order functions to perform a map/transform/etc operation on an input list.

In some languages I've seen solutions that mutate the input list as part of their solution. (Some languages like Haskell can't have this problem, but C, Go, Common Lisp, etc certainly can)

Is it possible to add an optional test across the board for "input list is not mutated"?

[coriolinus]

Why is this property desirable? Wouldn't the opposite property be better: guarantee that implementations mutate the input, for minimal allocation? Given that property, implementations which need to retain access to the original list can simply clone it before handing it to the accumulate function.

[joshgoebel]

My language knowledge may not be broad enough but every map implementation I've used does NOT mutate the input - nor would I expect it to, it provides a copy... I would expect I differently named method if what I was doing was mutating. I've also never read the exercise (in all my mentoring experience) to imply or suggest mutation.

So I vote for a test that guarantees non-mutation.

This is a pretty simple exercise though so if it was expanded to have a mutateMap with associated tests that could be a good addition.

[SleeplessByte]

.map doesn't "mutate" but I've seen people do this:

const items = [1, 2, 3]

items.map((item, index) => {
  items[index] = item * 2
})

return items

This works.

[joshgoebel]

Sure you can use map to mutate, just pointing out that's not it's standard behavior - at least in languages I'm familiar with.

[SleeplessByte]

I was just indicating that you can use map to mutate ;)

[booniepepper]

I think the trend these days is to favor immutable data over mutable data, (as an optimization for humans and the ability to reason about code) but @coriolinus brings up a good point that it's not optimal from a memory use perspective, and there probably are tracks where mutation is expected.

@SleeplessByte brought up in the friday meeting that I can send a pull request for both ways and leave it up to track maintainers which makes sense to implement.

I'll update the issue title to indicate this is more about reducing ambiguity for students and mentors and put together a PR when I make the time

[joshgoebel]

and there probably are tracks where mutation is expected. ... that I can send a pull request for both ways and leave it up to track maintainers

I hadn't even considered that... I could certainly imagine some languages where the expectation might be entirely different. Letting track maintainers decide which makes sense per languages sound like a winner.

[junedev]

Sidenote: There was a decision to deprecate accumulate here https://github.com/exercism/problem-specifications/issues/129 because it is part of list-ops, it just wasn't actually done in the end for whatever reason. It the deprecation is picked up again, it would be better to have the mutate vs. don't mutate discussion/ improvements for list-ops instead.