|
09:02
lizmat joined
09:05
Geth joined
|
|||
| lizmat | . | 09:09 | |
| it appears we lost our Internet connection during the night :-( | 09:10 | ||
| so potentially several hours are missing :-( | |||
| vrurg: isn't it so that only type objects that have a GenericHOW are generic ? | 10:36 | ||
| tellable6 | lizmat, I'll pass your message to vrurg | ||
| Geth | rakudo/main: 502a6a15fe | (Elizabeth Mattijsen)++ | src/core.c/Exception.rakumod Make X::Comp::BeginTime a bit more resilient Against compilation errors early in the setting compilation |
12:57 | |
| vrurg_ | lizmat: roles | 13:17 | |
| tellable6 | 2024-04-05T10:36:19Z #raku-dev <lizmat> vrurg: isn't it so that only type objects that have a GenericHOW are generic ? | ||
|
13:17
vrurg_ is now known as vrurg
|
|||
| lizmat | because a role can be parameterized and the parameterization may contain a generic ? | 13:18 | |
| vrurg | Exactly. | 13:23 | |
| lizmat | ack | 13:24 | |
| vrurg | Basically, this is the primary way how we get generics in first place. | ||
| Then, there are nominalizables. I.e. with T:D() we actually get a generic definite coercion. | 13:25 | ||
| ab5tract | shouldn't we already know whether roles can parameterize based on their declaration? | 13:38 | |
| ah, nevermind, I grok the point now | 13:43 | ||
| [Tux] | MasterDuke: tux.nl/Talks/CSV6/speed4-20.html | 14:03 | |
| tellable6 | [Tux], I'll pass your message to MasterDuke | ||
| [Tux] | also note that the tux.nl domain has a chance of being EOL | 14:04 | |
| Geth | rakudo/main: a4423566c7 | (Elizabeth Mattijsen)++ | src/Perl6/Metamodel/RoleToRoleApplier.nqp Streamline Metamodel::RoleToRoleApplier (Part 1/N) - rename some variables for clarity - saner handling of .yada checks - remove unneeded nqp::hllize()s. At least on the MoarVM backend they do not appear to be needed. |
16:01 | |
| lizmat | hmmmm that is actually just RoleToRoleApplier hmmm | 16:02 | |
|
16:13
elcaro_ left
|
|||
| Geth | rakudo/main: 9f0b8689dc | (Elizabeth Mattijsen)++ | src/Perl6/Metamodel/RoleToRoleApplier.nqp Streamline Metamodel::RoleToRoleApplier (Part 2/N) - more variable renaming for clarity - add helper sub for checking whether a method already exists - change for loop into while loop - extract submethod inclusion condition out of loop - refactor methods by name addition completely |
16:44 | |
| rakudo/main: 5256102d98 | (Elizabeth Mattijsen)++ | src/Perl6/Metamodel/RoleToRoleApplier.nqp Streamline Metamodel::RoleToRoleApplier (Part 3/N) - some variable renaming - change for loops to while loops - refactor target method addition |
17:18 | ||
| rakudo/main: a153c729c0 | (Elizabeth Mattijsen)++ | src/Perl6/Metamodel/RoleToRoleApplier.nqp Streamline Metamodel::RoleToRoleApplier (Part 4/N) - abstract method addition / collision recording in a helper sub - let both method and private method addition use this helper sub |
17:42 | ||
| rakudo/main: f0d5a9425b | (Stefan Seifert)++ | 2 files RakuAST: fix symbols declared in role bodies disappearing for the resolver After we finish parsing a role we replace the generated Block with a fully fledged Sub by moving over the block's body. The Block however is also a lexical scope and as such carries declarations that we also have to move to the new Sub object. Fixes role R[::T] { package G { class A is Array[T] {} }; has @.a is G::A; } |
18:24 | ||
| lizmat | aw, still 1019, nine++ nonetheless! | 18:35 | |
| greppable6: multi_methods_to_incorporate | 19:04 | ||
| greppable6 | lizmat, Found nothing! | ||
| Geth | rakudo/is-item-redux: e62e394874 | ab5tract++ | 5 files Scaffolding for 'is item' trait on parameters |
19:19 | |
| ab5tract | as suggested by lizmat++, restarting with the intent of using the is item trait solely as a tie-breaker in multi dispatch, rather than an actual working constraint on the argument's item-ness outside of a multi dispatch context | 19:24 | |
| it would be great to dig to into the bottom of why 'callstatic' and 'callmethod' decont the args, but that's a bit beyond my current ken | 20:08 | ||
| TIL that the order of named args matters in multi dispatch.. (this seems wrong) | 20:18 | ||
| m: multi sub q(:@z, :@b) { say 1 }; multi sub q(:@b, :@z) { say 2 }; q :b([]), :z([]) | |||
| camelia | 1 | ||
| ab5tract | let me rephrase: the ordering *doesn't matter from a caller standpoint | 20:19 | |
| what seems wrong is that this doesn't result in an ambiguous disptach | 20:20 | ||
| lizmat | I vaguely recall the reason: optional named args are never part of initial candidate selection | 20:21 | |
| they only serve as a tie-braker in case of ambiguous dispatch: and the first matching wins | |||
| so yes, the order in which you specify candidates *does* currently matter for optional named args | |||
| ugexe | m: multi sub q(:@z!, :@b!) { say 1 }; multi sub q(:@b!, :@z!) { say 2 }; q :b([]), :z([]) | 20:22 | |
| camelia | 1 | ||
| lizmat | heh | ||
| interesting... | |||
| now, the reasoning for this behaviour, I'm not sure about... | 20:23 | ||
| ab5tract | I'm poking at this particular bear specifically to determine how complicated I should make the `is item` disambiguation | ||
| since the easy way is to record and compare the indices of `is item` params against the indices of capture args, which raises this question of the variable indices of named args and params | 20:25 | ||
| but I'll consider worrying about named order as out of bounds for this current patch :) | 20:30 | ||
| lizmat | m: multi a(:$a, *%_) { dd %_ }; multi a(:$b, *%_) { dd %_ }; a :a(42), :b(666) | 20:35 | |
| camelia | {:b(666)} | ||
| lizmat | m: multi a(:$a, *%_) { dd %_ }; multi a(:$b, *%_) { dd %_ }; a ::b(666), :a(42) | 20:36 | |
| camelia | ===SORRY!=== Error while compiling <tmp> No such symbol 'b' at <tmp>:1 ------> %_ }; multi a(:$b, *%_) { dd %_ }; a ::bā(666), :a(42) |
||
| lizmat | m: multi a(:$a, *%_) { dd %_ }; multi a(:$b, *%_) { dd %_ }; a :b(666), :a(42) | ||
| camelia | {:b(666)} | ||
| lizmat | ab5tract: ^^ how would you disambiguate that, other than by the order of the candidates ? | 20:37 | |
| m: multi a(:$a, *%_) { dd; dd %_ }; multi a(:$b, *%_) { dd; dd %_ }; a :b(666), :a(42) | |||
| camelia | sub a(:$a, *%_) {:b(666)} |
||
|
20:53
lizmat_ joined
20:56
lizmat left
|
|||
| ab5tract | good question. *%_ does complicate the story significantly | 20:58 | |
| but for explicitly defined params in a signature, my instinct would be to throw a compile time sorry: "(:$a, :$b) and (:$b, :$a) are ambiguous" | 21:00 | ||
| but anyway, I've absolutely never had to worry about this before and I don't expect it's a major trouble for other users | 21:03 | ||
| lizmat_ | the *%_ is always implicit with methods | 21:05 | |
|
21:06
lizmat_ left,
lizmat joined
|
|||
| ab5tract | sure, but I'm talking about explicitly defined parameters | 21:08 | |
| lizmat | m: multi a(:$a, :$b) { dd }; multi a(:$a, :$b) { dd }; a :b(666), :a(42) | 21:09 | |
| camelia | sub a(:$a, :$b) | ||
| lizmat | m: multi a(:$a, :$b) { dd }; multi a(:$b, :$a) { dd }; a :b(666), :a(42) | ||
| camelia | sub a(:$a, :$b) | ||
| lizmat | m: multi a(:$a, :$b) { dd "one" }; multi a(:$b, :$a) { dd "two"}; a :b(666), :a(42) | ||
| camelia | "one" | ||
| lizmat | I guess that *could* be a compile time error | 21:10 | |
| ab5tract | I can understand the argument for the current behavior, but I think it might be more polite to let the user know that they are writing a multi that won't really multi | 21:13 | |
| Geth | rakudo/is-item-redux: 1475aab465 | ab5tract++ | src/vm/moar/dispatchers.nqp Add dispatch disambiguation for 'is item' |
21:40 | |
| rakudo/is-item-redux: db1404a74b | ab5tract++ | src/vm/moar/dispatchers.nqp Add dispatch disambiguation for 'is item' |
21:45 | ||
| lizmat | so I have this patch for the RoleToRoleApplier that takes about 4 CPU seconds off of "make test" (191 -> 187) | 22:17 | |
| but it kills Inline::Perl5 and I can't figure out why :-( | |||
| will sleep on it& | 22:18 | ||