Implement Robot Simulator

[IanWhitney]

Implement Robot Simulator

This follows the current standard test suite

The stub file, as we discussed in #117, is just enough to run cargo test and not get any errors from ignored tests.

[jonasbb]

I would pre-fill the functions with unimplemented!() just to make sure, that you know where to put the implementation. This is more important for functions which return values, because unimplemented!() always typechecks, no matter the type.

[IanWhitney]

Cool. Done. Thanks!

[jonasbb]

Your test suite will push them to a certain solution in any case. If you set mut it is more likely to change the state of the struct, but if you remove mut and return a new struct, you need to adapt your test cases to support this.

[IanWhitney]

Ah, right, if I remove the mut then the signature would change to

fn turn_right(&self) -> Self {
  Robot::New{...}
}

Which might be interesting. I don't think any of our exercises take that approach.

[IanWhitney]

Two tweaks:

• Stub & Tests now use immutable robots.
• I'm silencing some warnings

[IanWhitney]

I'm unsure what the direction function should return -- Direction or &Direction?

Currently the Robot new function uses &Direction, which makes sense to me. Students can choose to handle the lifetimes that come with a struct using a borrowed reference, or they can derive Clone and just clone the Direction. That works for me.

But when getting the Direction back out, what is the idiomatic thing to do? My instinct says that the function should be

fn direction(&self) -> &Direction

But my instinct has been wrong a lot.

[steveklabnik]

usually, accessor methods return &T. If they returned T, then they would destroy the owner, or you'd be making a clone every time.

[IanWhitney]

Ooh, my instinct was right for once. Go team instinct! 👏

[IanWhitney]

What about primitives, @steveklabnik ?

For example, given the struct

struct Robot {
  x: isize,
  y: isize
}

Would you expect a position function to be:

fn postion(&self) -> (isize, isize)

or

fn postion(&self) -> (&isize, &isize)

Alternatively we could create a whole new Position type, like we did with queen attack

[steveklabnik]

If the type is Copy, then they're basically the same, so yeah, returning T is fine. Consider http://doc.rust-lang.org/stable/collections/vec/struct.Vec.html#method.len as an example

[IanWhitney]

That's what I was thinking as well. I'm clearly on a roll today.

[Dr-Emann]

Taking by value and returning a copy just doesn't feel rusty-y to me. I expect functions to take the most general type of arguments they can, &T if no mutation, &mut T if mutation needed, and T only if ownership is required.

[IanWhitney]

Working example in place. Now to figure out where to place this problem.

The solution will involve:

• Enums (though the stub file provides them)
• Structs (either a tuple struct, or a normal struct)
• Some matching on Direction variant
• Iteration

And, if the student chooses not to clone the Direction, they may end up in a world of Lifetimes. That, though, is optional.

I'm thinking it should go around grade-school. It's got a pretty straightforward use of enums, so it should come before Allergies (which has slightly more complex enum usage). But beyond enums, students will be familiar with all the tools they need to solve this by the time they reach grade-school

[IanWhitney]

So what API are you proposing, @Dr-Emann?

[Dr-Emann]

I would expect turn_right, turn_left, advance, and instructions to take &mut self, instead of self, and return nothing.

[IanWhitney]

That was the initial implementation. And it might be the right one. But I'm leaning towards immutable because

• Immutability is the default in Rust
• No other problem (that I know of) really features Rust's default immutability
• Immutability is not my natural inclination

I figure if I don't expect immutability then other programmers with an OO-focused background probably don't expect immutability. So a problem that forces immutability may make me (and them) think about immutability. Which I think is good.

Immutability brings other benefits, though they aren't exposed by the tests. It would be very easy to trace your Robot's path, for example. Re-winding to a specific point on the path would be trivial. All very nice, but not part of the test suite.

[IanWhitney]

Ok. This now passes CI and is basically ready to go. Once we settle on API and improve the example code a bit, it'll be ready to merge.

[IanWhitney]

Thinking about the immutability thing more...

As I mentioned earlier, I think the immutable design advantages become clear if you want to rewind to a point. Maybe we could have an optional test that's commented out:

