Add fizzy: an exercise teaching advanced generics and impl trait #828

coriolinus · 2019-05-03T21:32:44Z

This will probably always be a track-specific exercise; I don't know of many other tracks for which "figuring out the right trait bounds" makes a good exercise. Still, I think it's a good idea to teach complicated techniques by doing a simple thing in a complicated way, hence this exercise.

I implemented my version because it was late and I was bored. Then I realized I had something interesting, and turned it into an exercise. Closes exercism#821.

coriolinus · 2019-05-03T21:33:13Z

config.json

+      "difficulty": 7,
+      "topics": [
+        "generics",
+        "impl_trait",


This is a Rust-specific topic, but I think it's appropriate here.

coriolinus · 2019-05-03T21:38:03Z

exercises/fizzy/tests/fizzy.rs

+#[ignore]
+fn test_f64() {
+    // a tiny bit more complicated becuase range isn't natively implemented on floats
+    // NOTE: this test depends on a language feature introduced in Rust 1.34. If you


These last two tests require std::iter::successors, a 1.34 feature. It would be possible to work around it and support an earlier compiler, at the cost of a more complex test implementation in each case.

I know of no track-wide policy on the minimum supported rustc version. We should decide between:

it is ok for an exercise to require use of the most recent compiler

it is ok for an exercise to require use of the most recent compiler if it includes an apologetic note (as here)

the track as a whole can require no feature newer than some specified compiler version

My preference, at strength 1/10, is to allow the most recent stable compiler. The reason for this preference is in the service of keeping the code expressive (high signal to noise ratio), and that I personally am able to stay sufficiently up to date.

Useful clarifying point about the note: When 1.34 is sufficiently old, would the note be eligible for removal?

If one goal of the track is to optimise for accessibility, we may be required to only use some version that is widely available. For example, if a significant portion of students use distribution D and that distribution's package manager contains Rust at 1.32, then perhaps we would choose to stay at 1.32.

I do not know of the characteristics of the students, so I can't make decisions on that dimension. We may have to wait and see.

I agree: I also have no trouble keeping up with the most recent stable compiler, and therefore feel like it a reasonable thing to require of the students. We can revisit this if we start seeing student issues complaining that they don't have access to a recent stable compiler, but for now, let's decree the Official Track Policy: exercises may require use of the most recent compiler.

coriolinus · 2019-05-03T21:52:44Z

config.json

+      "uuid": "6b209749-d4af-45c2-bbdc-27603ce6979f",
+      "core": false,
+      "unlocked_by": "luhn",
+      "difficulty": 7,


Note on positioning: the Rust track currently has three exercises other than fizzy with the "generics" topic. None of them are core exercises. The easiest of these is a difficulty 4, unlocked by "luhn", so I chose to make this a peer exercise.

I don't believe that it's worth worrying too much about positioning, because Rust is currently in the middle of the track reordering project, and we can expect the position of this exercise to shift, possibly substantially.

petertseng

This Approval says:

An inspection of the provided code and tests indicates that these look reasonable.
It seems to be a good idea to include this exercise.

What is missing from this Approval, but would have been good to have:

An attempt by me to solve this exercise from the student point of view: Remove and do not refer to the example solution, and try to make the tests pass by only starting from the provided stub. Give a report on the experience of doing so.

Since I did not have time to do that yet, I leave open the choice of whether to wait for me to do that (I can't guarantee any specific time. This weekend?????), wait for any other reviewer to do that, or to simply put it out there and let students give that feedback.

petertseng · 2019-05-06T16:44:07Z

exercises/fizzy/.gitignore

@@ -0,0 +1,3 @@
+/target


regarding this gitignore, you may want to match the other exercises' gitignores exactly, else you may get a PR like #592

petertseng · 2019-05-06T16:45:02Z

exercises/fizzy/example.rs

+            "1", "2", "fizz", "4", "buzz", "fizz", "7", "8", "fizz", "buzz", "11", "fizz", "13",
+            "14", "fizzbuzz", "16",
+        ];
+        // a tiny bit more complicated becuase range isn't natively implemented on floats


Suggested change

// a tiny bit more complicated becuase range isn't natively implemented on floats

// a tiny bit more complicated because range isn't natively implemented on floats

petertseng · 2019-05-08T01:05:19Z

exercises/fizzy/tests/fizzy.rs

+#[ignore]
+fn test_f64() {
+    // a tiny bit more complicated becuase range isn't natively implemented on floats
+    // NOTE: this test depends on a language feature introduced in Rust 1.34. If you


My preference, at strength 1/10, is to allow the most recent stable compiler. The reason for this preference is in the service of keeping the code expressive (high signal to noise ratio), and that I personally am able to stay sufficiently up to date.

Useful clarifying point about the note: When 1.34 is sufficiently old, would the note be eligible for removal?

If one goal of the track is to optimise for accessibility, we may be required to only use some version that is widely available. For example, if a significant portion of students use distribution D and that distribution's package manager contains Rust at 1.32, then perhaps we would choose to stay at 1.32.

I do not know of the characteristics of the students, so I can't make decisions on that dimension. We may have to wait and see.

coriolinus · 2019-05-08T06:06:31Z

Thanks! I'm happy to leave this for another week or two until you get the chance to attempt it from the student perspective. I estimate that a student will probably spend about 90 minutes implementing this: it took a little longer for me to write it the first time, but students have the API and tests provided for them, which should help speed things.

petertseng · 2019-05-12T22:03:53Z

I have completed an implementation at https://github.com/petertseng/exercism-rust/blob/fiz/exercises/fizzy/src/lib.rs .

It had been sufficiently long since I reviewed this PR that I didn't remember any of the example at all, so I was doing things from scratch.

The 90 minute estimate was just about exactly where I landed, though I took about a 15 minute break away from the computer at the 45 min mark. A fair bit of my time was spent trying to figure out appropriate lifetimes. I didn't end up figuring out how to remove the 'static at line 10.

petertseng · 2019-05-12T22:46:39Z

As to what I learned: I was a bit busy thinking about lifetimes to give a lot of thought as to what impl trait means. I saw the mention in the code comment so I knew to look for https://doc.rust-lang.org/edition-guide/rust-2018/trait-system/impl-trait-for-returning-complex-types-with-ease.html myself and look at it. Although I got it here, it may be difficult to extrapolate from this and know to use it in a situation where a stub isn't given. I'm not sure how I'd solve this problem though, since not providing the stub would mean potentially a lot of time spent figuring out the right type for apply. So I don't have a suggestion that I like better than keeping things as is.

coriolinus · 2019-05-13T06:24:11Z

For the 'static in line 10, I think it's just necessary for the F parameter. I decided I was OK with this because I couldn't come up with a plausible reason for someone to attempt to use a function with a lifetime shorter than 'static. For the S parameter, I avoided 'static by storing subs in the Matcher object, which meant that it could have a shorter life than F.

I believe that we can summarize your experience implementing this exercise as "worth doing, no exercise changes required". As such, I will now merge this.

tintinthong · 2019-07-28T10:08:57Z

In reference to the PR above, perhaps its worthwhile to add pull request to the problem-specs on including fizz-buzz

coriolinus · 2019-07-28T13:35:15Z

I opted not to. Fizz buzz is well-known to the point of ubiquity. On its own, it's just not an interesting exercise. As a track-specific exercise, that's a good thing: the learning objective of this exercise is to demonstrate advanced trait usage. It's better if the ostensible problem is simple and well-understood, so that students can focus on the learning objective. However, I don't personally know of any other languages which would benefit from the specific problem posed here.

…

On Sun, Jul 28, 2019, 12:08 Justin Thong ***@***.***> wrote: In reference to the PR above, perhaps its worthwhile to add pull request to the problem-specs <https://github.com/exercism/problem-specifications/> on including fizz-buzz — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#828?email_source=notifications&email_token=AB3V4TS7F6SACLXDHWSYGA3QBVV3VA5CNFSM4HKXEF4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD263QYQ#issuecomment-515749986>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB3V4TR7IBD7W5AWD2WQVM3QBVV3VANCNFSM4HKXEF4A> .

Add fizzy: an exercise teaching advanced generics and impl trait

71b244b

I implemented my version because it was late and I was bored. Then I realized I had something interesting, and turned it into an exercise. Closes exercism#821.

coriolinus requested a review from petertseng May 3, 2019 21:32

coriolinus commented May 3, 2019

View reviewed changes

ensure stubs compile by giving tests more type hints

2058e51

coriolinus commented May 3, 2019

View reviewed changes

petertseng approved these changes May 8, 2019

View reviewed changes

respond to reviewer feedback

e40e531

coriolinus merged commit da21df6 into exercism:master May 13, 2019

coriolinus deleted the advanced-generics branch May 13, 2019 06:24

katrinleinweber mentioned this pull request Jul 27, 2019

Added famous fizz-buzz question exercism/r#122

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Add fizzy: an exercise teaching advanced generics and impl trait #828

Add fizzy: an exercise teaching advanced generics and impl trait #828

Uh oh!

coriolinus commented May 3, 2019

Uh oh!

coriolinus May 3, 2019

Uh oh!

coriolinus May 3, 2019

Uh oh!

petertseng May 8, 2019

Uh oh!

coriolinus May 8, 2019

Uh oh!

coriolinus May 3, 2019

Uh oh!

petertseng left a comment

Uh oh!

petertseng May 6, 2019

Uh oh!

petertseng May 6, 2019

Uh oh!

petertseng May 8, 2019

Uh oh!

coriolinus commented May 8, 2019

Uh oh!

petertseng commented May 12, 2019

Uh oh!

petertseng commented May 12, 2019

Uh oh!

coriolinus commented May 13, 2019

Uh oh!

tintinthong commented Jul 28, 2019

Uh oh!

coriolinus commented Jul 28, 2019 via email

Uh oh!

Uh oh!

	// a tiny bit more complicated becuase range isn't natively implemented on floats
	// a tiny bit more complicated because range isn't natively implemented on floats

Add fizzy: an exercise teaching advanced generics and impl trait #828

Add fizzy: an exercise teaching advanced generics and impl trait #828

Uh oh!

Conversation

coriolinus commented May 3, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

petertseng left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

coriolinus commented May 8, 2019

Uh oh!

petertseng commented May 12, 2019

Uh oh!

petertseng commented May 12, 2019

Uh oh!

coriolinus commented May 13, 2019

Uh oh!

tintinthong commented Jul 28, 2019

Uh oh!

coriolinus commented Jul 28, 2019 via email

Uh oh!

Uh oh!