🦋 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.
nine I woke up and immediately realized why one would want splice to flatten anything in the first place. You may want to insert these 1 million elements in the middle of the target array. Trying to pass those as individual arguments will quickly run into the max args limit. So you really need the ability to pass a boat load of elements as a list. 06:16
That of course raised the questions: how do others do it? Scala uses different names for these operations (insert vs. insertAll). Actually even Raku does so in the case of push vs. append. That really does seem like a better approach to me. 06:18
The reason I so dislike the dispatcher approach is that it disambiguates something that is absolutely ambiguous. All that an @ sigil does is require the thing such a variable contains to do the Positional role. Positional $a and @a are exactly the same in that regard. The only other difference is the default value where @ gives you an Array. 06:31
The pull-request gives as problem that with these candidates, the first one never gets checked if the sub is passed an Array: 06:34
multi sub($a where *.can("elems") == 2) {...}
multi sub(@a) {...}
But since @a implies Positional type, all one needs is to supply a type to $a as well: 06:35
m: multi sub foo(Positional $a where *.elems == 2) { say "where"; }; multi sub foo(@a) { say "at" }; foo([1, 2, 4])
camelia at
nine m: multi sub foo(Positional $a where *.elems == 2) { say "where"; }; multi sub foo(@a) { say "at" }; foo([1, 2])
camelia where
nine $ sigiled variables can be bound to any C<$x> may be bound to any object, including any object that can be bound to 06:40
any other sigil
Nowhere else does $ imply "the bound object must be in a Scalar container". 06:41
With regards to parameters, there is actually something that already exists and requires the bound object to be in a Scalar container:
m: multi foo($a is rw) { say "rw" }; multi foo($a) { say "normal" }; my $b = []; foo($b); foo([]) 06:42
camelia rw
nine m: multi foo($a is rw) { say "rw" }; multi foo($a) { say "normal" }; foo($ = []); foo([]) # again, without a named variable
camelia rw
07:48 sena_kun joined
ab5tract I am on my way to an appointment so will have to respond in full later but 09:14
8:42 AM <nine> m: multi foo($a is rw) { say "rw" }; multi foo(@a) { say "normal" }; foo($ = []); foo([]) # again, without a named variable 09:15
Geth MoarVM-Remote/main: e60fd92f17 | (Elizabeth Mattijsen)++ | 21 files
Preparations for first official ecosystem release
ab5tract Your example isn’t (or at least shouldn’t be) hitting the disambiguation code. Only $ signature parameters annotated as Positional should get involved 09:18
Which is sort of the whole point of this approach. It simply introduces a tie break into an otherwise ambiguous dispatch
Geth MoarVM-Remote/main: 6e7ae3c1ed | (Elizabeth Mattijsen)++ | 4 files
lizmat The CI tests on MoarVM::Remote fail because it can't find moar..... 09:30
would appreciate if more CI savvy people could find out wtf is going on
Geth rakudo/main: d1acbe933e | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION
Bump NQP to get "code_of_method"/"declares_method" methods

in all applicable NQP classes that may be referenced in Raku
rakudo/main: ef942c5ced | (Elizabeth Mattijsen)++ | 8 files
Add/Use "code_of_method"/"declares_method" methods

Reducing clutter with regards to needing to always also test the submethod table (if any).
ab5tract nine: I've had a chance to read your objections more clearly 10:29
To start, your example does not demonstrate a means of doing the kind of disambiguation that the proposed changes enable 10:31
m: multi foo($a is rw) { say "rw" }; multi foo(@a) { say "normal" }; foo($ = []); foo([])
camelia normal
ab5tract > But since @a implies Positional type, all one needs is to supply a type to $a as well: 10:36
^^ in base this is not true. supplying a type to $a without a where guard or other trait will catch all Positionals passed to it 10:37
> Nowhere else does $ imply "the bound object must be in a Scalar container". 10:38
^^ except that colloquially $foo is called a scalar 10:39
To zoom out a bit: If $[] and [] are exactly the same, why do we have both? If they are not exactly the same, why don't we have a clean user interface for distinguishing them? 10:43
lizmat fwiw, this also applies to ${ } and { } 10:44
fwiw, I think we need to be able to dispatch on the whether the parameter is a container or not 10:49
maybe nine is more opposed to the syntax than functionality?
multi a(@a is container) vs multi a(@a) perhaps ? 10:50
multi a(@a is item) vs multi a(@a) perhaps better? 10:51
Geth rakudo/main: ffc663d52f | (Elizabeth Mattijsen)++ | 2 files
Streamline Metamodel::ClassHOW (Part 2/N)

  - assume non-generic until proven otherwise at compose time. This also
   removes the raku-class-archetypes dispatcher, as it appears to not be
   needed this way.
  - remove documentation of raku-class-archetypes dispatcher as well
