Agree.
What's wrong with students sleep with the 'bug' overnight? It seems to me like a better version of the traditional homework. The bug usually 'bugs' people = makes them think. Who knows what might come up from this ... Just as I write this I get few ideas of possible 'breaks' that I haven't tryied yet.
I won't argue with you! I think the argument had to do with the fact that it's not the student's own bug, but rather a piece of code we give them that's deliberately broken. I can imagine that it'd be bad for us to do that and not say anything about it, but we show them what happens when you run it
so they know that we know that there's a bug in it!
OK, thanks for showing me.
The same holds for:
… I wasn’t aware of this construct (should have read your post #14 more closely). Hobby horse: undocumented Snap! feature, I think
… As well as v10’s variadic input parameter features (same). Yet another undocumented Snap! feature
The only remaining issue (from my perspective) is the value of any “external” variable sharing its name with an upvar is always reset as soon as the block declaring the upvar is executed: an (unwanted) external effect.
A slightly ridiculous idea - variadic upvar input (type 112)
Nice twist!
Even worse, it’s impossible to have a fixed number of variadic input items … o, well that makes sense, really. 
Anyway, you made the closest thing to an “upvar” not influencing same-named variables outside its native block!
I may use variadic input in a future update of the streams library, bh permitting.
Only after the logic programming library is done... :~)
