Perl 6 language and compiler development | Logs at colabti.org/irclogger/irclogger_log/perl6-dev | For toolchain/installation stuff see #perl6-toolchain | For MoarVM see #moarvm
Set by Zoffix on 27 July 2018.
Geth_ rakudo: RayMPerry++ created pull request #3204:
Issue #2092 | Clarify detached method error messaging.		 03:29
synopsebot RAKUDO#2092 [open]: github.com/rakudo/rakudo/issues/2092 [Hacktoberfest][LTA][easy to resolve][good first issue] "only alpha methods may be detached" message could be a bit clearer/accurater
nine lizmat: just that no _known_ non-Str Cool object can contain whitespace or newlines, that doesn't mean that there never will be one. Nothing's preventing the user from declaring class Foo is Cool { method Str() {} } 07:12
m: say ["foo bar", "baz qux"].words # this actually does make some sense 07:13
camelia (foo bar baz qux)
|Tux| Rakudo version 2019.07.1-368-g1e2b0ec59 - MoarVM version 2019.07.1-243-g1546c8c4d
csv-ip5xs0.777 - 0.788
csv-ip5xs-206.391 - 6.552
csv-parser22.646 - 25.016
csv-test-xs-200.423 - 0.455
test6.889 - 7.371
test-t1.714 - 1.736
test-t --race0.785 - 0.807
test-t-2029.530 - 29.537
test-t-20 --race9.167 - 9.264
 09:49
lizmat nine: yeah, I came to that conclusion as soon as I realized that Match is also Cool 10:10
Files=1274, Tests=109505, 205 wallclock secs (26.74 usr 7.78 sys + 2887.25 cusr 259.47 csys = 3181.24 CPU) 10:11
Geth_ nqp: 89a912193c | (Paweł Murias)++ | src/vm/js/nqp-runtime/package.json
[js] Specify version of dependency better to satisfy yarn
 14:23
nqp: eddfe9739d | (Paweł Murias)++ | src/vm/js/nqp-runtime/core.js
[js] Decont when passing p6 objects to js land
nqp: 498b64a4e2 | (Paweł Murias)++ | src/vm/js/nqp-runtime/reprs.js
[js] When wrapping js objects fill expose some methods that Perl6