lizmat vrurg: ^^ please tell me I made a booboo here: all tests pass, so I have currently no reason I did 11:03
ab5tract I'm of course open to other formulations and approaches 11:05
lizmat the reason I like Positional $a is that it is clear what it means, and that "Positional @a" and "Positional %a" already have distinct meaning 11:06
whereas "$a is item" would be... weird and probably an error 11:07
as opposed to "@a is item" or "%a is item"
nine m: multi foo(Positional $a) { say "scalar"; }; multi foo(@a) { say "array" }; foo([]) # This is the case made for why one wants to disambiguate 11:48
camelia array
nine m: multi foo(Positional $a) { say "scalar"; }; multi foo(@a) { say "array" }; my $a = []; foo($a) # Wait, what? Since when does putting things into a variable change semantics so much? $-sigilled variables are not supposed to impose anything on their value, are they? 11:49
camelia scalar
ab5tract nine: it changes things in the small subset of cases where the designer of the method wants you to have that flexibility... 11:58
which is likely to be a total of zero cases in the wild because before the change, having both Positional $a and @a candidates in your multis would result in an ambiguous dispatch error 12:00
nine Zero cases now. But whenever there is a feature it will get used. I argue that in this case the feature would lead to bad interface designs and some serious wtfs. 12:02
ab5tract the splice change could have a wider impact, that's true. the current way blin works makes it impossible (AFAIK) to check based on a branch
nine That's exactly the reason why I usually keep away from language design discussions - it's so damn hard and the implications are far reaching. I'd have to invest a lot of quiet time and thought to make such a desicion and feel good about it. 12:03
ab5tract fair, but here we are. the only way out is through :) 12:05
> $-sigilled variables are not supposed to impose anything on their value, are they?
nine I remember arguing for introduction of the contains method. That one has led to countless problems because of its surprising behavior when called on lists. Because we did not take enough time to think it through.
ab5tract let's zoom out for a second and discuss "$-sigilled variables are not supposed to impose anything on their valie" 12:06
if we remove the "variables" from the statement, is it still true? 12:07
in other words, are $[] and [] supposed to be the same? if so, why do we have both? and if not, why can't a user distinguish them?
and also I want to be clear that I appreciate you using your time to think about and discuss this. 12:09
lizmat m: my %h = a => { b => 42 }; for %h.values -> \hash { dd $_ for \hash }
camelia Mu %h = ${:b(42)}
lizmat one often occurring WAT with newbies :-(
Geth rakudo/main: 00256ffba9 | (Elizabeth Mattijsen)++ | src/Perl6/Metamodel/ClassHOW.nqp
Streamline Metamodel::ClassHOW (Part 3/N)

  - make adding a fallback threadsafe
  - streamline .compose (for now)
  - move error handling for unresolved stubs to separate method to
   reduce local bytecode footprint
nine ab5tract: the $ prefix (or .item method) prevents an iterable from getting flattened in list context, as is the case with flattening slurpy arguments: 12:23
m: sub foo(*@a) { dd @a }; foo([1, 2]); foo($[1, 2])
camelia [1, 2]
[[1, 2],]
nine In cases like splice or sub (@a) or sub (Positional $a) there is no flattening, thus the $-prefix has no effect. 12:24
12:30 MasterDuke left
ab5tract > why can't a user distinguish them? 12:32
nine What do you mean?
ab5tract My patch is literally to provide a mechanism for the user to distinguish between $[] and [] 12:33
nine They already could before your patch:
m: sub foo($a is raw) { say $a.VAR.^name }; foo([1, 2]); foo($[1, 2])
camelia Array
ab5tract no, that isn't good enough 12:34
nine That is of course something one can argue about. I'm obviously in the camp of "this is something very obscure that you really shouldn't need, so it's ok if it's somewhat hidden and a bit cumbersome" 12:35
ab5tract well we are at a clear impasse. 12:36
I guess it defaults to not adopting the change
fwiw, I thought my solution _was_ somewhat hidden and a bit cumbersome 12:37
lizmat fwiw, I *do* feel we need a way to dispatch on itemness or not 12:40
"$a is raw" is not a solution to that
nine In a way, yes it is. What I just can't get over is that it turns two things that should be equivalent into something that behaves differently. The learning curve probably goes like: from "$ is for single objects and @ is for arrays" to "@ actually means the object does the Positional role". Then you come across two multi candidates with one a (Positional $) and the other a (@) and now what? 12:41
lizmat but then we're arguing syntax, no?
ab5tract that seems like an API documentation problem at most
nine "$a is raw" at least clearly points out that there is something special going on
ab5tract but yeah, again, I'm open to syntax 12:42
lizmat sub a(@a is item)
would also
nine I guess I could live a bit better with "is item" as it is more clear about what it does and it does not invalidate those positions on the learning curve. I still think this feature encourages bad API design. Again it means that my $a = []; foo($a); and foo([]) will behave differently. Of course we have never prohibited bad API design. 12:45
ab5tract m: multi sub a(Positional $a is raw where *.VAR.^name eq 'Array') { "array" }; multi sub a(Positional $a is raw where *.VAR.^name eq 'Scalar') { "scalar" }; dd a([<a b>]); a($[<c d>])
camelia Cannot resolve caller a([a b]); none of these signatures matches:
(Positional $a is raw where { ... })
(Positional $a is raw where { ... })
in block <unit> at <tmp> line 1
nine m: multi sub a(Positional $a is raw where { $_.VAR.^name eq "Array" }) { "array" }; multi sub a(Positional $a is raw where { $_.VAR.^name eq "Scalar" }) { "scalar" }; dd a([<a b>]); dd a($[<c d>]) 12:47
camelia "array"
nine Apparently .VAR does not curry
ab5tract oof, another where + whatevercode bug!
nine In RakuAST it does :) 12:48
ab5tract that's always a nice thing to hear 12:51
I don't know if you've had any cause to peruse the changes I made to whatevercodes in RakuAST, but that was an epic patch that felt great to finalize last year 12:54
nine I'm so grateful that you did that :) It was already so hard getting it to the place from which you took over. And that was just half of the way 12:57
ab5tract It was my pleasure! It was also my pain, of course, but it was worth it 13:02
Geth rakudo/main: 189ce4f749 | (Elizabeth Mattijsen)++ | src/Perl6/Metamodel/ClassHOW.nqp
Streamline Metamodel::ClassHOW (Part 4/N)

  - fetching roles using nqp::splice
  - general fallback handling optimizations
