lizmat Files=1294, Tests=109646, 210 wallclock secs (27.82 usr 8.17 sys + 2957.14 cusr 269.20 csys = 3262.33 CPU) 11:11
lizmat m: dd 0b111.11 11:29
camelia 5===SORRY!5=== Error while compiling <tmp>
Malformed postfix call
at <tmp>:1
------> 3dd 0b111.7⏏0511
lizmat m: dd <0b111.11>
camelia RatStr.new(7.75, "0b111.11")
lizmat is there a reason for this discrepancy?
lizmat m: dd <Nil> # seems like an oversight that we don't support that ? 13:26
camelia "Nil"
nine lizmat: why? Seems to me more likely to write code like my @zeros = <Zero Null Nil Zap Aught>; than to expect an actual Nil coming out of list quotes 13:30
lizmat m: dd <NaN Inf> # we do so for NaN and If 17:29
camelia (NumStr.new(NaN, "NaN"), NumStr.new(Inf, "Inf"))
lizmat nine ^^^ 17:30
bisectable6: role A { method a() { 666 } }; class B does A { has $.a = 42}; dd B.new.a 17:34
bisectable6 lizmat, On both starting points (old=2015.12 new=d5a34f1) the exit code is 0 and the output is identical as well
lizmat, Output on both points: «666␤»
lizmat bisectable6: role A { has $.a = 666 }; class B does A { has $.a = 42}; dd B.new.a 17:35
bisectable6 lizmat, On both starting points (old=2015.12 new=d5a34f1) the exit code is 1 and the output is identical as well
lizmat, Output on both points: «04===SORRY!04=== Error while compiling /tmp/knmt4TjqVq␤Attribute '$!a' already exists in the class 'B', but a role also wishes to compose it␤at /tmp/knmt4TjqVq:1␤»
lizmat m: dd <42.25*-10**4> 18:17
camelia RatStr.new(422500.0, "42.25*-10**4")
lizmat m: dd 42.25*-10**4
camelia -422500.0
lizmat which is correct?
lizmat m: dd -10**4 # I guess shorter 18:30
camelia -10000
lizmat I guess the current val processing is wrong 18:36
japhb lizmat: NaN and Inf are defined concrete Numeric values; Nil is not any of those. Thus I'm not surprised by that sort of discontinuity. 18:47
lizmat probably, but if you're using a CLI, it could be nice if you could just say "Nil" to indicate the absence of a value 18:48
japhb lizmat: As for the processing of <42.25*-10**4> I would not be surprised if it was a bug, but I also would not be surprised if that's a literal interpretation of the relevant synopsis.
lizmat but should val processing be different from general expression evaluation ? 18:49
japhb lizmat: Can you give an example of when it would be useful to be able to specify Nil in the command line args, instead of just not having that flag in the args at all? 18:50
lizmat sub MAIN($a, $b) { }; foo Nil 42 18:51
japhb The only think I can think of off the top of my head is slightly simplifying programs-that-spawn-other-programs. But that seems like an edge case for creating the Nil special case.
lizmat: Oh, you're thinking about having positional args that aren't ''.
lizmat yeah 18:52
japhb My thought is that that feels like it belongs in getopt module territory.
lizmat it's just that I know that Nil has historically been implemented *after* val() processing, so I wondered if we missed something there 18:53
japhb I think val() processing *should have been* a true subset of expression parsing, where they overlap. There are some things that val() can handle that normal expressions cannot, and that is a little odd. That ship may have sailed though. And in any case, it's a matter of waterbed complexity -- handling all of val() parsing in normal expressions would most likely push up the waterbed somewhere else. 18:56
lizmat: It's possible, yes. (missed out on Nil because history)
lizmat which cases can val() handle that normal expression handling can't ? 18:57
japhb val() after all has the advantage of being able to assume the entire string should parse as a single value.
lizmat I thought val processing was a subset of expression parsing
japhb Well (and I'm reaching into misty memory now), aren't Complex values treated differently? val() producing a compile-time value and normal expressions not going that far? Or is that no longer true? 18:59
m: dd <1+2i>
camelia <1+2i>
japhb m: dd 1 + 2i
camelia <1+2i>
japhb Oh duh, dd is evaluating the runtime value 19:00
I need to look at the AST, and ... I'm not sure the bots can do that
lizmat yeah it can be tricky
m: dd val('1 + 2i') # ensure runtime
camelia "1 + 2i"
lizmat m: dd val('1+2i') # ensure runtime
camelia ComplexStr.new(<1+2i>, "1+2i")
japhb m: dd 1 + 0i 19:01
camelia <1+0i>
japhb (phew)
lizmat m: dd val('1+0i')
camelia ComplexStr.new(<1+0i>, "1+0i")
lizmat m: dd val('1+Inf\i')
camelia ComplexStr.new(<1+Inf\i>, "1+Inf\\i")
japhb Ah yes, there's a difference.
m: dd <1+2i>, val('1+2i'); 19:02
camelia <1+2i>
ComplexStr.new(<1+2i>, "1+2i")
lizmat val creates allomorphs
japhb Right, but notice that <1+2i> is *not* an allomorph. 19:03
even though <...some real expression...> is
lizmat m: dd <4> 19:04
camelia IntStr.new(4, "4")
lizmat hmmm
I wonder if that's an issue with ComplexStr.perl
japhb github.com/perl6/specs/blob/master...x-literals 19:05
lizmat m: dd <1+2i>.^name
camelia "Complex"
japhb It's spec ^^
Intentional discontinuity. 19:06
Hmmm, github.com/perl6/specs/blob/master...-semantics is interesting too. 19:11
lizmat yeah, I've been looking a lot at that section the past weeks 19:14
I'm also implementing Blob literals, but different from this spec: github.com/perl6/specs/blob/master...b-literals 19:15
japhb The bit about no-space=no-val being useful for separating out a single constant from the surrounding expression precedence was I think what I had been trying to remember before. 19:16
lizmat :16{ aa bb cc } -> Blob.new(0xaa,0xbb,0xcc)
luckily the grammar already deals with that, as far as I have been able to determine
Xliff o/ 22:45
I'm having a bit of trouble with some metaprogramming.
Can someone tell me why my overridden ClassHOW method incorporate_multi_methods isn't getting executed? 22:46
github.com/Xliff/Method-Also/blob/...so.pm6#L38 22:49