code expects
vrurg What would be the most efficient way to distinguish NQP role from Perl6 one? 18:26
timotimo comparing its .HOW against a known nqp role's how possibly? 18:33
vrurg timotimo: ineffective because NQPParametricRoleHOW, NQPConcreteRoleHOW, ... 18:37
timotimo do they all do a common role perhaps?
hm
roles having roles, eh?
vrurg The best I came up with is nqp::istype($role.HOW.HOW, KnownHOW)
m: role R does Metamodel::DefaultParent { }; class C does R { } 18:38
camelia 5===SORRY!5=== Error while compiling <tmp>
Cannot find method 'role_typecheck_list' on object of type NQPParametricRoleHOW
at <tmp>:1
vrurg m: class C does Metamodel::DefaultParent { }
camelia ( no output )
vrurg Common role on HOW would possible be Metamodel::Naming. 18:40
jnthn vrurg: Why do you need to know that, ooc? 22:41
(Generally, we'd try to avoid that...)
(And find some solution where things fall naturally out of dispatch/polymorphism/whatever)
vrurg jnthn: R#3199, implementing github.com/perl6/problem-solving/issues/103. Perl6 class can consume an NQP role but they're not fully compatible by method parameters. 22:42
synopsebot R#3199 [open]: github.com/rakudo/rakudo/pull/3199 [WIP][roles] [WIP] Implement perl6/problem-solving#103
vrurg By 'they' I meant Perl6 and NQP RoleHOWs 22:47
jnthn vrurg: Specifics? Maybe just make the NQP one compatible? 22:49
vrurg jnthn: I didn't want to mess up with NQP. Besides, NQP doesn't have submethods and I didn't want method `BUILD` to be handled same way as submethod. 22:51
But even if I wanted to, roles doesn't have `find_method`. So, I have to deal directly with method tables. 22:53
jnthn Hm, but you probably should anyway, 'cus find_method on a Perl 6 role will pun the role and give you the instantiated method from the class :)
vrurg Precisely. I forgot that I already had this experience yesterday.... :D 22:54
jnthn The typical way we deal with things like "doesn't ahve submethods" is `nqp::can($the-how, 'submethod_table') or some such.
e.g. check if the thing has the method in question
vrurg Ah, really... At some point I'm stuck at some narrow field of view... 22:55
Thanks!
jnthn: There is still a controversy about calling submethods. I'm still opposed to call them as if with .*/.+. Besides, it breaks current behavior too much. I'd rather propose operators .- or .<<, or alike, which would reverse MRO and call methods/submethods in this order. 22:57
jnthn vrurg: Yeah, I read that (didn't have chance to reply yet, sorry :() and have been pondering it a bit 22:58
vrurg I could be just .- which would return failures for typeobjects where the method is not found.
So, it could be like (42, 0, Failure, 1) 22:59
jnthn Don't have any good answers yet, except maybe to borrow the idea that regexes modify quantifiers, e.g. *? and *: for minimal matching and ratchet
So it'd be .+ and .* plus something
I'm not sure what looks like a down arrow :)
vrurg My point is to avoid line noise. And yes, no good non-unicode symbol comes to mind anyway. 23:01
To my view, .+ and .* are overkill already. The approach with failures looks much cleaner and could have resulted in exactly one op for the purpose.
Then I'd be a perferct pair of .+ for forward-call and .- for reverse call. 23:02
*call order
Gibberish: $obj.?+method(); $obj.?-method(); 23:07
jnthn Poor punctuation. It dutifully goes about making different things look different, and just gets sniped at for its efforts. 23:18
vrurg jnthn: but it makes .* obsolete. Deprecation? 23:19
timotimo i didn't encounter a use case for .* and .+ so far, or maybe i didn't think to use either of them when it would have been good 23:20
vrurg timotimo: I used the contra-functionality: was manually iterating classes+roles in reverse-MRO order. .- would make a lot of sense for me at that point. 23:21
timotimo maybe what we need is something separate from method and submethod. like a hypermethod or a sidewaysmethod or an allmethod 23:22
and BUILD would become that
i think "aspect" is kind of what this is called in other circumstances?
i mean, aspect oriented programming has a similar taste
on the other hand, BUILD is a thing you encounter relatively early in your perl6 learning journey 23:24
and if that has some very funky keyword to go along with it, that'd potentially just confuse 23:25
or would only the ones in roles get that keyword?
"parasitic method BUILD"
vrurg Besides, the change itself is too radical. If we ever consider something like this, it would need big planning beforehand.
parasitic? 'alien method BUILD' 23:26
timotimo "also method BUILD" :) 23:27
if only the part in BUILD has to be changed, then we'd be in the clear as far as backwards compat goes, i believe
so far there has not been a way to get BUILD from orles contribute to (rather than replace) implementations of classes
so either you have a BUILD in your role now and it probably does what you don't want, or you have come up with a manual method
either way, as long as the role doesn't have the extra keyword in it, it wouldn't change how things happen 23:28
i'm not entirely sure if i'm making sense with this
vrurg timotimo: I'm currently working on BUILD/TWEK/DESTROY to be executed on per-role basis. Isn't it a solution? 23:29
timotimo it probably is
will that be language-version-gated?
vrurg Basically, github.com/perl6/problem-solving/issues/103 has my view on how roles and submethods must interact with classes. 23:30
timotimo: Yes, it is already.
I had to implement version revision recording for all type objects (including role variations).
It makes it impossible for pre-6.e classes to consume 6.e+ roles though. But I think it should be ok. 23:31
timotimo i'm not sure i have the sufficient brainspace to absorb all of this properly 23:33
but i think making submethods automatically multi-call by themselves could be a bad approach, just as you suggest 23:34
vrurg I had har time convincing Jonathan about this. Especially when he was backed by TimToady ;)
s/har/hard/ 23:35

Powered by Cro and the Raku® Programming Language.

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

Thank you!