The subject line should say "Bool::$1" instead of "Bool::$!", btw; I didn't let go of the shift key fast enough. This is what I get for trying to be clever.
On Tue, Dec 9, 2008 at 9:50 AM, Mark J. Reed <[EMAIL PROTECTED]> wrote: > This is a Rakudo issue, which I found while following up on the p6l thread > about literals. I'm not sure where the best place to ask about it is; I > already said something on p2. I will be happy to open up an RT, but I'd > like to understand what's happening so I'll have better luck making sure > it's not a dupe. Maybe I'm just getting too far ahead of the development > curve in terms of what I expect to work at this point. > > Basically, "True" and "False" are acting weird. > > I thought they were simply aliases for their fully-qualified brethren > Bool::True and Bool::False. Is that supposed to be the case? It is true in > pugs, FWTW. > > But in current Rakudo they seem to be distinct objects: > > $ perl6 -e 'say (True === Bool::True).perl' > Bool::False > > ... and oddly lacking in identity and metadata: > > $ perl6 -e 'say True.WHAT' > > $ > > I thought the empty ".WHAT" was interesting, so I tried this, too: > > $ perl6 -e 'say True.WHAT.perl' > > $ > > I didn't think any .perl method would return nothing, but apparently > Object.perl does, and nothing is overriding it in this case. > > The overall effect feels like an object-vs-primitive dichotomy, with > broken/partial autoboxing. > > Also, as I said in the original message to p2, even though True.WHAT.perl > succeeds in producing an empty string, this fails spectacularly: > > $ perl6 -e 'say True.perl' > Method 'perl' not found for invocant of class '' > current instr.: '_block11' pc 26 (EVAL_13:17) > called from Sub 'parrot;PCT;HLLCompiler;eval' pc 892 > (src/PCT/HLLCompiler.pir:508) > called from Sub 'parrot;PCT;HLLCompiler;command_line' pc 1441 > (src/PCT/HLLCompiler.pir:771) > called from Sub 'parrot;Perl6;Compiler;main' pc 16573 (perl6.pir:166) > perl6(37577) malloc: *** error for object 0x2f97160: Non-aligned pointer > being freed (2) > *** set a breakpoint in malloc_error_break to debug > Segmentation fault > > Suggestions on next steps? Assuming I have the problem properly > identified, I will be happy to submit an RT, write a test, dive into the PIR > ... > > -- > Mark J. Reed <[EMAIL PROTECTED]> > > -- Mark J. Reed <[EMAIL PROTECTED]>
