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?