vrurg lizmat: you're very much wrong in your assumptions. Archetypes of a class is not only about the class itself but it's also about its instances which can or cannot be generic. 13:17
lizmat then we need more tests :-) 13:18
vrurg Yep.
Geth rakudo/main: ab0a1e12dc | (Stefan Seifert)++ | src/Raku/ast/name.rakumod
RakuAST: fix compile time error on encountering runtime lookups

Fixes: my $foo = 1; my $bar = "foo"; say $::($bar);
lizmat vrurg: if you could provide me some examples that are now failing, I'll make sure they're tested 13:20
vrurg It's my bad that I haven't added the tests. But back then JSON::Class was my testing area, then I got no time and memory. :)
lizmat ok, so you're saying JSON::Class will now be failing?
I can take that :-) 13:21
I mean, as source of inspiration :-)
vrurg It should, but I don't remember if I managed to implement corresponding tests for it too. :(
Heh, there are tests for non-generics, but no checks is they were generics before. Not reliable. 13:24
ab5tract so it occurs to me that another approach is to make Positional $a (or @a is item) candidates even more targetted by only succeeding in cases where the scalar has no name.. though maybe this is more, rather than less, confusing
Nevermind, that sort of breaks the utlity of the thing since you would have to include all of the elements of said array directly at the callsite 13:26
lizmat yeah, it would :-) 13:27
Geth rakudo/main: 3bbd35c54d | ab5tract++ | src/Perl6/bootstrap.c/BOOTSTRAP.nqp
Revert "Add multi positional scalar disambiguation to legacy dispatch"

We will be taking a different approach to this.
This reverts commit da2d9069ee5519cb47981f177e4a9a8ceecd7129.
rakudo/main: 7e5f77e7cf | ab5tract++ | src/vm/moar/dispatchers.nqp
Revert "Add multi disambiguation for positional scalars"