// Optional:
// #[test]
// fn robot_simulator_can_return_robot_at_any_point() {
// let robot = Robot::new(...);
// let simulator = RobotSimulator::new(robot);
// simulator.simulate("LAAAR");
// assert_eq!((-1,2), simulator.at_step(4).robot_position);
// assert_eq!((0,2), simulator.at_step(3).robot_position);
// etc.
// }

[IanWhitney]

I think this is now ready. Leaving the PR open until Tuesday, July 5th, after which I'll merge if there are no issues.

[Ryman]

@IanWhitney Is the intention for the example implementation to be showing idiomatic rust, or just a potential solution to pass the tests?

[IanWhitney]

@Ryman That is a good question without a clear answer!

Track maintainers discussed this recently: exercism/discussions#27

Unsurprisingly, people had different opinions. I think everyone is agreed that the first job of the example code is to pass the tests (otherwise our CI fails).

Beyond that first requirement, there was general agreement (though not unanimous) that the code should be:

• not clever
• idiomatic
• a good example

Probably my favorite description of the example code was this one:

[T]ry to solve the new proposed exercise as if the track maintainer were a real exercism user.

Which I most certainly am. I ended up writing Rust exercises because I wanted to use Exercism to help me learn Rust. My example code for this exercise is probably pretty close to what I would submit if I did this exercise.

[IanWhitney]

That's not to say my example code is exactly idiomatic, though. I'm still quite new to Rust and am learning new stuff all the time. Which is one of the reasons I encourage discussion in these PRs.

[petertseng]

I'll not comment on whether we want to go with mutable or immutable interface.

But I want to say that if we want an immutable interface, I suspect we can do turn_right(&self) -> Self instead of turn_right(self) -> Self. Can you check?

(And if it were mutable, it would be turn_right(&mut self))

[IanWhitney]

That results in compiler errors. Can not move out of borrowed content. There are additional changes we'd need to make to get that to work, though I don't know what they are off the top of my head.

[petertseng]

This comment surprised me enough that I checked out your branch to take a look.

My diagnosis: Make your Position #[derive(Clone, Copy)] and it will work.

[petertseng]

same with advance and instructions - If your Direction is Copy then they can take &self

Can't do the same for execute though since it can potentially return self, which means a &self wouldn't be able to become a Self.

[IanWhitney]

Huh. I never would have guessed that from the compiler error. Clearly.

Based on this quote from The Book, I'll update these to take &self

We should default to using &self, as you should prefer borrowing over taking ownership, as well as taking immutable references over mutable ones.

[petertseng]

well, to be fair, making them Copy was not the only solution - could have only made them Clone, not Copy, and then explicitly call clone() on them. But I suggested Copy simply because https://doc.rust-lang.org/std/marker/trait.Copy.html said "Generally speaking, if your type can implement Copy, it should"

[petertseng]

I don't always do this myself (maybe I should if I run into a compiler output I don't understand), but rustc should have outputted src/lib.rs:67:21: 67:25 help: run rustc --explain E0507 to see a detailed explanation

And I found that one of the solutions rustc --explain E0507 does say you can make it Copy, so that could have been a way to understand.

[petertseng]

I haven't tested, but if you had Robot derive Clone, I think this Self::build(...) could just be clone() instead. But I don't see this as a change that has to be done.

[petertseng]

For me, I think I've said all I want to say 👍

[Ryman]

The Direction argument being a reference here is a bit out of place when compared to the rest of the interface, for if we assume the user may want to store &Direction in their Robot type, the other methods will not allow this to be updated to anything reasonable, i.e.:

fn turn_right(&self) -> Self {
     Robot { 
         position: self.position,
         // nowhere to tie this lifetime to as it's not an input
         direction: &self.direction.next_clockwise() 
     }
}

[IanWhitney]

It's preferred for structs to take ownership of their values, so I'm OK with pushing students towards that.

[Ryman]

To be clear, that means fn new(x: isize, y: isize, d: Direction) -> Self rather than the current signature with the push towards the student calling clone to take ownership?

[Ryman]

Sorry for the delayed response, I left some feedback on things which may affect the users code and just left some nits on the example itself.

[IanWhitney]

Unless there's more discussion on this, I'll merge tonight.

[IanWhitney]

And in it goes. Thanks for all your input!