|
🦋 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 normal |
||
| nine | m: multi foo($a is rw) { say "rw" }; multi foo($a) { say "normal" }; foo($ = []); foo([]) # again, without a named variable | ||
| camelia | rw normal |
||
|
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 | |||
| afk& | |||
| Geth | MoarVM-Remote/main: 6e7ae3c1ed | (Elizabeth Mattijsen)++ | 4 files 0.0.2 |
09:24 | |
| 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 |
10:08 | |
| 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). |
10:09 | ||
| 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 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 |
11:02 | |
| 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 |
12:17 | |
| 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 Scalar |
||
| 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 |
12:46 | |
| 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" "scalar" |
||
| 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 |
13:10 | |
| 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. |
13:29 | |
| 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 |
13:57 | |
| rakudo/main: 9d6f284248 | (Stefan Seifert)++ | src/Raku/ast/resolver.rakumod RakuAST: fix lookup of type expressions, e.g. ::('Int') |
14:01 | ||
| nqp/is-item: eb94b01805 | ab5tract++ | 2 files Enable the creation of 'is item' and 'is exact type' param traits |
14:06 | ||
| nqp: ab5tract++ created pull request #819: Enable the creation of 'is item' and 'is exact type' param traits |
14:07 | ||
| 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. |
16:05 | ||
| 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 |
18:01 | |
| nqp/main: cd92b38e60 | ab5tract++ | 2 files Enable the creation of 'is item' and 'is exact-type' param traits |
18:02 | ||
| 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 |
18:03 | ||
| 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. |
18:53 | ||
| 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 iteration - also use nqp::splice where possible instead of iterating |
19:38 | ||
| 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 |
20:00 | ||
|
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 | |