We will taking a different approach to this.
This reverts commit ff08bcde7e48c8eb70747e26feb105d004d9a741.
vrurg OK, the most simple case to test would be Foo { has Bool $.generic; multi method is-generic(::?CLASS:D:) { $!generic } }; $foo.set-generic(true); $foo.^archetypes.generic; $foo.set-generic(false); $foo.^archetypes.is-generic; 13:30
The switching back and forth is better be repeated in a loop for 2-3 times as dispatchers tend to record last results if guards are incorrectly set. 13:31
vrurg is afk for work. 13:32
ab5tract ..... :O 13:35
m: multi s(@a is onearg) { dd "onearg", @a }; multi s(@a) { dd "other arg", @a }; s $[1,2]; s [3,4]
camelia "other arg"
[1, 2]
"other arg"
[3, 4]
ab5tract ah, sorry, false positive. I haven't recompiled after the revert locally 13:36
umm, even worse, I just misread the output locally
Geth rakudo/main: 6c663f7808 | (Elizabeth Mattijsen)++ | src/Perl6/Metamodel/ClassHOW.nqp
Streamline Metamodel::ClassHOW (Part 5/5)

Abstract fallback logic into a proper class
rakudo/main: 9d6f284248 | (Stefan Seifert)++ | src/Raku/ast/resolver.rakumod
RakuAST: fix lookup of type expressions, e.g. ::('Int')
nqp/is-item: eb94b01805 | ab5tract++ | 2 files
Enable the creation of 'is item' and 'is exact type' param traits
nqp: ab5tract++ created pull request #819:
Enable the creation of 'is item' and 'is exact type' param traits
rakudo/main: 33f41e6a24 | (Stefan Seifert)++ | src/Raku/ast/resolver.rakumod
RakuAST: fix variables mistakenly treated as types

Fixes my $i = 1; say ::($i); In this case the check whether the thing found through the name was a type gave a false positive as the Scalar found as compile-time-value was deconted, resulting in an Any type object.
nine 996
lizmat whee! 16:09
ab5tract Should we throw a virtual party at 1000? 16:26
lizmat sounds like a plan to me! 16:28
Geth nqp/is-item: 7bffb43a09 | ab5tract++ | 2 files
Enable the creation of 'is item' and 'is exact-type' param traits
nqp/main: cd92b38e60 | ab5tract++ | 2 files
Enable the creation of 'is item' and 'is exact-type' param traits
rakudo/main: dc243d1250 | (Elizabeth Mattijsen)++ | src/core.c/Any.rakumod
Streamline some Any.AT-xxx candidates

  - add a specific candidate for Any::U.AT-POS where the invocant can
   be written to. This by itself appears to nibble off 5 CPU seconds
   from make spectest (1230 -> 1225)
  - do the same for Any::U.BIND-KEY
  - handle some more Any:U.AT-POS candidates to make behaviour consistent
rakudo/main: dab45fa312 | (Elizabeth Mattijsen)++ | 14 files
Streamline nqp negations

Instead of using prefix:<!>, use nqp::not_i on all cases where
  ! was being used on an nqp::op that returned a native integer.
Reduces bytecode size a bit, and thus increases chance of inlining.
Also change a few cases of "if !foo { bar } else { baz } to if foo { baz } else { bar }, thus removing an unneeded negation.
rakudo/main: 1af29151d7 | (Elizabeth Mattijsen)++ | src/Perl6/Metamodel/Concretization.nqp
Streamline Metamodel::Concretization (Part 1/N)

  - mostly about splitting the transitive / non-transitive logic into
   separate branches, rather than continuously checking inside every
  - also use nqp::splice where possible instead of iterating
rakudo/main: 5ed668d455 | (Elizabeth Mattijsen)++ | src/Perl6/Metamodel/Concretization.nqp
Streamline Metamodel::Concretization (Part 2/N)

  - mostly about using nqp::atpos(foo,N) vs foo[N] and using
   nqp::bindkey(foo, key, value) instead of foo{key} := value
22:28 sena_kun left 22:30 MasterDuke joined
MasterDuke fair warning, if i don't get any good suggestions for github.com/rakudo/rakudo/pull/5544...cc7bb19R23 you all will be forced to live with whatever i come up with... 22:32
japhb MasterDuke: That kinda looks like the !SET-SELF private methods used in a few places, though that usually eschews named and optional arguments for moar speed 23:58