🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
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

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!