Thanks for the responses, and my apologies for the duplication. (Google started raising objections to my account, and I thought I was locked out.)
On 9/5/11, Carl Mäsak <cma...@gmail.com> wrote: > 1parrota (>): >> 1. Should there be a way to make "die" behave like the Perl 5 version, > > Yes, there should. > There's a "known unknowns vs unknown unknowns" here. (More or less Moritz's point.) Stack traces are fine for the programmer or tester when the program does something unexpected. When the user tries to access a missing file, (or a similar problem), they're more likely to generate a panic-stricken twitch than a a useful understanding. For the moment, I suppose it doesn't matter, but it will. (How about defaulting to a 'quiet' termination, with an option to trace, (possibly a command-line or environment switch ?) > $c contains a Range object, namely C<0..20>. The Range object > stringifies to what you see by the output of C<say>. I hadn't read up as far as Ranges. Now I know. > > <masak> rakudo: my $c = 0..20; say +$c > <p6eval> rakudo f34aa8: OUTPUT«21» > > What you wanted was probably 'for 0..20 -> $c { ... }'. > Indeed, as I subsequently discovered. I bet I won't be the last to make that error, though. (One reason I'm willing to look foolish in public is to illustrate the mistakes that are likely to come up. If you study any kind of accident investigation, you'll find that people keep having the same accidents until a wording gets changed, a knob gets moved, or something is a different colour.) >> # Unannounced demise > > Should quit with a message. Known bug. > > The "Stub code" message is correct. It certainly shouldn't Null PMC > access. Known bug. > Oh, well. >> # The opposite to what I'd expect, if ... returns failure > > Same base cause as your first example above. Similarly wrong. > Maybe the meaning of "returns" in this context needs clarifying?