I get that... I guess I just don't quite see why this case isn't possible.
To me, it seems totally reasonable to want to use RUN and then write some script that has IF <> REPORT to stop execution of just that script.
I'm also not convinced that an error is necessary. Showing an error when CALL does not get a return value makes sense to me, because you're expecting one. But if RUN sees a value, it seems safe to ignore it.
In almost any other language:
item = list.pop();
both do exactly what you'd expect and not using the return value is OK.
No, because if the script is being used in RUN, the way to stop it is IF <> STOP THIS SCRIPT.
Remember also that inside the FOR block body, the situation is exactly what you proposed here. Inside FOR there's a RUN (ACTION) and inside the ACTION script the user has put a REPORT block. The user's intention is clearly not to stop the ACTION script; it's to report a value from the block whose definition includes the call to FOR.
In other words, we have no way to distinguish your hypothetical situation from the FOR one.
But the different ring type should cancel that out. (in my opinion)
Sorry, I don't know what you mean. What type, and what is "that"?
the ring type is command vs. reporter, and `that' is the fact that they can't be used in the same context.
I think the debate going on here is great, but I have found @bh's example of the for-loop with counter to the be most compelling response.
The issue here is what should be done when an unexpected report is encountered. The preventative solution is to not report in an inappropriate context. Conversely, pad the "run" block with a "call" block when a reported value is expected and needs to be discarded.
Generally, the for-loop is considered a low-level construct. In Snap! where the lambda is a first-class citizen, the younger programmer will feel more at home when things behave somewhat imperatively.
The for loop report could be fixed if rings kept their scope.
That plan would however break the catch block.
Once you decide to use a graphical interface in which reporters and commands are different shapes, which has the pedagogic purpose of quietly teaching that reporters combine by composition of functions, whereas commands combine in a sequence, you are going to end up making compromises in all sorts of funny corner cases. No question that lambda calculus, in which every function call returns a value, is way more elegant. In Scheme you can compose functions, but you can also put the same functions in a sequence and ignore all but the last return value. We can't do that, not unless we want ovals to snap into a sequence like jigsaw-piece blocks.
Until 10 years ago, our intro CS course for non-majors, the equivalent to the current CS 10 (i.e., BJC), used Scheme. In some ways that was more fun for me. Even though we're just about at the point where Snap! can do everything Scheme can do (just missing macros), I miss the joy of using God's programming language. But that course was all white and Asian males. (Not literally all, but not many exceptions.) So we decided to see how much of the Scheme feel we could retain and still have a language that everyone would find welcoming.
So. Scheme doesn't have REPORT at all, so it doesn't give any guidance about how to handle weird cases. Given that, I think the right thing is to make sure users can accomplish the things users want to accomplish, rather than to spend a lot of time on questions such as "what should happen if you CALL an empty ring?"
In this discussion, getting FOR to work properly was our main guidepost in planning things like REPORT in a command context. It wasn't trivial for Jens to implement finding the innermost reporter context and reporting from there -- a sort of implicit nonlocal exit -- but it was clearly the right thing. If there is no pending reporter context, then it's totally unclear what the user can have meant.
As a special case of the special case, if a toplevel script does a REPORT, we put the reported value in a speech balloon. That's our best guess as to what the user meant.
(You need to be wearing the Turtle costume for this to work, not another costume.)
Actually,python dosent have ';'s!